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
Goto page 1, 2  Next
 
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: 10

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: 18452
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: 3241

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: 10

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: 2960
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: 10

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: 3241

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: 10

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: 3241

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: 10

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: 3241

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
mathdon
Expert


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

PostPosted: Fri Aug 10, 2018 12:49 pm    Post subject: Reply with quote

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

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.

Comments please.
_________________
Graham
Back to top
View user's profile Send private message
fire.bird



Joined: 06 Sep 2017
Posts: 10

PostPosted: Wed Aug 15, 2018 5:48 am    Post subject: Reply with quote

@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.
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Wed Aug 15, 2018 7:45 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Mon Aug 20, 2018 7:02 am    Post subject: Reply with quote

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
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
Goto page 1, 2  Next
Page 1 of 2

 
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