Write and erase flash when the Internal RC Oscillator is off #1348
Conversation
vanrein
commented
Oct 24, 2023
vanrein
commented
- By first enabling it
- This worked for me on STM32F103
- Quite likely not the best structure
- Willing to take instructions, or hand it over
|
According to RM0008, the Reference Manual to STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced Arm®-based 32-bit MCUs:
You can imagine that I only found this after I had landed in a cyclical dependency; after every reboot the HSI would be off and so I could not flash a new program into the device. This fix remedied that. I think it makes life more robust, can hardly cause trouble (as we usually reset after a rewrite) and is a pleasant thing to have arranged quietly. |
|
I suspect that you have strict ideas about the program structure, and want it done elsewhere. I'm listening. I suppose the RCC_CR and its HSION bit also needs location on all devices. Perhaps in the Guidance is welcomed, but chances are you'll be faster off doing this yourself. Which is then kindly welcomed :-) |
|
FWIW, the code in action: Reading the HSION in bit0 and HSIRDY in bit1, setting it in the next write, and reading the HSION/HSIRDY as both set in the subsequent read. |
- By first enabling it - This worked for me on STM32F103 - Quite likely not the best structure - Willing to take instructions, or hand it over Fixed the check to include HSIRDY alongside HSION - When writing HSION, the HSIRDY takes some time to come up - This may in theory have delays - It is entirely proper to check the bits together; they are "ist & soll"
|
According to RM0008, 7.2.6 System clock (SYSCLK) selection:
How is the system clocked after a reset if the HSI is turned off? |
|
Hi Anton,
According to RM0008, 7.2.6 System clock (SYSCLK) selection:
> After a system reset, the HSI oscillator is selected as system clock.
Yes, but then my software, as burnt before, turns it off (after switching
to the external oscillator HSE). Since the use of a crystal is common,
and the internal resonator is not useful for normal operations, I turned
it off. Only to be surprised that the flash design apparently benefits
for writes/erases from the RC oscillator because it has a known pace.
I suppose many keep the RC running, possibly to live up to the flash
requirements. That's a bit silly I think, especially because there is
a lot of setup being done in st-flash before it starts. This seems like
a way to avoid the surprise that I'd gotten.
How is the system clocked after a reset if the HSI is turned off?
HSE from a crystal. I'm using the standard STM32F103C8T6 module, the
so-called "blue pill".
The only "pathetic" thing I did was switching off the unused HSI.
This may not be common [I always look for tightest energy consumption]
or perhaps it is a problem that nobody figured out. There are other
cases that lock up these chips (flash may get reconfigured to 0 size)
so I initially also wondered if I had to accept it as a loss.
Are you using connection under reset?
No. Like most people, I use an ST-Linkv2 with only 4 wires, so no
wire for reset. In fact, my blue pill routes PB2 to the side of the
board and not nRST, so it would not be easy to do that.
Cheers,
-Rick
|
|
@vanrein Hi, Rick! I understood the situation. Thanks for the explanation! The connect under reset option also performs a soft reset with halt (AIRCR_SYSRESETREQ with DEMCR_VC_CORERESET). Perhaps soft reset will solve the problem. Can you check this ( Calling the reset function: |
|
Tried with Returning to my patch e5be102 and power cycling to remove the other version's impact and flashing is stable. This is virtually instant. Sometimes it gets stuck waiting infinitely for an OK: |
|
I've been wondering why I ran into this, after so many others apparently have not. It may be because I'm avoiding the Cube software, because its license bans cross-MCU inclusion, and also because I prefer doing it without HAL and completely with My code is public, and these are the relevant portions: |
|
@vanrein |
|
Hi Anton,
@vanrein
`--reset` it's another function. To check you need to run: `st-flash --debug --reset --connect-under-reset`
That is not documented, so it is unavailable to users. But it does work, I could program the chip with --connect-under-reset added, and not without it. This is still without direct link from the ST-LinkV2 to the NRST pin on the STM32.
I'll leave it to you if the idea of resetting the RC-oscillator by default is a good idea; but at least I think it is better to avoid options like these that have more impact (though I cannot think of a really big problem).
Please document this feature in the st-flash man page? It is not really clear now...
Thanks!
-Rick
|
|
Closing this ticket as there appears to be no general need and/or interest in this topic. |
Nightwalker-87
modified the milestones:
v1.8.0,
Declined or withdrawn contributions & issues
