JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

URC-7955 (604803) non-standard EepromSize

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
fire.bird



Joined: 06 Sep 2017
Posts: 6

PostPosted: Thu Apr 05, 2018 4:30 pm    Post subject: Reply with quote

First I want to thank everyone involved into the development of RemoteMaster for this great piece of software! Smile
Then I'd like to mention that I'm not sure if this is the ideal place for the following kind of information/topic. In case it isn't please feel free to move that posting.


During working on a new RDF file we discovered that there is a problem saving read data when the EepromSize is not divideable by 16. As of now, this new RDF seems to be the first requiring a EepromSize which is not divideable by 16.
In the new RDF file the EepromSize has an unusual 0xFFC, which works nicely reading the data from the remote. But RemoteMaster fails with an Exception on trying to save that data to disk. Output in rmmaster.err:
Quote:
Error in write task: 4092
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 4092
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at javax.swing.SwingWorker.get(SwingWorker.java:602)
at com.hifiremote.jp1.RemoteMaster$WriteTask.done(RemoteMaster.java:3561)
at com.hifiremote.jp1.RemoteMaster$SaveTask.done(RemoteMaster.java:3634)
at javax.swing.SwingWorker$5.run(SwingWorker.java:737)
at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832)
at sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112)
at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842)
at javax.swing.Timer.fireActionPerformed(Timer.java:313)
at javax.swing.Timer$DoPostEvent.run(Timer.java:245)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 4092
at com.hifiremote.jp1.Hex.toString(Hex.java:558)
at com.hifiremote.jp1.Hex.toString(Hex.java:681)
at com.hifiremote.jp1.RemoteConfiguration.save(RemoteConfiguration.java:7911)
at com.hifiremote.jp1.RemoteMaster$SaveTask.doInBackground(RemoteMaster.java:3617)
at com.hifiremote.jp1.RemoteMaster$WriteTask.doInBackground(RemoteMaster.java:1)
at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at javax.swing.SwingWorker.run(SwingWorker.java:334)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
RemoteMaster.windowClosing() entered


Having a look into the code, I discovered the following section (lines 7909-7912) in the file controlremote-code/km/com/hifiremote/jp1/RemoteConfiguration.java:
Quote:
for ( int i = 0; i < getDataEnd( dataToSave ); i += 16 )
{
pw.print( String.format( "%04X", i + base ), Hex.toString( dataToSave, i, 16 ) );
}


So the above mentioned function will, run in that case, into:
i = 4080, which is < getDataEnd( dataToSave ) beeing 4092, and will then call Hex.toString with the instruction to do it for 16 bytes.
Which will result in an "java.lang.ArrayIndexOutOfBoundsException: 4092" triggered exactly at 4092 which is 0xFFC.

To solve this issue I already tried to modify that function to either use 4 instead of 16 which actually fixes the above listed exception in that use-case and writes the data properly to disk. This "solution" is not perfect, but helped to verify if this code block is the one causing the problem.

I'd highly appreciate if EepromSizes which are not divideable by 16 could in future versions of RemoteMaster be saved properly to disk.


Many thanks & best regards,
Harald
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18348
Location: Chicago, IL

PostPosted: Thu Apr 05, 2018 6:27 pm    Post subject: Reply with quote

Harald, which remote are you working with?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Thu Apr 05, 2018 11:49 pm    Post subject: Reply with quote

Rob,
Harald has a URC-7955 (604803), a sister of the URC-7980. Both of these are segmented remotes using the TI CC2541 processor. Harald and I have been working together on a RDF, and he has gotten it to a pretty good state. I'm not clear about the [ActivitiesControl] section,which for the 7980 includes text similar to "maps:$03+$0B+$09+$81+$83". I haven't found documentation of this feature.

Segmented remotes all include the length of the E2 area in their signature block, and JP12Serial.dll uses this length in determining if a read or write request is valid. We originally had the RDF setup with the length as $1000, but RMIR wouldn't read the remote. So we set the length to $0FFC, as specified in the signature block of the remote. Then Harald could read the remote but not save a RMIR file. He's done some excellent sleuthing to find the cause.

Harald has a temporary fix, but I'd like Graham to weigh on the permanent fix.
Back to top
View user's profile Send private message
fire.bird



Joined: 06 Sep 2017
Posts: 6

PostPosted: Fri Apr 06, 2018 10:21 am    Post subject: Reply with quote

@3FG:
Thanks for providing the details. I would not have been able to provide that much information on the RDF parameters and types, as I've little knowledge on JP1 so far.

I also want to clearly state that the work on the RDF was done by 3FG. I just have provided information and tried to verify/test it with the remote. Currently it is also not fully functional and from my side considered as a work-in-progress, even tough it already reads (nearly) all programmed features properly.



Just came to the above described conclusion when analysing the stack trace, and having a bit of luck.
The idea to set that 16 down to 4 is not to be considered as a suggestion for doing it this way. It was simply the easiest way to get a temporary fix.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2930
Location: Cambridge, UK

PostPosted: Fri Apr 06, 2018 11:16 am    Post subject: Reply with quote

3FG wrote:
I'm not clear about the [ActivitiesControl] section,which for the 7980 includes text similar to "maps:$03+$0B+$09+$81+$83". I haven't found documentation of this feature.

The [ActivitiesControl] section is documented in the Addendum to the RDF spec that is included in the Docs subfolder of each RMIR build. In revision 10 of the Addendum, the current one, it is on page 14.

On the matter of the EepromSize, I find it very strange that the size in the URC-7955 is four bytes short of 4K. I would like to understand these four bytes before jumping in with an edit to RMIR. It suggests to me that there is some new feature involved, not that simply UEI was short of space and needed to pinch four bytes from the E2 area.
_________________
Graham
Back to top
View user's profile Send private message
fire.bird



Joined: 06 Sep 2017
Posts: 6

PostPosted: Fri Apr 06, 2018 1:58 pm    Post subject: Reply with quote

mathdon wrote:
3FG wrote:
I'm not clear about the [ActivitiesControl] section,which for the 7980 includes text similar to "maps:$03+$0B+$09+$81+$83". I haven't found documentation of this feature.

The [ActivitiesControl] section is documented in the Addendum to the RDF spec that is included in the Docs subfolder of each RMIR build. In revision 10 of the Addendum, the current one, it is on page 14.

Just re-checked the documentation, but as already stated, I could also not find any information on the specific part of "maps:$03+$0B+$09+$81+$83" in the context of [ActivitiesControl].
[ActivitiesControl] itself is described in that area, but there is no hint on what the maps keyword does. Eventually it is just written in the RDF "603704 (URC-7980 Smart Control).rdf", and is not an instruction/configuration respected by RemoteMaster.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Sat Apr 07, 2018 1:28 am    Post subject: Reply with quote

It seems to me that we will have to modify JP12Serial. Setting the E2 length to 0xFFC does allow it to read from the 7955, but as I belatedly realized, erasing the E2 area requires the requested E2 size to be an integer multiple of the 2KB page size. But my reading of JP12Serial.cpp says that it does use the value written in the signature block as the E2 size and consequently fails a size check when asked to do a write since the size isn't a multiple of 2K.

My first thought is to insert a special case for 6 series remotes that rounds up the E2 size to a 2K boundary. I think that would get Harald up and running, but it seems like a dangerous approach,if we encounter another CC2541 remote.

I believe Harald is running under some variant of Unix, so I'm not able to generate even a test version.

A different issue: This remote has a Type 03 segment which has a format that is new to me. According to the manual, it is a macro with a time delay.I doubt that is causing any problems at the moment.

The most recent trial RDF is in the RDF Development folder.
Back to top
View user's profile Send private message
fire.bird



Joined: 06 Sep 2017
Posts: 6

PostPosted: Sat Apr 07, 2018 2:22 am    Post subject: Reply with quote

I've just tried to get jp12serial compiled on my system which worked flawless. So we can share patches for testing purposes.
Currently I've checked out the source from sf.net svn rev. 1592.


My main system runs on Linux amd64, but I also have Windows available in case required.


Have a nice weekend, I'll be away till Monday. Smile
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Sat Apr 07, 2018 10:00 am    Post subject: Reply with quote

Have you tried using the smartphone app? Perhaps if the setup is updated by the phone app, the $0FFC will be changed to $1000. If that happens, then no changes to JP12Serial or RMIR would be required.
Back to top
View user's profile Send private message
fire.bird



Joined: 06 Sep 2017
Posts: 6

PostPosted: Sun Apr 08, 2018 10:13 am    Post subject: Reply with quote

I've at the beginning once used the smart-phone app to program the remote.

The app itself is very limited, and more or less connects the URC Support Database for searching the codes with programming them into the remote. There was no feature to program macros or other interesting things from within the app.

In case app usage would influence the EpromSize, it might be the opposite way.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Sun Apr 08, 2018 3:33 pm    Post subject: Reply with quote

Yes, I have URC7980, so I know that the phone isn't very useful. However, the issue with the URC7955 isn't the actual size of available memory-- I think it has a lot of empty memory since the CC2541 has 256KB.

Segmented UEI remotes have a signature block which not only contains the signature (604803 in this case), but also the addresses and lengths of various blocks of memory. It is just the value of the length of the E2 space which is apparently incorrect. So I have some hope that another phone session of e.g. adding a new component will overwrite the two bytes containing the bad length.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central