Programming arrays of STM32 MCUs

[MikeDB]

Still struggling with this so hopefully somebody can help me.

As far as I can work out the STM32(H7s if it matters) need three pins (TCK, TMS & NRST) plus a common ground to be programmed from another MCU. I can't dedicate three pins on the master processor to each slave but I can't find a sort of 'programming chip enable' arrangement to allow me to address all the slaves one at a time on a bus arrangement as I would do with say Atmel or other MCUs.

Fortunately I don't need SWO debug or that would be yet another pin.

If a bus arrangement is possible, can somebody point me in the right direction please ?

Thanks in advance

[Tesla DeLorean]

JTAG can be used where devices daisy chain into each other.

[waclawek.jan]

You can also share clock and reset, and have individual data. This consumes more pins on the master but less pins on individual mcus, if this matters.

You of course can have your bootloader arranged in each chip and then it's a matter of your imagination, a single pin should generally suffice.

JW

[MikeDB]

Hi Jan - do you mean a custom bootloader I put in each MCUs Flash ? I can't find any option in the System bootloader that uses a single pin in the way SWIM does on STM8s or UPDI does on Atmels.

Thanks

[waclawek.jan]

> do you mean a custom bootloader I put in each MCUs Flash

Yes, that's what I meant - if the production process allows for this.

JW

[Tesla DeLorean]

You could drive the USART based system loader blindly, or use the response from one to guide your timing.​

[MikeDB]

Each MCU has a different codeset so not sure that would work. Been looking at the I2C bus which is addressable as probably the best way forward. I have to say STM documentation is a bit vague in places on something as important as programming the devices. I suppose most people use ST-Link and never worry about it.

[Tesla DeLorean]

People using SWD/JTAG tend to use existing pods, or understand the ARM protocols in use, as they aren't ST specific. If you're building a board with a huge array surely boundary scan would be employed to pin down failure within the nodes. Building something that's testable would get you to a destination that would be readily programmable. I'm not convinced this is an ST vs ATMEL vs NXP issue.

CAN bus would be faster than I2C

If devices are all addressable, and know their identity, push common code into RAM/FLASH, and then second stage the device unique stuff, or allow the nodes to extract data aimed at them from the stream.

Programming the devices is the 1ppm case in most applications, I think people are expected to have enough domain knowledge to find a solution that works for their own specific use cases. ST's loader has 12 years of docs and history behind it.

[MikeDB]

There is a mesh in place for inter-processor communication using the SAIs so any fault would soon be indicated to the master and it will simply move the problem to a different processor. But you can't program flash through the audio ports and as the board is already pretty full of the wiring mesh of the SAI ports I was after the minimal tracking solution. CAN bus would be faster but isn't supported by the system bootloader making it a two stage process and more tracking.

[waclawek.jan]

> But you can't program flash through the audio ports

Certainly not using the "native" methods (SWD/JTAG/built-in bootloader), but... Well, again, would you have a custom bootloader in place (programmed during manufacturing using whatever tools available, possibly bare chips before placing them on the board) - well then probably it's just logical to use existing interconnections, whatever they are...

JW