Doesn't detect EV3 under Windows

[gtminch]

Running version 0.4.0, installed via the c4ev3-setup.exe installer. Can't find any getting-started or step-by-step documentation, so I'm optimistically reading the code instead.
My EV3 is in update mode, and the screen shows "Updating..". Windows Device Manager shows it under "Human Interface Devices" as "USB Input Device" with Hardware ID "USB\VID_0694&PID_0006". There's a similar "HID-compliant vendor-defined device" with similar VID and HID. That seems consistent with an EV3 in firmware update mode.

The Lego software, "LEGO MINDSTORMS Education EV3 Teacher Edition" detects it correctly and attempts to upload the firmware, but ev3duder doesn't detect it. I get the following results, even if the Lego application isn't running. Maybe the command "--usb flash info" isn't good, but it seems appropriate after reading the code.

PS C:\ev3\uploader> .\ev3duder.exe --version
0.4.0
PS C:\ev3\uploader> .\ev3duder.exe --usb info
EV3 not found. Either plug it into the USB port or pair over Bluetooth.

PS C:\ev3\uploader> .\ev3duder.exe --usb flash info
EV3 not found. Either plug it into the USB port or pair over Bluetooth.

[JakubVanek]

Hello,

I think the cause might be that the version tagged as 0.4.0 (~2018) predates the update support (~2020, e.g. 3c8e49b). I tried to cross-compile the latest ev3duder which should include this functionality and I have uploaded the resulting binary here. I have produced it this way:

• I am using Ubuntu 22.04
• I have installed the mingw-w64 package
• I have cloned the ev3duder repository, including the submodules
• I have run

  make CC=x86_64-w64-mingw32-gcc OS=Windows_NT

• I have then uploaded the resulting ev3duder.exe to Google Drive

My hope is that this new binary will work out of the box. However, I have not tested it yet on Windows and unfortunately I no longer have a EV3 brick available at the time.

[gtminch]

Thanks Jakup, I'll try it later.
In the meantime, I cloned your repo to my Mac and it built easily, runs and detects my EV3. I was surprised how easy it was.
Unlike you, I do have an EV3 brick. I've had it sitting around for years and rarely used it, but I showed it to my kids the other day and they very quickly figured out how to program some interesting moves. It didn't start up reliably and had firmware 1.03H so I thought I'd do the firmware update using one of the old Mindstorms applications, but now it doesn't start at all. My brick is bricked.
The Mindstorms apps show progress up to 98% then stall forever. ev3duder on my Mac also doesn't succeed, but at least it reports the problem: CRC errors every time. I've tried several firmware versions, and always the same result.
I've read your code in bl_install.c and it all makes good sense. I don't suppose you know if there's a boot loader function to read out the installed image? I'd be happy to add a command to read the EV3 image to a local file, then I could do a binary comparison and see where the problem is.
I can't find any documentation about the boot loader protocol though. I've had a Quick Look in Lego's firmware source package but couldn't find any reference to the boot loader yet.

[JakubVanek]

I don't remember there being a flash-reading command. IIRC, the logic in ev3duder is based on a C# implementation of the update protocol. The C# tool is in turn likely based on the implementation in BricxCC: constants and logic. However, I didn't find any other documentation either.

However, I think there might be another way. The bootloader commands allow the flash to be programmed and verified in small chunks. If the cause of the problem is a bad flash sector, this might be the way to find it. I have prepared such an implementation on the https://github.com/c4ev3/ev3duder/tree/flash-by-sector branch. The flashing process can be invoked normally via ev3duder flash install, however the logged output should be different.

[gtminch]

Aha, I wondered if doing it in small blocks would be an option. I'll check it out. Thanks!

[gtminch]

Well by now I'm very confused. I ran your flash-by-sector branch and it appeared to work but my brick still doesn't boot past the "Starting.." screen.
I modified your branch to print the local and remote CRCs for each sector, and they all match.
I added another step at the end to calculate the local CRC for the full image, and to request the full image CRC from the boot loader, and they don't match.
So I added a further step to request (without erasing or programming) the sector-by-sector CRCs and compare to the locally calculated ones. All indications are that every sector is correctly programmed, but the full-image CRCs do not match and my brick doesn't boot past the "Starting.." screen. I don't see how that makes sense. If all the bits are correct, why isn't the total correct?

[JakubVanek]

This does indeed sound weird. I don't really have a definite explanation for this.

However, I have one wild theory - it could be that some EV3 DRAM cell at a relatively high address is defective.

• For this theory to work, I have to assume that the boot EEPROM loads the flash memory contents into RAM prior to the CRC computation.
• When the CRC is computed only for one sector, the EEPROM loads only that one sector into RAM and so the RAM defect does not have an effect.
• When the CRC is computed over all sectors, the EEPROM loads the full flash contents into RAM (flash is 16 MiB, RAM is 64 MiB). The defective RAM cell is hit in the process and so the subsequent CRC computation returns a different result.
• This may also explain why the brick does not boot. Some of the system code or data may be corrupted during boot. The flashing procedures used by stock ev3duder and the EV3 software could also have been affected by that defect.
• The reason that firmware 1.03H worked previously (albeit unreliably) could be a coincidence:
  • The corruption could have been hitting an unused part of memory in that firmware build
  • The issue may also be that the first system boot is slightly different, but I don't remember the details.

I think that this theory can be proven or disproven by checking if CRCs reliably fail only when the size of the checksummed area exceeds a certain threshold.

OTOH, the cause might be also something different with a similar manifestation (e.g. the CPU itself starts misbehaving under heavy load from booting or CRC calculation).

[JakubVanek]

Hmm, if the theory is true, then reflashing the 1.03H firmware using the flash-by-sector ev3duder branch may at least partially revive the brick.

[gtminch]

Ok, I have interesting news. For a start, I found somebody living about 20 minutes away selling a used EV3 set, complete with brick, sensors, motors, etc, at a reasonable second-hand price. So I bought it.

I've also added a "crc' command alongside the "install" command, that doesn't write anything but gives the user the ability to compare CRCs for a certain portion of the firmware. e.g.:
"... crc firmware.bin" compares the file to the EV3 for the full image
"... crc firmware.bin 0 125" compares the first half of the image
"... crc firmware.bin 125 125" compares the second half
etc, and then
"... crc firmware.bin 0 250 v" does a CRC comparison for every sector in the specified range, showing the remote and local CRCs for each sector in a list.
I have this version as a new branch, based on your flash-by-sector branch. If you want to give me write permission, I'll push it to GitHub.
What did I learn from this exercise? Only that my EV3 is flaky. It consistently reports CRC errors in one of the early sectors (sector 4). It reported errors in some higher sectors too, but they went away after a re-flash.

I had no idea the firmware was being copied to DRAM. I come from a microcontroller background and I assumed the firmware was executed from flash, but you know the EV3 better than me. Your faulty-DRAM theory is plausible, and is supported by some of my observations. I used the sector-by-sector comparison to find a large region of sectors with no errors. If I do a single big-block comparison of that region, I get no errors with smaller blocks (e.g. 100 sectors) but errors with larger blocks (e.g. 150 sectors). That suggests your theory may be right.

Finally, I'd already had the idea of downgrading to version 1.03H but I couldn't find a copy of anything older than 1.05 (which also didn't work). However, after another couple of hours searching I did find a site that had a binary of 1.03H!!! So I flashed it and, amazingly, it actually works. It's still a bit broken, in the same way this brick was broken a week ago: You have to do the three-finger reset sequence to make it boot up, but once it's running it's perfect. My brick is finally un-bricked.

So in the end, I have two usable EV3 bricks now. My kids have already made a caterpillar-track robot with one of them.
Thanks for your help!

[JakubVanek]

That sounds great!

I think the CRC command could be useful in the future. I have added your account as a collaborator to my old development fork at https://github.com/JakubVanek/ev3duder . Feel free to push the branch there if you don't want to create your own fork.

I have some ideas on how to integrate the changes. I think that exposing the newly developed commands as ev3duder advflash install_sector_by_sector and ev3duder advflash check_crc could be a good compromise between having the functionality available and not making the existing ev3duder flash functionality confusing to new users. I will not be able to get to it immediately, but I'd like to eventually do it.

[gtminch]

I messed up the push. GitHub Desktop said I still didn't have write permission to your other fork, so I created my own fork.
Then when I went to GitHub.com it showed me your invitation to collaborate!!! So it all happened in the wrong order, and my branch has ended up in my new fork. I've created a pull request. I hope you can see my code.

I think just keeping it under the "flash" command would be fine. Users can ignore the new functions if they don't understand them - they won't need to use them if the original functions work correctly. BTW I added some help text for the "crc" command. You'll see it in my branch. Maybe "flash install_sectors" would be a reasonable name for your new installation method.

[JakubVanek]

Hello, sorry for suddenly disappearing. I saw the code earlier, but I had troubles getting myself to reply. I have now taken the code, cleaned it up slightly and created #46 and #47 from it. I will try to get access to an EV3 to test it.