If the NRF52833 is soft reset, can I read the value of the last recorded RTC counter?

Hi, please forgive my awkward English sentences.

Situation: A soft reset occurred while measuring calendar time.

Purpose: I want to know when the soft reset occurred.
[The purpose is to estimate the time when the reset occurred]
[The purpose is not to estimate the current time].

Question: When a reset occurs, does the value in the last count register of the RTC stay the same? Or does it get reset?

(If it is retained, is it possible to read the value stored in the RTC's count register?)

Thanks for reading.

Parents
  • Hi,

    That value is not retained upon reset. But since the reset is a soft reset, what you could do is find out where the reset is triggered, and add some code there to store the time to non-volatile memory.

    And regarding your English, no need to worry. I would even say it's above average here, we get questions from all over the globe! Thanks for stating your question so clearly.

    Best regards,

    Raoul

  • Hello again, Mr. Raul.
    Thank you very much for your response.

    Regarding your answer:
    We do not use the Zephyr library.

    However, I agree with your workaround.

    In soft reset
    1) Find the location where the reset is triggered.
    2) Add code there to save the time to non-volatile memory.

    -------------------------------------------------------------------------

    My development environment is (Segger Embedded Studio, SDK17.1). - nrf52833 DK

    1.)
    I am checking the reset status via sd_power_reset_reason_get.
    This way, after the reset has occurred, I can tell if it happened or not.
    However, an initialized RTC does not tell you when the soft reset time has occurred.

    2.)
    Using non-volatile memory before a soft reset occurs
    The issue of wear and tear when using flash memory to store time at short intervals was mentioned.


    What I tried: (Reset behavior :Soft reset does not initialize ram)
    Before the reset occurred, we stored the calendar time every second as a non-initializing variable.
    After the reset occurred, we checked the time of the uninitialized variable value in the reset trigger.

    This method does what I want it to do,
    but is there a more efficient way or structure to save current consumption?

    Thanks for reading.

  • Hi,

    Your suggestion using .noinit sounds like a good one. However I think that this requires the CPU to be awake every second to store the RTC value to RAM. If your application is going to be active anyway, this is fine.

    But if the CPU is not doing much, I think it could be better to just write the RTC to flash once in the code that triggers the soft reset. Then the device can sleep (with RTC on) the rest of the time. With regards to wear and tear, I assume you won't soft reset often, so there shouldn't be many writes. The Flash Data Storage module also does some wear leveling, so it should be fine.

    Best regards,

    Raoul

  • Hello again, Mr. Raul.
    Thank you very much for your response.

    Regarding your answer:
    I also want to write code to trigger a soft reset so that the RTC only flash once.

    However, the reset triggers I know of check the status after the reset occurs, so if I don't do a .noinit, the RTC will be initialized.

    So, if I can only write the RTC to flash memory once, it should be done just before the soft reset occurs when the reset trigger occurs.

    My Questions:
    do you mean pre-storing the RTC value in flash memory by detecting the trigger just before the reset occurs?
    If so, what method do you mean by reset trigger?

    Thanks for reading.

  • Hi,

    No, I didn't mean prestoring the RTC (which would have to be done every second).

    What I mean by "triggering" is just that if this really is a soft reset, then some reset function is being called somewhere in your code. This will almost certainly be NVIC_SystemReset()

    Because it is just some code that executes, you "luckily" have the chance to store the RTC before the reset function is called. If this was a hardware reset you wouldn't be able to.

    If you know that the NVIC_SystemReset() is being triggered from the same place every time, you could store the RTC right before that. And if you don't know where the reset is being triggered, then you could modify NVIC_SystemReset() itself to add a flash write before actually resetting. Just make sure that the flash write completes successfully.

    Alternatively, you can use .noinit RAM as you suggested earlier.

    Thanks for reading!

    Best regards,

    Raoul

Reply
  • Hi,

    No, I didn't mean prestoring the RTC (which would have to be done every second).

    What I mean by "triggering" is just that if this really is a soft reset, then some reset function is being called somewhere in your code. This will almost certainly be NVIC_SystemReset()

    Because it is just some code that executes, you "luckily" have the chance to store the RTC before the reset function is called. If this was a hardware reset you wouldn't be able to.

    If you know that the NVIC_SystemReset() is being triggered from the same place every time, you could store the RTC right before that. And if you don't know where the reset is being triggered, then you could modify NVIC_SystemReset() itself to add a flash write before actually resetting. Just make sure that the flash write completes successfully.

    Alternatively, you can use .noinit RAM as you suggested earlier.

    Thanks for reading!

    Best regards,

    Raoul

Children
  • I understand what you mean.
    Thanks for the good suggestions.

    However, I have tried logging everywhere NVIC_SystemReset() is present in my code, but the log output when reset occurs does not work anywhere.

    I would like to share my development environment and experimental conditions to see if there is a problem.

    -------------------------------------------------------------------------------------
    Development environment:
    I have configured my project based on the (ble_app_buttonless_dfu) example in (SDK17.1) of NRF52833.

    Reset behavior:
    Reset from programmer v3.0.3 of nRF_Connect for desktop.

    ---------------------------------------------------------------------------------------
    Result:
    - Confirmed that ram was not cleared and .noninit works.
    - After reset, output log with (sd_power_reset_reason_get) value 0x04 (=reset detected in soft reset).

    --------------------------------------------------------------------------------------
    questions:
    1) Is nRF_Programmer an inappropriate way to cause an artificial soft-reset?
    2) Can I get an explanation of the part about modifying NVIC_SystemReset() itself?
    When a reset occurs, I don't know where NVIC_SystemReset() comes into play.

    Thanks for reading.

  • Hi,

    I think there was a misunderstanding. Have you been using nRF Programmer to "soft reset" the device, all this time?

    When I talked about soft resets, I meant ones triggered by the device itself, through code. For example code that you added yourself, or some error handling code somewhere. I thought you wanted to find out at what time an error triggered a soft reset.

    Does that answer question 2?

    nRF Programmer will soft reset your device by directly accessing a hardware register - probably the RESET register in CTRL-AP, or perhaps the SYSRESETREQ bit in AIRCR (the register that NVIC_SystemReset writes to). See soft reset. This means that no code get's executed before reset. The device itself doesn't know when it will reset, it just suddenly happens!

    So, regarding 1: Using nRF Programmer is not appropriate if you want to try storing the RTC to flash. You can't trigger the reset externally. it would have to follow some execution path on the device itself, so you can add a flash write operation.

    It should be okay to use nRF Programmer if you are testing the .noinit RAM method.

    However, since you mention you're using a BLE sample, I realise that writing to flash is actually not a good idea. If the SoftDevice is enabled, soft resets should normally be done through SD_NVIC_SystemReset, which you can't modify. Also, the SoftDevice might trigger SD_NVIC_SystemReset by itself, and you won't have the chance to write the RTC to flash at all.

    So it's great that .noinit RAM works for you. This is your only option.

    Best regards,

    Raoul

  • Hello again, Mr. Raul.

    All answers have been completed.
    I was able to learn a lot about it.

    In the meantime, thank you for being so kind to answer our many questions.

Related