Electronics > Microcontrollers

Why do most MCU code start by resetting peripherals?

<< < (4/6) > >>

David Hess:

--- Quote from: semir-t on October 15, 2021, 10:03:45 am ---I would assume that when we reset the MCU through the external pin, there would be some internal circuit that would bring the MCU in some default/starting state. But what about when we initiate software reset through CPU instruction. So from my point of view it is better to do this stuff in the startup script then to leave it hanging.
--- End quote ---

You can probably count on a hardware reset also resetting microcontroller peripherals but in the past it was more common to have separate peripherals which may or may not be tied to the CPU reset signal, and that will still be the case today sometimes.  The safe bet by default is to reset the peripheral before initialization unless you have specific reason not to, like needing to maintain the previous state.

simonlasnier:
Hi! I'm the OP. Thank you all very much for your insights, very interesting to hear!!  8)


--- Quote from: Siwastaja on October 15, 2021, 06:06:48 pm ---Power on reset / soft reset are pretty darn reliable because they get tested directly or indirectly in every possible project. If some peripheral does not reset properly on device reset, the design team will see that immediately (by noticing the difference in behavior between first run after power-on, and second run after soft reset).

--- End quote ---
I fully agree and actually this is the model I have been running so far, always assuming that I could trust the reset values, and I have had zero issues with this so far. It made sense for my project which is a relatively small project where I have 100% control (i.e. no libraries and no external people). But I keep seeing these resets in code examples (in particular in the reset handler which really triggered me - see exactly what right below), hence my question.


--- Quote from: SiliconWizard on October 15, 2021, 06:46:12 pm ---And with all that said, the OP probably needs to be more specific and give examples.

In startup code provided by ST for STM32 MCUs I have used, the Reset_Handler routine typically, after setting up the stack and dealing with data and bss segments, will eventually calls the SystemInit() function (and then call main). This function will typically: configure the FPU, reset registers relative to clocks (for a reason I don't know, as those are indeed reset values) and not just all peripherals, and then disable interrupts and setup the vector table.

So can the OP show us example code provided by ST which would reset peripherals other than clocks?

The second point I do not understand from the OP's statement is this: "in the ResetHandler interrupt, is resetting the peripheral it is about to configure."
Except for what I mentioned above, no peripheral is configured by the ResetHandler. But there may be some information missing here. Or a misunderstanding of what the "ResetHandler" is.

--- End quote ---
You wrote "reset registers relative to clocks (for a reason I don't know, as those are indeed reset values)" (in bold italic in the quote) - that's it ha ha   ;D ;D That's the one I saw in the Reset Handler which I did not understand either.
Apart from that I have seen it a couple of times in other code and libraries, but that part has been answered by many here (the answer is basically ease of use and because you do not know when the library will be executed).


On the other side I completely understand the idea that for sure when you "assume" anything in hardware coding you better be darn sure you have not forgotten anything, and that gets much, much more complicated as the size of the project goes. So yes Tim/T3sl4co1l, very good point I agree  ;D


--- Quote from: T3sl4co1l on October 15, 2021, 08:59:39 pm ---It's not obvious when or why someone would do this, but maybe it's a simple enough solution to a program always crashing: instead of dumping to the default hardware error handler (a spin loop), just go back to start and hope it goes better the next time (ha).

--- End quote ---
:-DD :palm:

And as for ejeffrey and mikeselectricstuff who mentioned the Bootloader - yes I would always restart the whole thing (call a full software Reset, or even using the external NRST pin) after finishing a Bootloader.

And just to throw my own opinion, I personally also find a good middle ground by writing:

--- Code: ---PERIPH->REG = PERIPH_REG_RESET VALUE | myValue;
--- End code ---
instead of

--- Code: ---PERIPH->REG |= myValue;
--- End code ---
when I know the peripheral should be in reset, in most cases it will produce even smaller binary code and if for whatever reasons the peripheral is not at reset then it will still work.

Siwastaja:

--- Quote from: simonlasnier on October 17, 2021, 12:34:31 pm ---I fully agree and actually this is the model I have been running so far, always assuming that I could trust the reset values, and I have had zero issues with this so far. It made sense for my project which is a relatively small project where I have 100% control (i.e. no libraries and no external people). But I keep seeing these resets in code examples (in particular in the reset handler which really triggered me - see exactly what right below), hence my question.
--- End quote ---

Just keep doing what you do, it's perfectly OK since you understand what you are doing and are not writing generic libraries for others.

free_electron:
silicon fixes ...
some startup routines contain code to fix silicon issues.
for many arm processors there is a hidden start block that gets compiled in 'front' of your code and runs before anything else. It fixes hardware issues

SiliconWizard:

--- Quote from: simonlasnier on October 17, 2021, 12:34:31 pm ---You wrote "reset registers relative to clocks (for a reason I don't know, as those are indeed reset values)" (in bold italic in the quote) - that's it ha ha   ;D ;D That's the one I saw in the Reset Handler which I did not understand either.

--- End quote ---

Yeah. That's where comments would actually be welcome. Could be because of some silicon issue on some parts, or because they are assuming the "reset handler" could be called from other contexts than hardware resets... dunno. Again do not necessarily assume it is useful in your case just because some vendor's engineers wrote this either.

First thing to do would be to read the errata doc for the part you're using.
If you don't see anything related to this in it - you can probably safely assume clocks start with their default config upon reset.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version