cancel
Showing results for 
Search instead for 
Did you mean: 

How to flash STM32H725 using FDCAN Bootloader?

1080P
Associate

I went through the following documentation available from STM on FDCAN bootloader:

AN5405 - FDCAN protocol used in the STM32 bootloader

AN2606 - STM32 microcontroller system memory boot mode

rm0468 - Reference manual

Jump to bootloader code used:

(Reference link : https://community.st.com/s/article/STM32H7-bootloader-jump-from-application)

void ASYSTR_jump_to_bootloader(void)

{

uint32_t i=0;

void (*SysMemBootJump)(void);

/* Set the address of the entry point to bootloader */

volatile uint32_t BootAddr = 0x1FF09800;

/* Disable all interrupts */

__disable_irq();

/* Disable Systick timer */

SysTick->CTRL = 0;

/* Set the clock to the default state */

HAL_RCC_DeInit();

/* Clear Interrupt Enable Register & Interrupt Pending Register */

for (i=0;i<5;i++)

{

NVIC->ICER[i]=0xFFFFFFFF;

NVIC->ICPR[i]=0xFFFFFFFF;

}

/* Re-enable all interrupts */

__enable_irq();

/* Set up the jump to bootloader address + 4 */

SysMemBootJump = (void (*)(void)) (*((uint32_t *) ((BootAddr + 4))));

/* Set the main stack pointer to the bootloader stack */

__set_MSP(*(uint32_t *)BootAddr);

/* Call the function to jump to bootloader location */

SysMemBootJump();

/* Jump is done successfully */

while (1)

{

/* Code should never reach this loop */

}

}

Observations:

  • I think the system is maybe entering the boot mode because the SP is updating to a value around 01FF12xxx in the function ASYSTR_jump_to_bootloader
  • FDCAN bit rates are reflecting different from what is mentioned in the documentation
  • Documentation: bit rates = 0.5Mbps


_legacyfs_online_stmicro_images_0693W00000bl8iSQAQ.png

  • Implementation: Nominal bit rate = 0.25Mbps / Data bit rate = 1Mbps


_legacyfs_online_stmicro_images_0693W00000bl8iwQAA.png 

Questions:

  1. It was unclear whether the FDCAN peripheral needs to be configured as per the documentation or is already configured when the system enters boot mode?
  2. The bit parameters and the resultant bit rates of the boot mode FDCAN configuration is not matching. Could it be a documentation fault? If so, what are the correct values?

2 REPLIES 2
anotherandrew
Senior

Did you have any luck with this? I'm struggling with the same issue.

  • AN2606 says 500k, AN5405 says 250k/1M
  • stopping the core while running the bootloader confirms 250k/1M based on 20MHz clock
  • verified PD0/1 are set up for AF9 (also PH13/14, but those pins don't exist on my package)
  • tried setting PH13/PH14 to GPIO (input) instead of AF9 by stopping the bootloader, changing, continuing, no change.
  • tried sending 0x111 with DLC=0, DLC=64 (AN5405 says ID must match filter1 exactly) with BRS set, also tried 0x000 (get version command), DLC=0, DLC=64, also tried 0x79
  • tried sending extended ID 0x111, 0x000
  • tried sending a few frames of EVERY standard ID

I then re-ran everything when I remembered something from the standard/classic CAN bootloader saying that it *must* see an 0x79 frame NOT acknowledged before it'll acknowledge (put the can sniffer in listen-only mode so it would not ACK) ... no change.

It's tremendously frustrating that STMicro does not respond to any of the messages about this on the forum and their documentation is in disagreement with itself.

Replying to myself here.

from my other post here , the steps I took to get responses from the bootloader:

# configure the CANFD driver on Linux:
sudo ip link set can0 up type can bitrate 250000 sample-point 0.75 sjw 16 dbitrate 1000000 dsample-point 0.75 dsjw 4 fd on

# monitor the CAN bus (in a different window/tab):
candump -tdex can0

# send a standard (11-bit) CANFD frame with BRS set, ID=000 and a 64-byte payload:
cansend can0 000##100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

# it is important to note in the command above the double-hash (##) which tells cansend that this
# will be a CANFD packet, and then the single '1' before the 64-byte payload which sets the Bit
# Rate Switch (BRS) switch in the outgoing packet.

# observe the CAN traffic in the candump window:
(179.707038) can0 000 [64] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(000.001531) can0 000 [01] 79
(000.000025) can0 000 [01] 0B
(000.000009) can0 000 [01] 11
(000.000009) can0 000 [01] 00
(000.000007) can0 000 [01] 01
(000.000008) can0 000 [01] 02
(000.000008) can0 000 [01] 11
(000.000008) can0 000 [01] 21
(000.000008) can0 000 [01] 31
(000.000999) can0 000 [01] 44
(000.000012) can0 000 [01] 63
(000.000006) can0 000 [01] 73
(000.000005) can0 000 [01] 82
(000.000006) can0 000 [01] 92
(000.000006) can0 000 [01] 79

 It is definitely 250k/1M, and I am suspecting that the sample window/jump settings are important (I have not yet tried without them explicitly set). I am also using the flag value of 1 which should set the Bit Rate Switch flag on the outgoing CAN frame.

The bootloader seems kind of picky and can hang/crash if it's tickled the wrong way.