2023-05-30 05:42 AM - edited 2023-11-20 04:22 AM
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:
Questions:
2023-10-27 10:01 PM
Did you have any luck with this? I'm struggling with the same issue.
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.
2024-02-06 06:30 PM
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.