First I want to thank everyone involved into the development of RemoteMaster for this great piece of software!
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:

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.

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.

@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.

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

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.

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.

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.

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.

It is just the value of the length of the E2 space which is apparently incorrect.

I have at last turned my attention to the URC7955. I don't think the E2 length of 0xFFC is an error. I have downloaded a brand new URC7955 before pressing any keys and that also shows this length. I don't know the reason for these 4 bytes reserved at the end of the E2 but they do seem to be deliberate. They are all FF's in a new remote, but I don't think we can assume that they remain so. They will be erased to FF's whenever RMIR updates the E2 area, so RMIR needs to read them and then restore them after any update. This assumes that their value does not depend on the content of the E2 area, but in the absence of any understanding of their purpose, I think this has to be the working hypothesis.

To read and restore them, JP12serial needs to be able to read and write them. As 3FG has pointed out, at present JP12serial performs two tests: (a) that the region being written is an integral number of flash pages (which in the TI processor of this remote are 2KB in size), and (b) that the region does not extend beyond the end of the E2 area, calculated from the E2 size reported by the remote. For the URC7955 these are incompatible.

3FG has also written

Quote:

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.

It seems to me that JP12serial should always be able to write to the whole of any flash page that it can erase, so I cannot see what this danger might be. I don't even see that it needs to be a special case. I propose to modify the region test in the read and write operations of JP12serial so that (b) above is replaced by a test that the region does not extend beyond the flash pages in which the E2 area lies. I will then make a corresponding change to RMIR so that it reads the whole of these flash pages and restores the data of those parts that lie outside the E2 area.

The URC7955 is currently the only remote that this will affect, but it seems to me that this will be necessary also for any remote we come across in future that has an E2 area that is not a whole number of flash erase pages.

@mathdon:
Thank you for investigating the issue. I've also done tests with factory resetting the remote and also re-programming it via App. As you stated, the value for the E2 length always keept the same length of 0xFFC.

I'm too little expert on JP1 in order to give input/recommendations on your proposed suggestion for jp12serial modification.

I'm very pleased that you are still following this thread. I hope to have a development version for you to test within a week or so, with updates to jp12serial, RMIR and the draft RDF and with map and image files, too. I was afraid you might have lost interest due to the delay since you originally posted on this issue._________________Graham

I have now uploaded development build 9 of RMIR v2.06 to the RMIR Development folder. This upgrade supports the URC-7955 and includes RDF, map and image files for this remote. It also includes version 0.23 of jp12serial with binaries for 32-bit and 64-bit Windows, Linux and Mac OS X. Please see this post in the RMIR v2.06 announcement thread for full details of the upgrade.

I would be grateful if fire.bird and anyone else with this remote could test this and report back in this thread._________________Graham