I can't program my STM32 through bootloader on a CAN Network, even though it works with a single target connected on the bus.

[Zephyr S]

Hi all, 

I use 2 STM32F446RE boards. They communicate with a CAN bus.

I get a little code that allows my boards to enter boot mode when it receives a frame with a specific ID.

When one enters in boot mode, using a third board, I send a frame with ID 0x79.

But instead of answer me an ACK (0x79), it leaves the boot mode.

When I send the frame with ID 0x79, the second board (not in boot mode) receives the frame (but has not to treat it) and transmit a little bit on CAN2_Tx. Even if it's not detectable using a sniffer CAN, I saw it using a scope.

Just to make it clear, it works when I got only one target to re program on the bus.

How can I avoid the board to react and interfere with the other ?

Kind regards

[NathanWolcott]

I vaguely remember looking into the CAN bootloader several years ago for a project. I don't remember the exact details but we more or less decided it was pretty close to useless given the requirements in the documentation. I don't think there can be any other clients on the bus (just the programmer and the device getting programmed). We concluded that we could either wire up a hardware reset line so that the programmer could hold all but one device in reset. Alternatively, we could have a special command that would go out on the bus before starting programming and have all the other devices drop off the bus, either for a preset amount of time or switch to passive monitoring mode, etc. Then program one device (which should work now that everybody else is off the bus or passive), then send out a command to wake everybody back up (if they are monitoring) or wait until their timers wake them back up.

Ultimately, we decided to just write our own custom bootloader that could handle being on an active CAN bug. In the end, the whole project was canceled before that part was written, so I can't tell you how it worked out.

[Javier1]

And here i am with the same bug 2 years later, facing the same choices.For some reason the bootloader expects that first 0x79 to be NACKED maybe a cruel unfortunate way of checking if they are the only ones in the bus.