Recently, I thought it would be nice, if the CANtact USB-CAN adapter (which features a STM32F042 Cortex M0-based MCU) could start the USB firmware download procedure without me having to phyiscally place a jumper on the board’s BOOT pin (see also: GitHub issue #9). That way one wouldn’t have to open up the case every time a new firmware is available.
Commit 59b2813 implements a function jump_to_st_usb_bootloader(); which should do just that and can be invoked via USB. For some reason though, the adapter still won’t register on the PC as a USB DFU device. Instead it reboots into the regular firmware.
Why is that?
Regularly, the MCU maps either the so called „System Memory“ ROM i.e. the USB DFU bootloader at 0x1fffc400 or the regular firmware memory at 0x08000000 to address 0x00000000, depending on whether the jumper on the BOOT pin is present or not. That way stack pointer and vector table are set accordingly and the corresponding reset handler service routine is executed.
The system configuration register SYSCFG->CFGR1 allows to remap those memory areas after startup and I confirmed, that after the corresponding call in line 38 the memory at address 0x00000000 changes and afterwards reflects the ROM content. I also confirmed, that the processor’s stack pointer register is changed to the new value after the call in line 41 and that after line 49 code execution jumps to the ROM address range. Since the bootloader is not Open Source, unfortunately, I was unable to debug the issue any further from that.
What could be the issue?
- Does the bootloader re-sample the BOOT pin and exit, if it has an unexpected value?
- Does the bootloader have trouble with settings made to peripheral registers in the regular firmware?
- I tried to rule this out by invoking jump_to_st_usb_bootloader(); in the main(); before performing any hardware initialization – the issue persists.
- Is it an exception that triggers the MCU reset or is the reset invoked on purpose?