TimeStamp in nRF52832

[Sunil vignesh]

Hi, 

I am using nRF52832, SDK16.0

with SES

Is that nRF52832 have able to send timestamp through BLE.  is that hardware able to calculate timestamp  

will it act as REAL TIME CLOCK 

[Einar Thorsrud]

Hi,

You can use the RTC peripheral in the nRF to keep time, but remember that the RTC will be reset when the chip is reset for any reason. Also, there is no HW for mapping the RTC ticks to time and date, so you need to keep the calendar in SW. If this is not acceptable, then you need to use an external dedicated RTC chip.

[Sunil vignesh]

My case is . I need to read the sensor data and through value to the mobile app. device has to connect the mobile phone daily. and mobile app it send data to server. there it will have date time respective sensor data .

but if the device not connected to mobile for two days . the sensor data will be stored in external EEPROM / FLASH but i need to send timestamp . to match the database.

Can you give solution for that

[Einar Thorsrud]

I see. If you are happy with the risk of getting an incorrect timestamp in case of a reset, then you can use the internal RTC (perhaps using the app timer library and a repeated timer to update your timekeeping SW). We do not have any official examples for that, but you can refer to nrf-calendar-example.

[Sunil vignesh]

Here SW, are mentioning flash storage ?

internal RTC is a counter right? . i have to count the time until reset or power off. When it again power up the data will be lost right?

i will refer that example

[hmolesworth]

A tip is to keep the current time value in RAM memory that is not initialised on a reset. On a cold start reset where the RAM does not contain a valid RTC value then the time value would be set to zero and a companion value set to some fixed constant; this latter fixed constant can subsequently be used following a reset to indicate validity of the RTC time. This allows the RTC to continue with only time lost while the reset takes place. This is sample code for both SES and IAR:

// Segger Embedded Studio format
// Place following data in section .noinit so it doesn't get wiped on a reset
  static volatile uint32_t mIamInitialisedRTC __attribute__((section(".non_init"))); // Valid data indication for this data
  // 32-bit unsigned RTC time
  static volatile uint32_t mRTC_Timer         __attribute__((section(".non_init")));
// End - Place following data in section .noinit so it doesn't get wiped on a reset

// IAR Format:
// Place following data in section .noinit so it doesn't get wiped on a reset
#pragma default_variable_attributes = @ ".noinit"
  static volatile uint32_t mIamInitialisedRTC; // Valid data indication for this data
  // 32-bit unsigned RTC time
  static volatile uint32_t mRTC_Timer;
#pragma default_variable_attributes =
// End - Place following data in section .noinit so it doesn't get wiped on a reset

Care has to be taken over the type of reset and applicable errata, since there are conditions that can corrupt RAM. The RAM area for segment .noinit also has to have power enabled regardless of operating mode (eg in system Off).

In practice this works well; resets are rare (ideally only happen once when battery first installed) and only have minimal impact on RTC time.