Production loading of code into a ST 32F417

[peter-h]

The obvious way is to have a laptop running Cube IDE and a STLINK debugger connecting via spring-loaded probes (I already have such a fixture built for the SWD connection) and pressing this button





How would this be done with just some "box" which does this? A laptop is actually ok for small batches... but at work we program thousands of little Atmel-AVR-CPU products and these are done with a dedicated box (we are using an ancient Equinox FS2000) driving the spring-loaded probe setup.

Is there such a box for the 32F4 into which you just load the .elf file and which has a PROGRAM button on top?

[woofy]

I can't speak for ST, but we use a lot of PICs, and for volume production we buy them pre-programmed from Microchip.
Maybe ST offers a similar service?

[pigrew]

One option is the Segger Flasher.

I also imagine you could setup another micro to flash it. In that case, I would use the MCU's bootloader (UART or SPI) instead of JTAG.

ADDED: Are you considering doing a production test at the same time? Perhaps whatever production test tool you're using could flash the MCU (through either JTAG or the bootloader)?

[HwAoRrDk]

Ar the very least you'd probably want to use STM32CubeProgrammer rather than the IDE, would you not?

[peter-h]

Aha - that Segger flasher looks just right. I recognise the Segger pricing too from a mile away - must be good, eh

The ST programmer is also good and more idiot-proof than a Cube setup, although it still needs a laptop, and if you are using a laptop then it is simpler to just duplicate the development setup on that laptop.

Yes one could do it with another CPU but that's hard work, yet another bit of kit to document and maintain, potentially over many years.

There is indeed a "production test" which will probably be done via a menu presented on a serial port, interacted with Teraterm on a laptop. One could also do it over ETH with a browser client but a) if ETH is dud then you cannot do anything and b) the target code is a lot more convoluted, and maybe not possible if I want the factory test to be contained in what space is left in the 32k "boot block".

[AndyC_772]

The older ST-Link utility supports that chip and is smaller, lighter and (anecdotally) more reliable in this type of application.

I'd use that plus a spring loaded header - maybe something like a Tag-Connect cable.

For high volumes, you could always just send your CPUs to a company like Action Circuits for programming in bulk.

[peter-h]

I recall looking at "tag connect" when I started the PCB but it did not appear to be self-retaining so you had to press it down for the programming time, so instead went for a straight line of 8 holes, and 8 of these

[voltsandjolts]

We generally do automated programming as part of the ATE bed-of-nails setup.

[hans]

You could add a jumper to the BOOT pins,  (BOOT0=High and BOOT1=Low) to enter ST's bootloader.
Then this document lists which pins you can use for programming using ST's bootloader. I've used the USB DFU before on a previous project with the F427, and I was able to drag-drop binaries with the DFU programmer utility. I see that utility is now replaced by STM32CubeProgrammer.

The essence of my story is, you don't need JTAG or SWD to program. A FTDI USB<>Serial (or USB if you use the right port), will do.

On the company I used to work at, most devices were programmed this way, also plenty from NXP dating way back to ARM7TDMI chips. We typically had a serial line TXD/RXD, BOOT and RST on there to FLASH atleast our own bootloader. Then reset the device and take it from there.

[peter-h]

Thanks; I saw that. You can boot load via serial, I2C, SPI, USB or even (if you are a masochist) CAN. Some of these are going to be really slow compared to SWD, if you are loading say 500k. And I do have a jumper which does BOOT0=1 so must have thought about this at some point...

I think the advantage of SWD loading is that if you have a dud board, then you can try to single step it right away in that very same rig and see how far it gets. Whereas if your production setup is just a code loader, then you need a second station with Cube running on it.

[AndyC_772]

You can, provided the person doing the programming has the technical know-how to step through source code with a debugger. If you're making a product in sufficient quantity for any of this to be important, then I'd suggest that you're better off having the programming done by an operator or junior technician, and if anything fails, red tag it and move on.

You can sort through the red tag pile in your own time - don't hold up production, or whatever else you're developing, to fix what should be a small proportion of your production PCBs.

[nctnico]

You can, provided the person doing the programming has the technical know-how to step through source code with a debugger. If you're making a product in sufficient quantity for any of this to be important, then I'd suggest that you're better off having the programming done by an operator or junior technician, and if anything fails, red tag it and move on.

You can sort through the red tag pile in your own time - don't hold up production, or whatever else you're developing, to fix what should be a small proportion of your production PCBs.

I agree. Even when I'm testing boards by myself I just put the boards with a problem aside and fix these later. Chances are multiple boards have the same problem (usually an assembly issue) so you can fix these in one go.

I'd be more worried about automating the process and loading things like serial numbers and MAC addresses. I wrote such a tool for one of my customers to use in their production lines.

[SiliconWizard]

Ar the very least you'd probably want to use STM32CubeProgrammer rather than the IDE, would you not?

And there's still the STM32 ST-LINK Utility which supports the F4 series no problem, and is lighter than the Cube Programmer.
You could alternatively use OpenOCD and write a small production utility launching it appropriately.

Usually in production, some testing follows flashing, so having a unique tool doing all the programming and basic testing is a good idea.

[peter-h]

loading things like serial numbers and MAC addresses

How would that be done? The only ways I can see are

- modifying the binary prior to programming the FLASH
- loading a standard binary into the FLASH and when the CPU wakes up (when the debugger releases -RST) then establish comms via serial (etc)

This stuff actually complicates the factory programming and makes "just a box" hard to do unless you build a fully custom "box".

In my other products I have loaded serial numbers during the factory test procedure, later, manually. There are various angles on this; one being that the 32F417 has a unique 96 bit ID already which could be used to generate a "serial number" for the product, but it would not be sequential so a PITA to keep track of which customer got which units (unless you build a database for that, with barcode entry). I was involved in such a thing in the 1980s - a PITA which was abandoned due to complexity (database running on an IBM AS/400, no kidding). Similarly, MAC numbers can't really be typed in by hand either, in production.

Alternatively, I have an Adesto serial FLASH in there which contains 64 bytes of unique data. Again, obviously not sequential (on populated boards). That could produce the same (fairly useless if you want to keep track of them) S/N for the product.

I wonder how people handle this stuff.

[nctnico]

loading things like serial numbers and MAC addresses

How would that be done? The only ways I can see are

- modifying the binary prior to programming the FLASH
- loading a standard binary into the FLASH and when the CPU wakes up (when the debugger releases -RST) then establish comms via serial (etc)

Send commands over the serial port to set these. The case I wrote about uses the ST serial port bootloader and then checks whether the board boots and sets a whole bunch settings using a command line interface over the same serial port used to load the firmware.

[AndyC_772]

The answer may depend on the nature of your product.

At one extreme, it might make perfect sense to just program the same code into every board, with nothing unique about it at all.

At the other, you might 'bulk' program a custom secure bootloader, then use that to install unique identifiers, security keys and an encrypted firmware binary with a hash or checksum - via whichever interface is most convenient.

I've done both, and can't really tell you which is the 'best' solution. Typically it all starts off as a manual process for a new product, and becomes more automated as volumes increase over time.

Tip: production test equipment is a great get-you-started job for a junior engineer.

[SiliconWizard]

Even if you want to customize some info in Flash memory, you don't have to program it monolithically in just one go, so you don't need to modify the code itself.

You can absolutely flash the same code in all your boards, and then flash separate data customized for each board in a second pass, to a dedicated area in Flash. That would be one common way of doing it.

[peter-h]

and then flash separate data customized for each board in a second pass, to a dedicated area in Flash

How would that be done?

Is there some SWD tool which can read one of the CPU FLASH blocks, mod a few bytes, and write it back?

Obviously you could do it using the CPU, with the custom data coming in over serial etc, but then you could just store the custom stuff in some other chip. I have a serial (SPI) FLASH for that. I've written a (RAM-resident) boot loader so have all the code, but there is little point in storing config data in CPU FLASH if you have other devices. Unless there are security considerations...

[jeremy]

Why not just use a raspberry pi with a python script? Use something like https://github.com/pyocd/pyOCD/blob/main/docs/command_reference.md and you can write to whatever flash pages you like as long as they were previously blank. You can add a button with the GPIOs for programming and some LEDs for go/no go and control them in your script.

Also FWIW tag-connect come in two varieties, one of them is just the pogo pins and the other is pogo pins with self-retaining clips. I pretty much always use the self-retaining one.

[SiliconWizard]

and then flash separate data customized for each board in a second pass, to a dedicated area in Flash

How would that be done?

Is there some SWD tool which can read one of the CPU FLASH blocks, mod a few bytes, and write it back?

Obviously you could do it using the CPU, with the custom data coming in over serial etc, but then you could just store the custom stuff in some other chip. I have a serial (SPI) FLASH for that. I've written a (RAM-resident) boot loader so have all the code, but there is little point in storing config data in CPU FLASH if you have other devices. Unless there are security considerations...

I don't know about the Cube programmer, but the STLINK utility allows you to import .hex files.
.hex files contain addresses and data. So you can generate a .hex file for just a portion of Flash memory independently.
For generating .hex files, there's a number of ways. One of them is to use objcopy which is part of binutils and comes with the GCC compiler.

Or you could use OpenOCD, which is more flexible than those programming utilities but has a learning curve. (But the plus side is that you can automate things with it!)

[cdev]

Ive used a simple UART which works fine and is easy.. Assuming you dont need to do any on the spot debugging that should be okay. I dontthink I am missing anything but I might be wrong, Ive only done this a couple of times..

[Codemonkey]

+1 for using OpenOCD in conjunction with an ST-Link adapter. I developed a product using the same device. For production, I wrote a batch file to automate programming of both a bootloader and application that the production guys can run by just double clicking on a shortcut on one of the production PCs. Quick and pretty much foolproof.

[Doctorandus_P]

I'd probably also use openOCD or another command line utilty such as stm32flash and combine that with a standard EUR 50 small Linux single board computer. These things generally have GPIO pins and you can write a simple shell script or use some other scripting language such as python and then write a loop that waits for some signal on an I/O pin, then programs the chip and shows some indication whether programming was successful or failed.

[DavidAlfa]

Programmer on-the-go was great feature introduced in pickit 2.
From the design point of view, all it needs is an inexpensive spi flash for storage.
I've used it for batch programming, each pic takes 5 seconds, click the button, wait for the green led and proceed with the next one!

I wonder why ST didn't do the same with the ST-Link v2.

[abyrvalg]

I’ve just seen this thing https://www.tindie.com/products/blinkingsilver/stm32-gd32-stm8-mass-offline-burner-downloader/ in action, it works (on STM32F103RC at least).