Firmware download doesn't work with RCX 1.0

[hangrydave]

No description provided.

[maehw]

Hi @hangrydave ,

good that you already had opened that issue. I've also had issues downloading the firmware to one of my RCX 1.0. So I thought firmware download would just not work in general.

But then I discovered the issue here and tried the download with an RCX 2.0 - where it worked... almost. I've tried to download the latest official LEGO firmware firm0332.lgo, but it didn't finish successfully. The RCX' display stopped showing the "packet number" and did not beep at the end. It also fell back to showing the standing man and a single digit 1 in the display (like: "no firmware programmed").

(Showing a progress bar in the UI would be an improvement. 😉 Or a timer which estimates the remaining download/wait time.)

Have you been able to analyze the differences? Do you have both hardware revisions at hand?

Are you able to download firmware with the current InfraredBrickTower revision?

Kind regards
Mäh

---

Edit: For the RCX 2.0 download issue I've done a very little(!) analysis: it seems that the RCX' response message does not arrive and InfraredBrickTower does not attempt to send a retry and wait once again for the response. This makes it quite suspectible to noise. Though, this is pure speculation - I haven't checked your code. I've only tried to sniff the USB traffic and the serial IR communication. And I do not see any IR serial communication from the RCX for the last firmware download package before the download aborts. Unfortunately, InfraredBrickTower also does not log any error on stdout/stderr.

[maehw]

Okay, so I did some more testing and I must say that I've been able to successfully download(!) firm0332.lgo to an RCX1.0 programmable brick.

It looks like you're sending the PBAliveOrNot command (0x10) twice after opening the InfraredBrickTower application. Do you also evaluate the response from the RCX? From the manual:

"The command tests for the presence of a P-brick and re-initialises the toggle bit from the
communication protocol in the RCX, when executed as a direct command."

You may otherwise miss to reset the toggle bit and any further communication may fail... because instead of sending 0x65 (0b0110'0101) for the GoIntoBootMode command you might have to send 0b0110'1101 (i.e. 0x6D) instead. To prevent rolling the dice for hitting the correct toggle bit (either 0 or 1), you should make sure that the PBAliveOrNot command has been sent and also received. (Edit: Looks like it could be this part of the code

InfraredBrickTower/IBTController/ControllerUI.cpp

Line 146 in f6a2d55

LASM::Cmd_PBAliveOrNot(lasmCommand);

-- but the variable success is not used. Would be nice to see it dumped to the console's stdout/stderr.)

When not checking during application init, you should at least check shortly before sending the sequence of firmware download commands. People may just switch their RCX on after they have opened your application.

---

I've also investigated failed firmware downloads on the RCX2.0 brick: the firmware download just aborts after not having received a reply from the RCX - I haven't seen a retry mechanism implemented, just a plain timeout. This does not seem very robust.

---

Again, I'll have to put a disclaimer here: I haven't checked your source code and this is deduced from observations on the IR layer only. I also don't know if there's a real difference between the RCX1.0 and the RCX2.0... if I understand correctly, early versions of the RCX1.0 had an a power jack (to run from an external power supply OR batteries) and RCX2.0 ALSO supports IR with a carrier frequency of 76 kHz (+ the original 38 kHz). So this may just have been a correlation thing...