604803 URC-7955 non-standard EEPROM Size

fire.bird · Post by **fire.bird** » Sat Mar 03, 2018 3:23 pm

Hello all together,

I've just bought a URC7955, and would like to program some discrete Codes to it, but unfortunately there is currently no RDF file for that remote available.

The Model is very similar to the URC7980, which has a working RDF available in RMIR 2.06. I've already Setup the connection to the remote, and did a first draft on the new RDF, but didn't manage to get it working properly.

The Main differences between URC7980 and URC7955 are the following:
* Just 3 instead of 5 ActivityControls
* Just 1 Macro Button instead of 3 (NetTV vs. A/B/C)
* Just 5 instead of 8 Devices (DVD, Game, S.Bar is not available)

I've created a RAW Download, with the following settings on the Remote:

TV - Samsung Setting (used AutoDetect method not program)
STB - 1272
Media - 2615
Audio - manually learned should have the following HEX-Codes:

Mute: 1B-0D
Volume Up: 1B-10
Volume Down: 1B-11
Pause: 1B-30
Stop: 1B-36
Track Back: 1B-21
Play: 1B-35
Track Forward: 1B-20
1: 1B-08
2: 1B-04
3: 1B-00
4: 1B-12
5: 1B-05
6: 1B-02

Hex Codes listed above have been taken from the User Manual of the Device.

RAW Dump:
http://s000.tinyupload.com/index.php?fi ... 7841821141
RMIR saved & RDF attempt:
http://s000.tinyupload.com/?file_id=288 ... 6711914490

I'd really appreciate if anyone of the experts here on board could provide me some information/hint/help to get the RDF for the remote into a working shape.

Many thanks in advance!

Best regards,
Harald

fire.bird · Post by **fire.bird** » Thu Apr 05, 2018 3:30 pm

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:

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:

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

Post by **The Robman** » Thu Apr 05, 2018 5:27 pm

Harald, which remote are you working with?

3FG · Post by **3FG** » Thu Apr 05, 2018 10:49 pm

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.

fire.bird · Post by **fire.bird** » Fri Apr 06, 2018 9:21 am

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

Post by **mathdon** » Fri Apr 06, 2018 10:16 am

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.

fire.bird · Post by **fire.bird** » Fri Apr 06, 2018 12:58 pm

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.

3FG · Post by **3FG** » Sat Apr 07, 2018 12:28 am

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.

fire.bird · Post by **fire.bird** » Sat Apr 07, 2018 1:22 am

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.

3FG · Post by **3FG** » Sat Apr 07, 2018 9:00 am

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.

fire.bird · Post by **fire.bird** » Sun Apr 08, 2018 9:13 am

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.

3FG · Post by **3FG** » Sun Apr 08, 2018 2:33 pm

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.

Post by **mathdon** » Fri Aug 10, 2018 11:49 am

3FG wrote: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

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.

Comments please.

fire.bird · Post by **fire.bird** » Wed Aug 15, 2018 4:48 am

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

Post by **mathdon** » Wed Aug 15, 2018 6:45 am

fire.bird wrote:Thank you for investigating the issue.

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.