I think I spotted the problem: my application uses Teensyduino EEPROM and that emulates EEPROM in the T41 flash chip, also at/near the top of the flash memory. Therefore, the FlashTxx.c concludes that my original codespace was as big as the entire flash rom. It thus finds not enough (zero in my case) space for a buffer in flash - because that code assumes anything != 0xffffffff from top of flash downwards is the tail of the code.
Once any program ever wrote something in top of flash of the Teensy, any subsequent program download with FlasherX (using flash buffer) will fail. The only workaround in my case was a complete Teensy41 'wipe' reset (reset switch down 15+ seconds so that flash is erased fully, and restored with the default led blink code). Looking at the memory regions picture on https://www.pjrc.com/store/teensy41.html I think the same problem will surface when using LittleFS... Not sure if the 'Restore Program' at the very top of the flash is also a risk.
Luckely there's the RAM buffer option with T41. So I better use that from now on.
For a next release, maybe add a check on buffer_size and refuse to run update_firmware if the buffer_size passed as argument to it is zero?
And not use '1' or '2' for user entry options (Serial, SD) because Intel hex format throws those same characters while it keeps attempting to finish an upload.
Plus some Delay(500) lines prior to any REBOOT; so that user can see and carefully read the error messages if any are there.
Once any program ever wrote something in top of flash of the Teensy, any subsequent program download with FlasherX (using flash buffer) will fail. The only workaround in my case was a complete Teensy41 'wipe' reset (reset switch down 15+ seconds so that flash is erased fully, and restored with the default led blink code). Looking at the memory regions picture on https://www.pjrc.com/store/teensy41.html I think the same problem will surface when using LittleFS... Not sure if the 'Restore Program' at the very top of the flash is also a risk.
Luckely there's the RAM buffer option with T41. So I better use that from now on.
For a next release, maybe add a check on buffer_size and refuse to run update_firmware if the buffer_size passed as argument to it is zero?
And not use '1' or '2' for user entry options (Serial, SD) because Intel hex format throws those same characters while it keeps attempting to finish an upload.
Plus some Delay(500) lines prior to any REBOOT; so that user can see and carefully read the error messages if any are there.