newRPL - can't restore to 39gs

[Claudio L.]

(03-18-2019 12:41 PM)franco51 Wrote:  More testing: As previously suggested the Win version is not significant and clearing the RAM was a red herring; it’s gone back to invalid data messages.

I have tried cleaning the 39gs USB contacts with IPA but as the boot loader always works with the exact same hardware I assume the connectivity is fine. As a double check, I put a UM25C USB Tester in series at the PC end. This class of device is very simple but by putting it in ‘scope mode it does at least confirm that the USB+ and USB- connections are driven by the 39gs USB driver.

I seem to remember something about pinging ponging data so I tried this: { « 1 1 + 2 2 + 3 3 + » } can be shuttled back and forth but I can’t send { « 1 1 + 2 2 + 3 3 + 4 4 + » } or anything longer from virtual to real calculator. The link is disconnected and a zero is returned as before. Going from real to virtual is not a problem with at least twice the length. Forgive me if this has been raised before - I can’t find it.

Any other suggestions, please?
BR
Frank

Now that's really strange, but more specific to help pinpoint the issue. What's failing is the transfer of multi-packet data from virtual to real. That's got to be either a timing issue or some kind of bug. The strange part comes from the code being identical for both virtual and real calc, except for the lower-level layer. I know libusb documentation talks about an extra byte sent by Windows but it's supposed to take care of that internally.

You presented a specific scenario doing { « 1 1 + 2 2 + 3 3 + 4 4 + » } USBSEND from the virtual calc to the real one. That's something we can try to replicate.
Can somebody else confirm this is failing? My calc is dead at the moment (as per the other thread) and until it comes back to life I can't do any testing but perhaps other users can help?
Whether it's a 50g, 39g or 40g, the firmware is the exact same code base so if it fails on one it should fail on all of them.