8

I work in a management roll and only have a very limited electronics knowledge (enough to make simple arduino projects etc).

We are working on a product at the moment which has 3 STM32F303s and 2 STM32F103s and the main processor being a AM5718.

I was just wondering how you would go about uploading and upgrading the firmware and bootloader one each processor including the AM5718.

The 5 STM32s are connected to the AM5718 via UART and all are on the same PCB.

I would like to get a good idea about how this would be done after the PCB is produced and the product is in the field.

I would obviously ask the electronic engineer working on the project but we have finished for xmas.

Newbie Noob
  • 886
  • 10
  • 27
  • You must not be in the US, because bossman here would just call you up at home.... :/ – Daniel Dec 22 '15 at 22:41
  • Haha you are right, I am in the UK! It isn't such a major issue that it warrants phoning someone at home. Mainly just to satisfy my curiosity and it is also good to get some 3rd party advice! – Newbie Noob Dec 22 '15 at 22:55
  • Hi. If there's an answer that helped you solve your problem, please click Accept on that answer. Thanks. – Armandas Jan 01 '16 at 12:13

3 Answers3

6

If hardware design is done correctly and assuming UART is used for programming, the steps would be roughly as follows:

  1. The main CPU resets a selected MCU.
  2. The CPU then brings the required BOOT pins to an appropriate state and releases the reset.
  3. The MCU bootloader starts and waits for data to come in on the appropriate UART line.
  4. The CPU send the binary data over the UART and resets the MCU when done.
  5. The MCU runs with a new firmware.

Here's an image showing bootloader selection for STM32F10xxx parts:

enter image description here

The same steps would be repeated for each MCU.

The main processor can be updated in numerous ways, but it usually goes like so:

  1. Firmware is downloaded into a local storage (FLASH, RAM, SD Card etc.)
  2. The CPU reboots and the bootloader discovers the upgrade code.
  3. The CPU bootloader reads the data, checks that the binary is valid and programs the appropriate FLASH sectors.
  4. The CPU reboots itself again and loads with the new firmware.

Update.

Based on your current hardware, you'd have to execute the bootloader by jumping to the appropriate memory address (see page 20 of AN2606). I don't know a great deal about this, but your hardware designer should be able to figure it out. Not having the control of the reset line is a bit of an oversight though.

jusaca
  • 8,749
  • 4
  • 36
  • 58
Armandas
  • 7,845
  • 1
  • 32
  • 56
  • So would that require more pins than the 2 USART pins or would the MCUs be connected to the main CPU with via other pins. – Newbie Noob Dec 22 '15 at 21:12
  • I'd hazard a guess that you'd need at least two more GPIOs. One for resetting the MCU and another for choosing the BOOT mode. – Armandas Dec 22 '15 at 21:14
  • What pins would be the reset and boot mode on the MCUs and what pins would they connect to on the CPU? I have tried to look myself but cannot make sense of it. Currently the NRST pins are connected to power via a resistor and the boot pins connected to gnd. – Newbie Noob Dec 22 '15 at 21:27
  • @ProductDesigner given the current connection by resistor and direct connections to ground, you will need a circuit/PCB redesign to accomodate the signals being logic controlled instead, now that you know how it works – KyranF Dec 22 '15 at 21:40
  • NRST is used for resetting and BOOT0 and BOOT1 are used for selecting the boot mode. On the CPU side they can connect to any GPIO. Based on your hardware description, you may have to use a different method to run the boot loader. I'll update my answer. – Armandas Dec 22 '15 at 21:41
  • So would it be beneficial to have control of both the boot pins and the resets? Or just the resets and leave the boot pin as it is and control the bootloader? What would be the ideal setup? – Newbie Noob Dec 22 '15 at 21:50
  • Well it's really up to you and your engineers to decide that. If you can activate the bootloader via the code, then it may make sense to save some signals and routing effort. On the other hand, hardware control is more reliable. Just imagine that the MCU crashed, how would you reset it and tell it to run the bootloader? – Armandas Dec 22 '15 at 21:57
  • Ok thanks for all of your advice. From a hardware point of view how would the pins connect, just a simple connection or would there be pull up/down resistors? – Newbie Noob Dec 22 '15 at 22:14
  • STM32s have a permanent internal pull-up on the reset line, so that's covered. BOOT0 should have a pull-down resistor for normal operation. – Armandas Dec 22 '15 at 22:17
4

I suspect you need to load the AM5718 firmware via JTAG, however I'm not far too familiar with this CPU family.

The STM32 (like many other ARM CPU's these days) have a ROM bootloader built in by ST. On some STM32 series this is done by holding BOOT0 pin high during reset. To boot your normal program you need to hold the pin low. This however is conveniently not always in the datasheet, but often in the user manual.

The ST bootloader often supports several protocols, and UART is a very common one. Not all UARTs or pin locations on the STM32 chip are supported though - so you need to choose the serial port pins. This document is very helpful if you can find the right family.

The procedure Armandas describes is correct. If you have some spare pins on your AM5718 CPU you could automate the activation of ST's bootloader via software. This does cost some GPIO pins on the CPU - in theory 1 additional reset line for every CPU added. You may also need to consider how your board will boot-up in this setup while the AM5718 is not completely running.

A little caveat: on some STM32 parts the ROM bootloader is turned off once you enable read protection. You can still access the chip via JTAG (after erase), but not via the bootloader. Additionally if you cannot make the automated activation seem fit in hardware, you may need to do it manually via jumpers & a paper procedure. This however is only practical to do in the factory - it is not a very field serviceable solution.

Both reasons may steer you towards an in-house bootloader which can be activated via a serial command. It also adds the advantage of 'protecting' of your firmware images via encryption, given that you handle decryption inside the bootloader itself.

Hans
  • 7,238
  • 1
  • 25
  • 37
  • Ok so at the moment I am thinking its best to have the STM32s connected to the main CPU via their own UARTS and have their boot and reset pins connected the the CPU GPIOs. I am not interested in software yet, I just want the hardware design to be future proof. – Newbie Noob Dec 23 '15 at 09:58
4

If all parts are JTAG-compliant, and are all in the same power domain (or otherwise in a state that guarantees chain integrity), you can construct a scan chain and use that to hit each part in turn.

However, it sounds like the project is done and you're in management :), so I think the UART option is the best route. To be clear, each STM has its own UART to the large processor, or do they share (which is a bit odd...)? If the latter, as the other posters said, you'll need one GPIO per to select who is active.

Krunal Desai
  • 6,246
  • 1
  • 21
  • 32
  • The first stage of hardware development is done ready for prototyping. I was just looking through the schematics and was concerned that the STMs are only connected to the main CPU through the UART, their reset and boot pins are connected to power / gnd as above. Each STM is connected to the main CPU via their own UART. So I'm thinking at the moment the best bet is to have each STM connected to the CPU via separate UARTs (as they currently are) and then connect their boot and reset pins to the GPIOs of the main CPU. – Newbie Noob Dec 23 '15 at 09:22
  • Yep, that seems sane. The only thing I would make sure is that your reset chain propagates through the CPU regardless of software state; i.e. when VDD drops below the acceptable threshold, will an internal supervisor take over and trigger reset, or should you run the GPIO control for each STM's reset through a reset supervisor IC. – Krunal Desai Dec 23 '15 at 17:33
  • Ok you've lost me now.. Remember I haven't got a massive knowledge on working on electronics of this scale. So are you talking about having a separate IC for handling the resets? I'm really only interested in getting the hardware right at the moment. – Newbie Noob Dec 23 '15 at 17:40
  • A separate reset supervisor is generally used when you want a stateless hardware element to assert a reset under certain conditions. For example, a 3.3V reset supervisor may be a 5-pin part -- VDD, GND, RST, RST# and MR#. It will assert reset when the voltage gets to 3.08V (or whatever it is set too, some are adjustable) so that all processors / etc go into reset safely before their power supplies drop too far. The MR# pin is something you can hook up to say a push button; it generates a pulse when you assert it and then release, or if you leave it held down, it will keep all in reset. – Krunal Desai Dec 23 '15 at 20:01
  • Would you think that a reset supervisor is necessary in this application? Would it be one ic per processor or just one for the entire system? What would be a good ic to use? – Newbie Noob Dec 23 '15 at 21:11
  • Without knowing more about the application, I'm not sure if it is 100% necessary, but generally if you can afford it, I think it is a good idea to have to protect against potential data corruption or other issues. It will ensure that your system is in a quiescent state when voltage drops too low. We can talk further over email if you'd like to share more details about your product in a less public setting. – Krunal Desai Dec 23 '15 at 21:54