[STM32G0C1] Intermittent Failure of System Bootloader on FDCAN1 (Multi-node network)

[francescopanini]

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:

1. Reconfiguration: The Master sends a global command. All nodes switch their FDCAN configuration to 250k (CAN FD) and enter Listen-Only Mode.
2. Trigger: The Master then sends a specific SDO command to a single target node to trigger a jump to the System Bootloader (System Memory).
3. 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

[mƎALLEm]

Hello @francescopanini and welcome to the ST community

I have two questions:

1- Did you check your soldering joints?

2- At which temperature range you are performing the test?

3- What is the number of the tested devices? what is the number of the failing devices?

[francescopanini]

Hello, 

We assembled 100-ish boards, all of which were by our assembly line, so not manual. I have tested this functionality on only 32, of which 3 have been found faulty. The swap tests I was referring to, though, have been performed manually by a trained operator. You suggested a good test, we haven't thought to inspect the soldering, both visually and via X-ray... we will do that for sure. 

All the tests have been performed at room temperature

[mƎALLEm]

Ok thank you for the feedback.

---

@francescopanini wrote:

All the tests have been performed at room temperature

---

Could you please estimate what room temperature you have? 

[francescopanini]

@mƎALLEm thank you for the quick followup. The temperature swings between 22 and 26 degrees Celsius according to the sun irradiation to the lab's glass windows.