cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 Possible to disable CAN bootloader?

LLawr.1
Associate II

I have a product that contains 2 STM32F405/07/15/17 series MCUs. There are 2 because we need 4 CAN and that's cheaper and easier than finding a 4 CAN MCU. Anyways, the main MCU is connected to the secondary MCU via UART and the boot/reset pins so that the main can update the secondary via the built in bootloader. This works fine in most cases, except for when the CAN2 of the secondary is connected to an active CAN network, the bootloader seems to detect a CAN frame, triggering the CAN 'branch' of the bootloader, before I am able to trigger the UART 'branch' of the bootloader. As soon as I release the reset pin on the secondary I start spamming the 0x7F learn byte (@57600 baud), but that doesn't seem to help if the bus is any busier than about 2 CAN messages/sec, which in practice it is busier.

 

Obviously the easy way would be to just not have that CAN2 on the secondary connected to a bus, but the product gets installed into a vehicle and disconnecting that bus is not always trivial. I had never considered the CAN portion of the bootloader would give me issues, but hindsight being 20/20 I would have pinned the RX to PB12 instead of PB5, but I have a few hundred out in the wild so I have to try and make it work. Are there any software solutions here that could help me circumvent the CAN bootloader?

2 REPLIES 2
TDK
Guru

> Are there any software solutions here that could help me circumvent the CAN bootloader?

Unfortunately not. The bootloader is in ROM and can't be changed in any way.

Your options are to make your own bootloader, redesign the board, or disable the interface while in the startup of the bootloader somehow.

If you feel a post has answered your question, please click "Accept as Solution".

Why do you think the bootloader is affecting here?

The bootloader is just active if the BOOT pin is configured. Otherwise, all MCU should jump directly to your own MCU FW code.

It should be something else, e.g. one MCU booting faster as the other, acting on CAN... I do not think it is the bootloader in the chip (which should never be active if BOOT is set properly).