Production loading of code into a ST 32F417

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