Question
[STM32G0C1] Intermittent Failure of System Bootloader on FDCAN1 (Multi-node network)
I am developing a multi-node system (16 nodes) based on the STM32G0C1MET6. During normal operation, all nodes communicate at 500k (Standard CAN). To perform a firmware update, the Master initiates the following transition sequence:
- Reconfiguration: The Master sends a global command. All nodes switch their FDCAN configuration to 250k (CAN FD) and enter Listen-Only Mode.
- Trigger: The Master then sends a specific SDO command to a single target node to trigger a jump to the System Bootloader (System Memory).
- Reflash: Once in Bootloader mode, the target node is expected to respond via FDCAN1 (as per AN2606/AN5405) to begin the reflash process. The Master repeats this node-by-node.
The Issue: While most nodes perform the jump and reflash successfully, some specific units enter the bootloader (confirmed by status LEDs) but never respond to CAN messages. These units appear "deaf" to the Master's CAN FD frames at 250k.
Environment:
- MCU: STM32G0C1MET6
- Interface: FDCAN1 (Pins: PD0/PD1)
- Transition: 500k Standard CAN -> 250k CAN FD (System Bootloader)
- Hardware: Custom board with CAN transceiver.
void JumpToBootloader (void)
{
uint32_t addr = 0x1FFF0000;
__disable_irq();
// 1. Reset hardware periferiche usate (FDCAN in particolare)
__HAL_RCC_FDCAN_FORCE_RESET();
__DSB();
__HAL_RCC_FDCAN_RELEASE_RESET();
// 2. De-init RCC e SysTick
HAL_RCC_DeInit();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;
// 3. Remap e VTOR
__HAL_RCC_SYSCFG_CLK_ENABLE();
__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();
SCB->VTOR = 0;
// FLASH->ACR |= FLASH_ACR_PROGEMPTY;
// 4. Jump
__set_MSP(*(volatile uint32_t*)addr);
void (*SysMemBootJump)(void) = (void (*)(void))(*(volatile uint32_t*)(addr + 4));
SysMemBootJump();
}
Tests Conducted & Observations
1. MCU Swapping:
- Scenario A: Replacing a "failing" MCU with a new one on the same PCB often resolves the issue.
- Scenario B: A "failing" MCU moved to a known-good test board sometimes works correctly.
2. Signal Integrity: We compared RX/TX signals (pre and post-transceiver) between working and non-working nodes using an oscilloscope. The waveforms are clean and virtually identical.
3. Peripheral Isolation: To avoid the bootloader auto-detecting the wrong interface, we isolated/pulled-up other boot-capable pins (UART, I2C, SPI) where possible.
4. Hardware Entry (BOOT0): To rule out software jump issues (stack pointer, caches, or clock debris), we tested entering the bootloader via the BOOT0 pin. Even with a hardware-triggered entry, the problematic units still fail to respond on the CAN bus.
Any suggestions on how to debug the internal state of the Bootloader or test/fix I can try? Any suggestion is appreciated. Thank you