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).

[bson]

How about openocd and a custom script.  Keep trying to connect to a specific cpuid, and when it succeeds proceed to flash.  Wait for disconnect, then return to waiting for connect.  Should work just fine with stlink v3 and openocd.

[ebclr]

This may help

https://pt.aliexpress.com/item/1005001488470112.html?spm=a2g0o.productlist.0.0.296ec5b0t9C87L&algo_pvid=ae4b8a47-c36a-454e-a3f1-9ef46810f1af&algo_exp_id=ae4b8a47-c36a-454e-a3f1-9ef46810f1af-48&pdp_ext_f=%7B%22sku_id%22%3A%2212000016321421243%22%7D&pdp_npi=2%40dis%21USD%21%2134.11%2134.11%21%21%21%21%40210318b916532745015783772efdfa%2112000016321421243%21sea

[peter-h]

That's more like what I was looking for, but they don't support the 32F4xx.

[jc101]

I use these https://softlog.com/

I send the programmer with the assembly kit, and a small box I made up with red/green LEDs and a GO button.  Plug it in, push-button, and wait for the Green or Red LED light up depending in the programming was successful or not.  Pretty hard to go wrong really.  I use the small ICP2(G3) but they go right up to 64 at a time.  You can serialise the data too, so can inject a unique serial number too for example, if required.

It looks like the STM32F417 is supported.

[peter-h]

Thank you all for these pointers Really great stuff.

[peter-h]

Back to this old one

Setting up a production programmer on a win10 laptop.

STM32 Utility (recommended further back here) installs but won't run. MFC140.DLL and a bunch of other files missing. Loads of people with same problems. No solutions (mostly). Told to download MS VC++ distributables, v xxxxx. No result after a day or so of trying different things. Of course the files are in windows\system32 but it doesn't find them. The other trick, copying them into the .exe's directory path, gets further but you get other errors. Something in win10 breaks it. This is the year 2020 executable. Works out of the box on win7-64 (as does latest Cube btw). On same laptop, Cube 1.13.1 works fine, which is odd since that was very sensitive to the MS VC++ versions.

Then I see on the ST forum that this prog is "deprecated" You should now use STM32 Cube Programmer Tools. So I install that. It runs, but what a weird program. Is this intended for production? You have to enter the ELF filename every time you start it. It complains about overlapping sections... never seen that before. I wonder if I should load a binary file instead (131MB). It fails to autodetect the target so one has to click on Disconnect/Connect every time.

Has anybody used this? It is usable but no programmer who actually uses this thing in production would have done it like that.

[DavidAlfa]

What utility are you referring to?
Both ST-Link Utility and ST Visual Programmer work fine in Win11 x64.

[peter-h]

ST Visual Programmer STM32 (replaced by STM32CubeProgrammer)

I didn't know about Visual Programmer. Cube programmer is what I am having "fun" with. OK, I mean, it is usable, just a bit crap.

I am surprised Cube IDE doesn't have this functionality actually. I could just use it, but the most basic build+download takes a fair bit longer.

[AndyC_772]

No solution, I'm afraid, but I feel your pain.

The ST-Link Utility was (is!) simple, light weight, fast, easy to use, etc etc.

The newer ST 'cube' programming tool (whatever it's called) is, by contrast, fat, bloated, awkward, generally inferior in all the ways that matter - but, sadly, required for recent generations of MCU like the G4.

[SiliconWizard]

For production, I would recommend what bson suggested, use OpenOCD. That's what I use as well.
If you want to have a GUI on top of it, you could write a small Python script that calls OpenOCD. No frills, just works.

I had used ST-Link Utility before, it was relatively ligthweight program that just worked. I've tried STM32CubeProgrammer a few weeks ago, out of curiosity. It's the now-common, bloated, slow, barely usable crap with cute icons that ST has switched to.

Note that if you are uncomfortable using OpenOCD (although I'm pretty sure you can easily find someone that would help you set it up and even write scripts/a small GUI for your production needs), you can use the CLI tool that comes with STM32CubeProgrammer (STM32_Programmer_CLI.exe in the STM32CubeProgrammer/bin directory), which can be automated just like OpenOCD.

[peter-h]

The ST-Link Utility was (is!) simple, light weight, fast, easy to use, etc etc.

It should run in a VM. I have a few win7-64 VMs. They run Cube IDE fine, too. One can update win7-64 using the Simplix route, all the way to current version available to M$ contract customers.

The gotcha is that USB in a VM is generally "fun"

Is Visual Programmer any better? I can't easily download it - the ST website either hangs or goes around in circles, with repeated validations of the email address.
https://www.st.com/en/development-tools/stvp-stm32.html#get-software

EDIT: got it. Used M$ Edge

[peter-h]

Visual Programmer works fine. It needs an intel hex file; can't read ELF etc. It's a good production tool. Control-P is all it needs (configured for auto erase before programming, etc).

I have a question on the watchdog config which all these programming tools seem to have.

You can have
- hardware watchdog
- software watchdog

In the product I use a hardware watchdog, obviously. But it doesn't seem to matter which of the above options I choose. Is this some CPU config bit which automatically enables the watchdog?

Currently I call this

Code: [Select]

// Initialise the watchdog (by default in system trigger mode)
// The timeout_ms value specifies the time in ms within which it must be "pulsed"
// The maximum value for timeout_ms is 4095ms.

void watchdog_init(uint32_t timeout_ms)
{

// Max reload value is 0xFFF
if (timeout_ms > 4095) timeout_ms = 4095;

// Prescaler of 32 gives 32KHz / 32 = 1KHz
// So each reload count is worth 1ms
hiwdg.Instance = IWDG;
hiwdg.Init.Prescaler = IWDG_PRESCALER_32;
hiwdg.Init.Reload = timeout_ms;
(void) HAL_IWDG_Init(&hiwdg);

}

ISTM I should use "software watchdog" because I don't want the watchdog enabled until I enable it explicitly.

These
https://wiki.segger.com/ST_STM32F1#Hardware_watchdog
https://www.st.com/resource/en/product_training/STM32WB-WDG_TIMERS-Independent-Watchdog-IWDG.pdf
seem to confirm that, without saying what timeout period will be used on the "hardware watchdog" mode. Maybe the max possible time which for my clock is 4096ms.

Visual Programmer seems to save these settings. It just won't auto-load the firmware file, but that's fine. Curiously it does detect (and warn) if you changed it outside of Visual Programmer

Visual Programmer installs some other program which I could not work out what it does. It looks like a project builder, a bit like Cube IDE. But no obvious editor.

[peter-h]

Does anyone know what a "software watchdog" is?

[AndyC_772]

If we're talking about the option bits in STM32 ('WDG_SW' if I recall correctly), it just refers to how the hardware watchdog is started.

If it's in 'software' mode, then your code is required to enable it. Prior to this point it's completely disabled.

In 'hardware' mode it's automatically started when the CPU boots, and your code must start kicking it before it expires and causes a reboot.

If it's enabled in hardware, then it can trigger while code is being downloaded through the ST-link cable, which means programming fails. You may need to set WDG_SW and reboot before starting the download.

[peter-h]

Thanks - this is what I suspected. But where is the watchdog trip time defined?

The CPU starts up at 16MHz so if you do nothing you will get a much longer trip time than if you do the usual thing and wind up the PLL to 168MHz (or whatever).

At 168MHz the max time is 4096ms (IIRC - not sure where the actual limit is). I have a function for setting it, which has a max parameter of 4096.

I experimented briefly with the "hardware version" and didn't see any difference, presumably because the trip time is longer than my power-up LED test happens a bit quicker

[wek]

Thanks - this is what I suspected. But where is the watchdog trip time defined?

The CPU starts up at 16MHz so if you do nothing you will get a much longer trip time than if you do the usual thing and wind up the PLL to 168MHz (or whatever).

At 168MHz the max time is 4096ms (IIRC - not sure where the actual limit is). I have a function for setting it, which has a max parameter of 4096.

I experimented briefly with the "hardware version" and didn't see any difference, presumably because the trip time is longer than my power-up LED test happens a bit quicker

The watchdog is clocked from LSI, and its function together with default/reset values are described in the IWDG chapter of RM.

JW

[peter-h]

That reads like the reset value is 16MHz divided by 4 (the default prescaler), and counting down from 4096 i.e. the watchdog will trip at  about 1ms after power-up.

This must be wrong because it isn't doing that.

[DavidAlfa]

- Kindly talking - more RTFM and less asking! 
I'm sure the WWDG / IWDG chapters will clear most of your doubts.
Also check the MX config!

[peter-h]

I've read the RM but it doesn't matter because I got the answer: the "software" watchdog setting is the one to use because I call specific functions (operation verified) to enable the watchdog.

[DavidAlfa]

What are you calling "Software watchdog"? In STM32 you have IWDG and WWDG.
Then you can set the config bits to configure the IWDG in software (code-enabled) or hardware (Forced always on) modes.

AFAIK the IWDG clock source is always 32 or 40KHz (Depending on the device) derived for LSI RC, not 16MHz.
You have it clear as water in the clock configuration tab of CobeMX, I cannot understand the struggle.
Pre=4...256 and Countdown=0...4095(+1) allow any setting between 122us-32s (32Khz) and 100us-26s (40KHz).

The default IWDG values are prescaler=4, countdown=4095(+1). So 16384 clocks.
That's 500ms (32KHz) or 409ms (40KHz).

[peter-h]

The terms "software watchdog" or "hardware watchdog" is what appears for the options byte(s) configuration in the ST device programming tools like Visual Programmer, discussed earlier in this thread.

I do actually know what the watchdog does (I missed the clock source) and have been using it; my question here pertained only to that pulldown menu in these programming tools. They don't all work well but they all seem to have it. Why, I have no idea. Surely you are writing the code for the product so you will set up the watchdog as appropriate. You don't need the watchdog auto enabled at power-up.

Is there some reason for this feature?

[DavidAlfa]

Avoid hacking, for example.
You can stop the core but not the dog if enabled in the config bits.
Or simply avoid the possibility of the code messing the wdt by disabling it.

[peter-h]

Ah yes I remember an old 1980s anti dongle hacking procedure using a timer on the PC, to prevent single stepping the dongle code IIRC, AutoCAD did that...

Not hard to work around.

[peter-h]

How could one defeat the config byte enabled watchdog?

Presumably if security is not Level 2 then you can connect up a debugger and reflash stuff and reboot?

[AndyC_772]

The 'hardware' watchdog is really there in case your code crashes before reaching the function that would enable it anyway.

Suppose you have a device which is deployed somewhere inaccessible. A power supply disturbance causes a crash, a watchdog timeout, and then a reset. That supply disturbance may well still be happening when your code boots, and it never makes it to the 'enable watchdog' function. Now it's stuck, executing garbage from which it can never recover without a physical power cycle.

[peter-h]

Is there any control over the watchdog timeout period, when the wdog is thus enabled?

It seems to be dependent on how soon in the code you set up the PLL to change the CPU clock, etc.

[DavidAlfa]

How could one defeat the config byte enabled watchdog?

Easy with an openocd script that keeps resetting by writing to the peripheral reg.
Something like this every few ms.

IWDG, write reset key

Code: [Select]

mww 0x40003000 0xAAAA

WWDG, reload counter

Code: [Select]

mww 0x40002C00 0xFF


Is there any control over the watchdog timeout period, when the wdog is thus enabled?

Starts instantly after reset, holding the default reset values (Pre=4, Load=4095).
That's 500ms, should be enough to init any mcu >1000 times! Otherwise just clear the WWDG periodically.
AFAIK there's nothing keeping you from modifying these values. But you can't turn the WWDG off if set by HW.

BTW I noticed I've mixed up a bit the IWDG and WWDG.

The IWDG takes the slow 32KHz LSI clock (32KHz), has pre 4...256 and 12-bit downcounter.
So max counter value is 4095(+1), with pre=256 gives 32 seconds!
HW IWDG cannot be stopped/halted by any means, can only be cleared.

WWDG clock source is APB1/4096, then has pre=1:2:4:8 (Default is 8 ), and a 7bit downcounter.
The counter resets to 0x7F and starts counting down, it'll trigger a reset in the transition of 0x40 to 0x3F.
So, you must reload the counter before it gets that low.
You can have anywhere between 4096*1*1=4096,  to 4096*8*(0x7F-0x3F)=2.1M clocks.
Normally APB1 runs at half the CPU clock, so at 84MHz 4096=48us and 2.1M=24.9ms timeout.
HW WWDG cannot be stopped either, but can be halted by a debugger using DBGMCU bits.

(RM is your friend).

[peter-h]

It is 500ms unless you set the CPU to some other PLL multiplier shortly after startup, which you probably do

[DavidAlfa]

Yeah, at the default 8MHz HSI, APB1 runs at 4MHz, that's 524ms

[peter-h]

Yes, I confused a few things

I am using the IWDG

Code: [Select]



// Static handle for the watchdog
static IWDG_HandleTypeDef hiwdg;

// Watchdog mode - used in the simple_timer tick
uint8_t watchdog_mode = 0;


// Initialise the watchdog (by default in system trigger mode)
// The timeout_ms value specifies the time in ms within which it must be "pulsed"
// The maximum value for timeout_ms is 4095ms.

void watchdog_init(uint32_t timeout_ms)
{

watchdog_mode = 0;

// Max reload value is 0xFFF
if (timeout_ms > 4095) timeout_ms = 4095;

// Prescaler of 32 gives 32KHz / 32 = 1KHz
// So each reload count is worth 1ms
hiwdg.Instance = IWDG;
hiwdg.Init.Prescaler = IWDG_PRESCALER_32;
hiwdg.Init.Reload = timeout_ms;
(void) HAL_IWDG_Init(&hiwdg);

}

// Pulse the watchdog
void watchdog_pulse(void)
{

HAL_IWDG_Refresh(&hiwdg);

}


/**
  * @brief  Initialize the IWDG according to the specified parameters in the
  *         IWDG_InitTypeDef and start watchdog. Before exiting function,
  *         watchdog is refreshed in order to have correct time base.
  * @param  hiwdg  pointer to a IWDG_HandleTypeDef structure that contains
  *                the configuration information for the specified IWDG module.
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_IWDG_Init(IWDG_HandleTypeDef *hiwdg)
{

  uint32_t tickstart;

  /* Check the IWDG handle allocation */
  if (hiwdg == NULL)
  {
    return HAL_ERROR;
  }

  /* Check the parameters */
  assert_param(IS_IWDG_ALL_INSTANCE(hiwdg->Instance));
  assert_param(IS_IWDG_PRESCALER(hiwdg->Init.Prescaler));
  assert_param(IS_IWDG_RELOAD(hiwdg->Init.Reload));

  /* Enable IWDG. LSI is turned on automatically */
  __HAL_IWDG_START(hiwdg);

  /* Enable write access to IWDG_PR and IWDG_RLR registers by writing
  0x5555 in KR */
  IWDG_ENABLE_WRITE_ACCESS(hiwdg);

  /* Write to IWDG registers the Prescaler & Reload values to work with */
  hiwdg->Instance->PR = hiwdg->Init.Prescaler;
  hiwdg->Instance->RLR = hiwdg->Init.Reload;

  /* Check pending flag, if previous update not done, return timeout */
  tickstart = HAL_GetTick();

  /* Wait for register to be updated */
  while (hiwdg->Instance->SR != 0x00u)
  {
    if ((HAL_GetTick() - tickstart) > HAL_IWDG_DEFAULT_TIMEOUT)
    {
      return HAL_TIMEOUT;
    }
  }

  /* Reload IWDG counter with value defined in the reload register */
  __HAL_IWDG_RELOAD_COUNTER(hiwdg);

  /* Return function status */
  return HAL_OK;
}


So IWDG runs off the 32768Hz oscillator. So I come back to my Q as to whether the software/hardware watchdog setting in the code loader utilities applies to this.

BTW a 32F4 runs at 16MHz after startup.

It also seems that disabling the IWDG is easily done by shorting the 32768Hz oscillator.

[DavidAlfa]

How do you short the 32K oscillator? It's internal, not the external 32KHz meant for the RTC.

[peter-h]

More confusion

These are areas which I had already set up when I got involved and which I didn't have to investigate.

So my outstanding Q as to whether the software/hardware watchdog setting in the code loader utilities applies to this. For example this is the old STM Utility



In the HELP they group together both IWDG and WWDG



WDG_SW - which watchdog?

I am not using the window watchdog at all.

[DavidAlfa]

Seems they missed the "I", as few options down you have WWDG_SW.

[peter-h]

They have missed the "I" out from both places, and done it in each of the 2 or 3 other production programming tools which have the same option byte labelling. Weird.

But anyway I clearly should choose "software" to prevent the "hard enable" on the IWDG.

[peter-h]

Update:

I have carefully tested the WDG_SW unchecked and the CPU gets reset after about 540ms. This is a 32F417. AFAICT the IWDG is affected (speed-wise) by nothing on the chip. It uses a 32000Hz RC oscillator.

If the long delay is removed, so the system starts up as normal, the reset occurs after about 250ms. This must be because the IWDG prescaler has been reinitialised to IWDG_PRESCALER_32. The power-up default is 64. So it is about right.

The "hardware enabled watchdog" mode is clearly useful but one needs to initialise everything pretty fast and not waste time on stuff like LED patterns on startup Or pulse the watchdog inside these too.

Interestingly I can't see a way to set the option bytes in Cube IDE, but it must be in there somewhere.

For reference, my startup code (after the asm startup which does memory fills etc and sets up SP) is

EDIT: I finally realised that the IWDG timeout time is not affected by anything on the chip if the "hardware watchdog" mode is used; only the IWDG prescaler and the counter value can be changed by software.

Also I found that on the Visual Programmer tool the option byte does not get programmed just by setting it and programming the CPU (the way it works on the ST-LINK Utility). You have to select the tab and program what is on the tab manually

[peter-h]

On a related topic, what is the simplest way to reboot (briefly reset) the target, with an STLINK V2/V3 debugger attached?

I see lots of things do a reboot e.g. a disconnect and connect of the target in the Visual Programmer, but there appears to be no "reboot" button. Unplugging and replugging the USB cable to the STLINK also does it

Maybe one could use the SWD API and some utility? But that may not work if the programmer utility is currently connected.

[DavidAlfa]

Openocd + reset command I guess.

[peter-h]

OPENOCD can probably do everything but looks damn complicated. Especially for a production environment.

[DavidAlfa]

Nah, it's pretty straightforward!
This might contain some errors as it's not tested and I'm not an openOCD user, but it's plain simple:

Code: [Select]

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -f my_script.cfg

Code: (my_script.cfg) [Select]

init
reset
stm32f4x unlock
stm32f4x mass_erase
flash write_image program.bin 0 verify
stm32f4x lock
reset
exit

It only took me 3 minutes, just a bit of reading, and so should you, instead complaining about it being very complicated!

[peter-h]

Right, but with no GUI, how do you use this in a production environment?

I can see you could set up icons which run batch files which contain these scripts.

I must be missing something... why use a command line utility IF you can find a GUI one that works.

[abyrvalg]

Because those nice GUI programmers are too generic for this fixed task? You can open a wrong file, tick wrong option bytes config, click wrong button in the toolbar. While a custom script can be coded to wait for keypress, do a fixed programming sequence using hardcoded file etc, repeat. Also you can combine programming with some sort of automated testing.

[peter-h]

Back to the option bytes, the RM has the same ambiguity



Same "mistake" repeated. Hard to be sure this is not intentional. Does the WDG_SW bit really control only the IWDG? Why didn't they call it IWDG_SW?

They call it thus here
https://community.st.com/t5/stm32-mcus/what-are-option-bytes-in-stm32-and-how-do-i-use-them/ta-p/49451

[Psi]

+1 for stm32flash and small computer like a SBC or Pi
But you'd probably want to write some code to make a simple production GUI to automate starting the command line call to stm32flash and reading if it succeeds. Maybe have a GPIO button to start it. etc..

Unfortunately production programming of MCUs is kind of a cash cow, lots of company's selling super expensive gang programming systems.

[peter-h]

In my case it is a bit easier. With the Visual Programmer, ctrl-o opens a .hex file and that file stays loaded until power-down. I will obviously make sure there is only one file on that laptop. Then ctrl-p programs and verifies the product, which then boots up and the operator runs some special procedures to initialise it.

Yeah - I was doing gang programming of EPROMs and later Atmel AVRs. The 32F4 is much easier and takes only some seconds to program.

and small computer like a SBC or Pi

Why not a dedicated laptop?

[DavidAlfa]

Meh. A simple batch/bash file taking input arguments, drop a bin/hex into it, done.