If there was a product with 5 MCUs (STM32303) and a main CPU being a AM5718, how would the bootloader be uploaded to each chip?
The same question about the firmware how would the firmware be uploaded to each.
Would it be done before the chips are soldered, would there be pads on the PCB for probes or something else?
Im only interested in what would happen in production. Any upgrading and uploading in the future would happen via the main CPU through UART
I worked on a product that had a total of seven MCU's in it. The design we did included a two wire serial bus implemented as RS485 that went multi-dropped to each MCU board and terminated at the TxD and RxD lines of each of the MCU's UARTs.
Each MCU was programmed with a boot loader that would respond to RS485 traffic that could support re-programming the "application code" FLASH of the MCU. Entry into the boot loader mode at power up was controlled by the analog voltage on a certain A/D input. Under normal system operation the pin would read near GND. Something between 2.5 and 4V would be seen as a "calibration mode" whilst an A/D reading over 4.5V was used to signal the boot loader mode. The A/D inputs were biased via a voltage divider so that the externally applied voltage on the CAL/BOOT wire externally had to be over 20V to get into the boot loader mode. This analog signal wire was also bussed to all seven of the MCUs.
An external PC was equipped with a special firmware update utility that could control the CAL/BOOT signal and then sequentially interact with each MCU over the RS485 comm link to perform the software updates. That same computer was also setup with a specialty calibration utility that used the same RS485 comm link to perform calibration and performance data logging for the product.
Note that since all MCUs were the same chip family from the manufacturer the same exact boot loader code was used in all of the MCUs. The MCU's were preloaded with the boot loaders by a programming service at the electronics distributor. The product application code was loaded into each MCU at initial board level test to save time over having to do it at product level functional test. Any subsequent update was done to the product level package without having to open anything up.
One last comment is that each MCU in this family of controllers could be in-circuit programmed via a SPI type interface. We provided pads on each circuit board that could be accessed via pogo pins on a board fixture that gave access to this interface. Through that it was possible to re-program the completed FLASH of the MCU including its boot loader. Once the seven MCUs were in place in the full product this access mode was no longer available because all the electronics boards were potted.
In a project I worked on about a year ago, the MCU was a USB 2.0 host and thus there was a USB connector on the board to connect it to peripheral devices. Although the processor was limited to USB 2.0, I designed in a USB 3.0 connector which has five extra wires. I used this to program the MCU via an ICD (in-circuit debugging) interface.
The circuit was normally disabled (so if someone plugged in a real USB 3.0 cable no harm would be done), but was enabled using a specific voltage over the GND_DRAIN lead (pin 7) of the USB 3.0 interface (inside cables GND_DRAIN is not connected to the main GND pin 4).
Enabling the interface (using a comparator) switched four wires of the ICD interface via a 4066 quad analog switch. The fifth wire (ground) used the normal GND lead of the USB 2.0 interface.
The programming was done at the factory in China using special test fixtures I designed which were also used to do board level testing. Afterward, the board could still be reprogrammed via the same connector. After the units were in the field, since they had a GSM modem in them they could be updated using FOTA (firmware over the air).
