#164 Regression: required delay before entering boot loader mode

[Guillermo]

We have been using stm32flash to flash different STM32F microcontrollers, and using -i to specify a GPIO sequence to enter boot loader mode. This was working fine in stm32flash 0.5, but we started getting errors when we upgraded to 0.7.

A git bisect pointed to commit efeab9 as the cause of the issue. According to the commit description, the intent was to add some flexibility in the specification of GPIO sequences: empty GPIOs (just the comma) for additional delays, and an additional separator ('&') for no delays. However the commit also changed the current behaviour:

• Before that commit, a delay of 100ms was added after each GPIO action (including the last one). After the commit, a delay of 100ms is added between actions, but not after the last one. This change may have been accidental.
• Additionally there was an extra delay of 500ms after the GPIO sequence which was also removed. This was an explicit change which is not mentioned in the commit description.

Thus in stm32flash 0.5, a delay of 100+500ms was automatically added after the GPIO sequence, which is no longer the case after this commit. This breaks existing behaviour, since most STM32F microcontrollers require some delay before entering boot loader mode (see table 191 in AN2606, March 2024 edition). To work around this, GPIO sequences would need to be modified to add an additional "empty GPIO" action so that there is a minimum delay before trying to communicate with the boot loader.

[Tormod Volden]

Thanks for your report. The change should have been mentioned in the ChangeLog and release notes. I have added info to the wiki Hints and online ChangeLog pages. I'll keep this bug open to remember to also mention it retroactively in the next release announcement.

I think both changes were intentional but not mentioned. The current behaviour seems consistent with the documentation, and the previous 600 ms pause was not documented anywhere AFAICS.

[Guillermo]

Hi,

Thanks for your answer.

According to AN2606 almost every STM32 micro needs a minimum delay, so with the current code, whenever the -i option is used to specify a GPIO sequence, an additional delay will always need to be added at the end of the sequence.

To make things worse, leaving this delay out does not automatically cause communication failures: in our tests, we only see communication errors on 10-20% of the cases. That's bad becasue if you don't pay attention to this issue (which users may not be aware of), a given GPIO sequence may "look correct" on casual tests, but still fail randomly later.

Based on the above I would suggest to add a delay back to init.c. Perhaps 600ms is too much, but I'd say 100ms should be OK. According to table 191 in AN2606 this should already cover the vast majority of the cases (there are only 6 configurations that require a delay greater than 100ms but less than 600ms).

I'd be happy to send a PR if you think this is OK.

Guillermo