firmware problem after warm reset (not if I power-on)

[filippo2991]

Posted on May 18, 2010 at 17:02

firmware problem after warm reset (not if I power-on)

[filippo2991]

Posted on May 17, 2011 at 13:51

I tried to reset the device using external NRST pin and it works fine, but I see from figure 7 of reference manual (simplified diagram of  the reset circuit) that using the software reset as I do (SCB_AIRCR), and NRST external reset should have exactly the same behaviour but on the contrary in my application NRST works fine and SCB_AIRCR not.

[filippo2991]

Posted on May 17, 2011 at 13:51

Not sure about this last comment, I'm not sure that sticking NRST to GND would not drain too current from VDD leading to hw reset. Need to check

[filippo2991]

Posted on May 17, 2011 at 13:51

I'm sorry for the annoying thread but this is a very important point for me.

I see some strange behaviour: - if I (just before warm warm-resetting) disable clock with the command RCC_RTCCLKCmd(DISABLE)  (it resets BDCR_RTCEN_BB) then after reset the system runs ok _but_ I get the RTC counter lost by command before. - if I don't disable clock, after resets the system halts on the following commands (during rtc configuration). It halts waiting on WaitForLastTask command How can I solve the problem? I must preserve the RTC value and warm resets.

  /* Enable the RTC Alarm interrupt */

  RTC_ITConfig(RTC_IT_ALR, ENABLE); 

 /* Wait until last write operation on RTC registers has finished */

  RTC_WaitForLastTask();

[Tesla DeLorean]

Posted on May 17, 2011 at 13:51

Not seeing enough code to make a judgement. (System initialization, RTC initialization, RTC interrupt code, etc)

You will however need to adapt your RTC/PWR initialization based on whether they are already running/configured. Checking PWR_GetFlagStatus(), Wakeup, Standby, etc. Clearing flags. If things are locking up you need to check that the clocks are correctly configured, and that RTC registers are synchronized. If interrupts are not being handled, and cleared properly, the system will also appear to lock up in a crap storm of interrupts. /* Set the Vector Table base address at 0x08002000 (dopo il bootloader)*/   NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000);  Is it at 0x08002000 or 0x08003000?

[t1]

Posted on May 17, 2011 at 13:51

What do you do after SCB->AIRCR = 0x05FA0004; ?

I noticed in a different thread that the __DSB() function is called. (Data Synchronization Barrier I presume.) ''The DSB operation will complete when all explicit memory accesses before this instruction have completed. No instructions after the DSB will be executed until the DSB instruction has completed, that is, when all of the pending accesses have completed.''

[filippo2991]

Posted on May 17, 2011 at 13:51

Hello guys, thanks for the comments.

I solved the problem just clearing rtc interrupt flags just before enabling interrupts in my rtc_on() routine. (here is the code for reference). But I  don't understand why I need to do this. Thanks

  /* Enable the RTC Second */ 

  RTC_ClearITPendingBit(RTC_IT_SEC);   RTC_ITConfig(RTC_IT_SEC, ENABLE);

  RTC_WaitForLastTask();

    /* Enable the RTC Alarm interrupt */   RTC_ClearITPendingBit(RTC_IT_ALR);   RTC_ITConfig(RTC_IT_ALR, ENABLE); 

 /* Wait until last write operation on RTC registers has finished */

  RTC_WaitForLastTask();

[Tesla DeLorean]

Posted on May 17, 2011 at 13:51

But I  don't understand why I need to do this.

Examine your interrupt handler code, and verify it is executing.