How to reproduce:
- Create a large array that uses a lot of RAM.
- Have a tight-ish loop that constantly changes the values in that array.
- Try to reflash.
This seems to be because the 1200 baud trick doesn’t directly reset the chip but rather turns on the watchdog reset and let it reset the chip 120ms later… and if the baud rate changes again then it turns the watchdog timer off… the comments in CDC.cpp note:
// Most OSs do some intermediate steps when configuring ports and DTR can // twiggle more than once before stabilizing. // To avoid spurious resets we set the watchdog to 250ms and eventually // cancel if DTR goes back high.
From what I can tell the problem is where the magic “bootloader mode vs app mode” flag is stored:
volatile uint16_t *const bootKeyPtr = (volatile uint16_t *)0x0800;
This seems to be 2k into RAM (or perhaps lower if the registers and IO ports are mapped into lower RAM, I forget how the addressing scheme works). Either way what is the point of placing this at 2k… why not at the very top of RAM? Or why not reserve a single byte or two of RAM for this flag. No matter where you put it it seems it risks working incorrectly if the RAM isn’t reserved.
Update: Yeah, looks like SRAM runs from 0x100 to 0xAFF in the address range. “google: (0x800-0x100) in base 10”… Looks like memory location 1,792. What is the logic behind this.
I think @dragula96 has also run into this. Seems like as issue a lot of people are going to hit if we hope for some ambitious software.
Update #2: Looks like this is a known issue: https://github.com/arduino/Arduino/issues/2474