Clone master chip firmware onto slave chip.

[TDK]

Posted on April 14, 2015 at 21:38

In my application, I have a master chip and a slave chip, both identical STM32F407.  From the master chip, I would like to flash the slave chip so that it has the exact same firmware as the master chip.  From my understanding, this means cloning the contents of the flash onto the slave chip.  (Right?)  I do this with the following:

• Put slave chip into system bootloader mode.  (I do this programmatically, but shorting BOOT0 on startup produces the same results.)
• Use USART1 to write relevant flash to slave chip...
  • I directly copy from the master chip memory 0x08000000 to the slave using the WRITE MEMORY command.  Everything checks out and I get the ACKs saying it worked.
  • I then send the slave the GO command to start executing at 0x08000000, which is where my code lies.  I get an ACK and the slave restarts.
• When the slave restarts, it doesn't respond.  (The correct behavior would be that it responds to various commands over the USART1 bus and some LEDs should flash.)

I can't figure out why this isn't working.  Do I need to erase or modify the RAM or something else on the chip as well?  Or is there something special I need to do at the beginning of the flash for this to work?To debug, I've done a few separate things to verify the steps I'm doing.

• When in the bootloader, sending the GO command alone without modifying the flash gives the expected result (slave is responsive), so the GO command seems fine.
• Instead of copying the entire FLASH, I've also just written a single byte, and can verify on the slave chip that it was indeed changed.  so the WRITE MEMORY command seems fine.
• If I flash the slave chip directly using ST-Link, it all works.  So something is different between what I'm doing and what ST-Link is doing.  I'm guessing it's a lack of understanding on my part.

Any ideas?  Many thanks.

[Tesla DeLorean]

Posted on April 14, 2015 at 22:46

I'd do a couple of things, I'd have code right at the ResetHandler entry to signal if it got there, perhaps set a GPIO/LED. I'd be very careful about being agnostic to reset conditions, the System Loader may call with the PLL running, perhaps even a WATCHDOG. Check the memory mapped at ZERO, and the vector table setting (SCB->VTOR)

What's the state of the BOOT0 pin when you do the GO?If I could get the GPIO/LED working in assembler, next I'd try configuring the clocks (HSI), gpio and usart in assembler to get a ''Hello World!'' type response. With a USART working I could push out whatever diagnostics I needed about the state of the chip, and the peripheral registers to understand why it couldn't get to SystemInit(), and later main().

[TDK]

Posted on April 15, 2015 at 00:09

clive1, thanks for the response!

The BOOT0 pin is low (unconnected) during the GO command.My knowledge and skill with assembler on the STM32 is limited, so I may try a few other things before messing with ResetHandler.It seems like manually power cycling after programming instead of issuing the GO command may also yield something useful.Okay, off to try some more things.  I'll report back if I find the issue.

[pmoore]

Posted on April 22, 2015 at 18:51

Tim:

I do this, but with F303, F100, and/or F051 parts as F407 slaves.  I use two extra GPIO pins from the master for each slave beyond the TX and RX USART pins: -One F407 GPIO pin configured as Push-Pull drives the slaves BOOT0 pin (for safety, I also have a 22K to 0V connected to the BOOT0 pin).  You never want the BOOT0 pin to float. -One F407 GPIO pin configured as Open Drain drives the slaves RESET pin (for normal slave reset functionality, I also have a 2.2K to Vdd connected to the RESET pin). Once I figured out the USART bootloader on the F303 did not function on the early date code parts, this has always been rock solid. -Patrick

[TDK]

Posted on April 24, 2015 at 04:32

Patrick,

Thanks for the notes.I somehow missed needing a pulldown on BOOT0.  Thank you for pointing that out.  I'll have to fix that on the next rev.  Regardless, that wasn't the issue here.  Odd that it needs a pulldown if NRST can be left floating, but I'm sure someone smarter than me knows the reason.After going back through it, it seems that I miscalculated the length of the flash being used, so I was only partially programming the slave.  This was easy to see when I used the ST-Link tool to compare HEX files on a reflashed slave versus the master.  Once I fixed that, it all worked. :)For my config, I'll have up to 30 or so slaves and no extra GPIO pins, so I can't use any other pins.  I'm using the USART1 stream to communicate between the masters and slaves.  I use the 96-bit unique ID, an ADC channel, and some coding magic to identify each one individually.  I really really wanted each slave to be absolutely identical in hardware and firmware for ease of use, but still need to differentiate each and be able to address them individually.  Works well so far.Regards,Tim

[pmoore]

Posted on April 27, 2015 at 19:28

Tim:

Please keep in mind that NRST is not floating in any of the STM32Fxxx parts that I'm aware of.  There is a weak pull-up resistor internally, so you can have a valid power-up reset event in most typical applications by just adding an external cap to 0V on the NRST pin.  ''The NRST pin input driver uses CMOS technology. It is connected to a permanent pull-up resistor...''  Pull-up value is specified as roughly 40K +/- 10K and an external cap value of 0.1uF is suggested. I sometimes add an external NRST pull-up to my applications to help prevent application and environmental noise from falsely triggering the NRST line, as my applications are industrial, but this is not normally needed.  In the case of a master controlling a slave's NRST, adding a series resistor between the master's GPIO pin and the slave's NRST pin, as well as retaining the slave's 0.1uF cap, helps protect the slave's NRST pin from any high speed pulses that might occur on the master's GPIO interface as ports are reconfigured.  (Yes, one can mostly manage this by careful coding, but in a world of ''canned'' hardware abstraction layers, more programmers than ever are not directly coding GPIO ports.)  This also can vastly reduce peak current flow (and thus noise) when the master GPIO interface discharges the slave's NRST capacitor. -Patrick