Software reset flag (SFTRSTF) in RCC CSR register: what source?

[jdaalwijk9]

Posted on April 09, 2013 at 11:52

Hi all,

I'm currently working on a custom bootloader. Whenever a reset occurs, it should check if that reset was initiated by the user application. The user application generates a reset by calling the NVIC_SystemReset function. It seemed logically to me, that this equals generating a software reset so i could check the SFTRSTF flag in  RCC_CSR. However, it isn't set when calling NVIC_SystemReset. The reference manual RM0008 states that it is ''Set by hardware when a software reset occurs.'' [RM0008 rev 14,page 148]. So, I'm wondering what causes the SFTRSTF-flag bit to be set by hardware as stated in the reference manual? I'm currently setting the flag manually before calling NVIC_SystemReset, but I'm not sure if that's a correct solution. Regards Jesper.

[Tesla DeLorean]

Posted on April 09, 2013 at 16:52

With the F4 it definitely signals when using NVIC_SystemReset()

if (PWR_GetFlagStatus(PWR_FLAG_SB))
puts(''System resumed from STANDBY mode'');
if (RCC_GetFlagStatus(RCC_FLAG_SFTRST))
puts(''Software Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_PORRST))
puts(''Power-On-Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_PINRST)) // Always set, test other cases first
puts(''External Pin Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_IWDGRST) != RESET)
puts(''Watchdog Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_WWDGRST) != RESET)
puts(''Window Watchdog Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_LPWRRST) != RESET)
puts(''Low Power Reset'');
if (RCC_GetFlagStatus(RCC_FLAG_BORRST) != RESET) // F4 Usually set with POR
puts(''Brown-Out Reset'');
RCC_ClearFlag(); // The flags cleared after use

[jdaalwijk9]

Posted on April 09, 2013 at 21:43

Thanks for your reply Clive1. I should have mentioned the fact that I'm using a STM32F103RB controller. Furthermore, I'm using a GCC toolchain (using Raisonance Ride IDE) and ST peripheral lib version 3.50.

Should NVIC_SystemReset() trigger the SFTRSTF-flag on an F1 too? And are there any other sources that will cause this bit to be set by hardware?

[Tesla DeLorean]

Posted on April 09, 2013 at 23:26

I figured it was an F1 from the RM0008 reference, but I don't have one on the bench right now.

Observations on the F4 : The bits are sticky, the debugger sets the soft reset bit when it initially brings the code up. It does not get set when pressing the reset button on the board, or when the power is cycled.

[waclawek.jan]

Posted on April 10, 2013 at 09:23

> It seemed logically to me, that this equals generating a software reset so i could check the

> SFTRSTF flag in  RCC_CSR. However, it isn't set when calling NVIC_SystemReset. How exactly do you check for that? I could imagine that various debugging tools may be intrusive enough to ''spoil'' the reset-source flags, so I'd check this without a debugger being involved. JW

[waclawek.jan]

Posted on April 10, 2013 at 09:35

> It seemed logically to me, that this equals generating a software reset so i could check the

> SFTRSTF flag in  RCC_CSR. However, it isn't set when calling NVIC_SystemReset. How exactly do you check for that? I could imagine that various debugging tools may be intrusive enough to ''spoil'' the reset-source flags, so I'd check this without a debugger being involved. JW

[zzdz2]

Posted on April 10, 2013 at 18:30

Just tested it with STM32F103C8.

After power-on PINRSTF and PORRSTF are set. After soft resetPINRSTF and SFTRSTF are set. Test code:

// reset test:
if (RCC->CSR & RCC_CSR_PINRSTF)
puts(''pin reset
'');
if (RCC->CSR & RCC_CSR_PORRSTF)
puts(''POW reset
'');
if (RCC->CSR & RCC_CSR_SFTRSTF)
puts(''Soft reset
'');
// power on: make soft reset
if (RCC->CSR & RCC_CSR_PORRSTF)
{
RCC->CSR |= RCC_CSR_RMVF;
beep(800, 40);
sleepms(4000);
NVIC_SystemReset();
}

[jdaalwijk9]

Posted on April 11, 2013 at 09:59

Thanks all for your effort. This morning I re-tested the issue. NVIC_SystemReset() does set the SFTRSTF-flag as Knik confirmed. It must have been an debugger side-effect which prevented the flag to be set in my previous tests I guess, though I remember testing it without the debugger.

My final question in this thread remains: are there any other causes that'll set this flag, apart from NVIC_SystemReset()? I assume it is the only source but I'd like to know your thoughts on this one.

[jdaalwijk9]

Posted on April 11, 2013 at 10:04

Thanks all for your effort. This morning I re-tested the issue. NVIC_SystemReset() does set the SFTRSTF-flag as Knik confirmed. It must have been an debugger side-effect which prevented the flag to be set in my previous tests I guess, though I remember testing it without the debugger.

My final question in this thread remains: are there any other causes that'll set this flag, apart from NVIC_SystemReset()? I assume it is the only source but I'd like to know your thoughts on this one.

[Tesla DeLorean]

Posted on April 11, 2013 at 19:53

Architecturally it would be anything that sets SYSRESETREQ