Thing+ Bootloader "Magic Reset" Address Doesn't Match Chip Definition

I was trying unsuccessfully to enter bootloader mode through software using:

	#define DOUBLE_TAP_MAGIC    0xf01669ef
	#define BOOT_DOUBLE_TAP_ADDRESS     (HSRAM_ADDR + HSRAM_SIZE - 4)

        *(volatile uint32_t*)BOOT_DOUBLE_TAP_ADDRESS = DOUBLE_TAP_MAGIC;

	NVIC_SystemReset();

After disassembling the bootloader file in Ghidra I found out that it looks for a different address (0x30000) than is defined in the samd51j20a.h file (0x40000). The 0x40000 should be correct, since it says it has 256k of SRAM. To be able to do the “magic reset” on these boards without burning a new bootloader, either use “0x30000” instead of HSRAM_SIZE, or do “HSRAM_SIZE - 0x10004”

Thanks for the input! We have forwarded this to our engineering team.

I can confirm this issue in the [current Thing Plus bootloader. This issue breaks automatic upload of sketches using bossa (the unit resets due to the 1200 baud knock, but continues booting instead of entering the bootloader). Double-tapping the reset button works fine for entering the bootloader, but is a hassle for iterative development.

The [Sparkfun Arduino samd core reset code sets the DOUBLE_TAP_MAGIC value at the correct address: 0x2003fffc.

download/file.php?id=6881

But the bootloader looks at the wrong address as @shalebridge described: 0x2002fffc

download/file.php?id=6882](Arduino_Boards/sparkfun/samd/cores/arduino51/Reset.cpp at master · sparkfun/Arduino_Boards · GitHub)](https://github.com/sparkfun/Arduino_Boards/blob/main/sparkfun/samd/bootloaders/SAMD51/bootloader-sfe-samd51-thing-v2.0.0-34-ga8591b7-dirty.bin)

I manually patched the double-tap address in the bootloader and the updater binary. I was very careful to double-check all changes and verify with Ghidra, but updating bootloaders is inherently risky and you may want to think twice if you don’t have an SWD debug interface to recover in case of an issue. I successfully updated one of my Thing Plus boards and it’s now working as expected.

I’ve attached the patched bootloader to this message and I’d be happy to submit a PR to the [Sparkfun Arduino repo or the [Thing Plus repo – different Sparkfun products seem to manage things differently, so it’s not clear to me where this change actually belongs.

It appears that this issue was caused by the bootloader being built for SAMD51J19A (192KB SRAM) instead of the SAMD51J20A (256KB SRAM) which is the part that’s actually on the Thing Plus board.

To update:

  • - Plug your Thing Plus into your computer.
  • - Double-tap the reset button to reset into the bootloader.
  • - The board should show up as a mass-storage device called **51THINGBOOT**.
  • - Check the **INFO_UF2.TXT** file. The first line should be **UF2 Bootloader v2.0.0-34-ga8591b7-dirty SFHWRO**.
  • - Drag **update-bootloader-sfe-samd51-thing-v2.0.0-34-ga8591b7-patch.uf2** onto the **51THINGBOOT** device.
  • - The board will reset.
  • - Double-tap the reset button again to enter the bootloader.
  • - Check the **INFO_UF2.TXT** file. The first line should now be **UF2 Bootloader v2.0.0-34-ga8591b7-patch SFHWRO**.
  • ](https://github.com/sparkfun/SAMD51_Thing_Plus)](https://github.com/sparkfun/Arduino_Boards/tree/main/sparkfun/samd/bootloaders/SAMD51)

    bootloader-sfe-samd51-thing-v2.0.0-34-ga8591b7-patch.zip (101 KB)

    Go ahead and submit it on the Thing Plus repo https://github.com/sparkfun/SAMD51_Thing_Plus :smiley:

    :blush::+1:

    https://github.com/sparkfun/SAMD51_Thing_Plus/pull/2

    I stumbled over that bug this morning, and so I had to add an extra definition for it. So the workaround works with the boards currently in the field, and will fail later.

    So Vynce’s work on fixing that value has finally been pulled into the main branch, which now includes the uf2 bootloader directly. I have also included the new uf2 folder with the reset fix in our SparkFun SAMD Arduino Board release v1.8.13.