unstable filetransfer for NUCLEO L432KC

[mindforger]

like i describe in my issue on the micropython tracker my NUCLEO L432KC board does not work for larger files with your loader

https://github.com/micropython/micropython/issues/4714

i suspect a bug in the port currently or an issue with the st-link STM32F103 that sits inbetween usb and the actual STM32L432

but through my testing i found out that there are 2 general issues that could maybe made configurable to get it working again

like i described in the linkes issue, i can paste around 374 bytes without any newline (i did not test if carriage return also has effects on it, as i only can paste with newline)

or depending on the line length way less lines, like 14 with 10+1 bytes per line and only 10 with 20+1 bytes per line

if i could define delays and chunk sizes, i could probably work around this issue for the moment or if it is ultimately unfixable in the firmware because of the st-link debugger chip

PS: even the upload.py and donwload.py do not work probably because of this limitation ... i can not compile or test this branch as i can not get pip to work behind this icredibly stupid SSL breaking firewall

[BetaRavener]

Hi. What behavior are you getting with the transfer scripts? If I remember correctly, there should be error message since some version giving more info about what went wrong. However, from the linked issue Damien correctly states that REPL doesn't implement any flow control - that's precisely the reason why transfer scripts exist - they split file into chunks, encode each and send them one by one awaiting acknowledgment from the MCU between each message. Furthermore, these messages should be at most 64 bytes long by default (see here: https://github.com/BetaRavener/uPyLoader/blob/master/src/connection/serial_connection.py#L246), so even if the buffer limitation applies when explicitly using UART library from script, this shouldn't cause the error.

Anyway you are free to change code in any way and see if it helps you. In the linked file you can just change the values for chunk sizes and timeouts. Note that this affects only UART, WiFi is implemented in another class. You need to be running from source code though. I don't know what are your issues with firewall, but if it's preventing you from downloading two packages from pip, maybe just go to some caffee and do it on public wifi? :)

[mindforger]

Haha, yeah public wifi here in most cases is the same issue, those ssl/tsl breaker becoming annoyingly popular and pip is very strict in ssl verification... But i am back on my private internet, so i can finally work on it.

I so not get any specific error, just 0% and the same when using paste mode. I just have to rule out i did not mess up the fs allocation. I may come back zu this tomorrow

[BetaRavener]

Is this issue still relevant or can be closed? Was there any resolution of the problem?

[mindforger]

The increased buffersize for stm32 improved the performance but still it fails every now and then. The stlink controller seems to be the culprit. Thank you anyway