Production loading of code into a ST 32F417

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