feat(flash): Switch to sector-by-sector flashing

[JakubVanek]

This flashing flow has some advantages:

• It is more interactive - the long erase command is avoided
• It seems to be less sensitive to hardware malfunctions. See issue Doesn't detect EV3 under Windows #45 where this mode was used to flash an EV3 brick with what looks like faulty RAM.

As some functions are now called repeatedly, I tried to go through them and eliminate the memory leaks in them.

I have not yet tested this new code myself, so I have created this as a draft PR for now. This is also rebased on top of #46 because I've moved the FLASH_* macros to the funcs.h header.

[JakubVanek]

There is something wrong with this and I am not certain what is it. When I flash the 1.09E firmware using this branch, one sector comes out consistently corrupted:

Sector   4: Remote CRC = 689F13E1, local CRC = D3CF1A60 ERR

[JakubVanek]

The flashing speed is slightly lower, but it still seems acceptable.

• Original bulk programming approach: 2 minutes 4 seconds
• New piecewise programming approach: 2 minutes 24 seconds

[JakubVanek]

There is something wrong with this and I am not certain what is it. When I flash the 1.09E firmware using this branch, one sector comes out consistently corrupted:

Sector   4: Remote CRC = 689F13E1, local CRC = D3CF1A60 ERR

Things are getting more weird: even programming the brick using the original code produces the same (mismatching) remote CRC.

[JakubVanek]

The CRC issue is not visible when I flash the 1.10E firmware, only when I flash the 1.09E firmware.

[JakubVanek]

Whatever the problem with sector 4 is, it is reproduced by flashing the brick via the classic EV3 software app on Windows and so it does not look like a bug in ev3duder.

[JakubVanek]

The code seems to work OK against a real brick after all.

[JakubVanek]

I think I know what the problem with sector 4 in firmware 1.09E was. The sector is matching before the brick is first rebooted out of firmware update mode. This would indicate that U-Boot has its environment block there. The available U-Boot sources indicate the same: https://github.com/mindboards/ev3sources/blob/78ebaf5b6f8fe31cc17aa5dce0f8e4916a4fc072/extra/uboot-03.20.00.13/include/configs/da850evm.h#L176

[dlech]

You might find pybricks/pybricks-code#2356 interesting.

I did a bunch of testing today (with Pybricks Code, not ev3duder - but the same ideas) and my conclusion is that the probability of ERR_USBLOOP depends on how long it takes to execute a bootloader command. I would occasionally see that error with a FW_DOWNLOAD_DATA command with a payload size of 384 bytes (This is what is left at the end of a 64KiB page. 65536 % 1018 = 384.)

With a bit of creativity, I was able to avoid commands of that size or smaller and so far haven't seen a ERR_USBLOOP with that approach.

I haven't done anything with CRC yet though. It could be interesting to use that to see what firmware is already on the EV3 and avoid re-flashing identical sectors. Based on the code here, it looks like that suffers from ERR_USBLOOP as well. So I wonder if checksum commands for larger sizes would take longer and avoid the bug.