AM3352: RTC register to keep data after warm reset

Hello Kasai-san,

This thread was assigned to the correct engineer. Please allow some time for a response.

Hello Tetsuro Kasai-san,

Thank you for your query !

The behavior in case of entering number outside a digit range in its corresponding bitfield is NOT officially documented in the TRM. The Section, Time/Calendar Data format generally specifies:

I think that there may be three possibilities:

1. The hardware interface logic behind the ALARMSEC1 and ALARMSEC0 bitfields may apply BCD format validation / overflow protection not allowing 0x6-0xF and 0xA-0xF value entries into the bitfields, regardless of the 4-bit size of the bitfields. For example writing of 0x9 and 0xC may lead to actually storing an unexpected 8-bit number: 0x32 (where 2-nd digit 0x3 = 9%6  and 1-st digit 0x2 = 12%10 ) because of a wrap around effect when 2-nd digit is outside the range (0-5) and 1-st digit is outside the range (0-9). This means that even with RTC functioning disabled, but with OCP interface clock mandatory enabled, overflow protection could make complete range utilization impossible. 

2.  The OCP interface logic may NOT apply a range validation but has an undefined behavior upon entering value outside the specified BCD valid ranges. 

3. No hardware check for overflow in input digits, in which case the complete bit-size determined range can be used. If this storage solution works, I would even recommend the ALARM_YEARS_REG as it has a 2x4-bit storage size. The ALARM_SECONDS_REG has a 4-bit + 3-bit = 7-bit storage size.

To make sure what the real behavior is: I need to double check this with an AM335x RTC functional design expert which may take time. I will let you know as soon as I get the feedback. 

Can you tell me exactly, how many more bits does customer want to store ? Depending on the number of bits we may have another solution.

Your patience is appreciated !

Best Regards,

Anastas Yordanov

Hi Anastas Yordanov,

Thank you for your reply.

I look forward the feedback from RTC functional design expert.

Anastas Yordanov said:

Can you tell me exactly, how many more bits does customer want to store ? Depending on the number of bits we may have another solution.

Your patience is appreciated !

Let me check this with customer and come back to you.

It would be good if OCMCSRAM with NOINIT can be used as discussed in the original thread.

https://e2e.ti.com/support/processors-group/processors---internal/f/processors---internal-forum/1664122/am3352-the-way-to-save-data-before-and-after-watch-dog-reset/6418415?tisearch=e2e-sitesearch&keymatch=%2525252520user%252525253A540505

Best Regards,

Kasai

Hello Tetsuro Kasai-san,

Tetsuro Kasai said:

It would be good if OCMCSRAM with NOINIT can be used as discussed in the original thread.

I have asked our Sitara memory expert about WD warm-reset insensitive area of the  AM335x OCMC SRAM as I could not deduce this from the TRM itself.

I am still waiting on his response.  

Thanks

Best Regards,

Anastas Yordanov

Hi Anastas Yordanov,

Did you get any feedback for  ALARMSEC1 and ALARMSEC0 register?

Thank you.

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

I am still awaiting the experts to:

- confirm if ALARM/YEARS registers BCD entries can be normally used across their full binary range for 7-bit (SECONDS) or 8-bit (YEARS) storage

- reply which AM335x OCMC SRAM area is WD warm-reset insensitive so it can be declared as a "no-init" data section in linker file.

I will let you know as soon as I get their response (earliest by end of this week).

Thanks for your patience !

Best Regards,

Anastas Yordanov

Hi Anastas Yordanov,

Sorry for pushing you again.

Did you get any update?

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

Yes I got feedback from both experts today.

1. Regarding the AM335x RTC registers - ALARM SECONDS and YEARS the expert told me that the internal RTC specification does not provide any insight to answer the question. The responsible member of the RTC IP design team is currently out of office, and the expert approached the team leader in order to get the feedback from another member.

Q1: The expert asked me if in the meantime customer had tried writing to these RTC registers and checked the values before and after WD warm reset is triggered ?

2. Regarding the OCMC SRAM option I had the following reply from the second expert:

The expectation is that the AM335x OCMC SRAM should not be affected by warm resets (in particular by WD reset). Contents should be maintained across a warm reset, and its power domain also is maintained. The customer should however check which of the OCMC SRAM area is NOT reserved and NOT cleared by any software during the bootloading stage.

Thanks

Best Regards,

Anastas Yordanov 

Hi Anastas Yordanov,

Anastas Yordanov said:

1. Regarding the AM335x RTC registers - ALARM SECONDS and YEARS the expert told me that the internal RTC specification does not provide any insight to answer the question. The responsible member of the RTC IP design team is currently out of office, and the expert approached the team leader in order to get the feedback from another member.

Customer tried to write 0xF to ALARM_SECONDS_REG, issue warm reset and then tried to read it. They could read 0xF. They want to make sure if there is any risk from design point of view. Could you keep following them up?
We told customer that supplier cannot garantee it since it is out of specification.

Anastas Yordanov said:

Q1: The expert asked me if in the meantime customer had tried writing to these RTC registers and checked the values before and after WD warm reset is triggered ?

Yes, as I mentioned above, they tried it and read it.

Anastas Yordanov said:

The expectation is that the AM335x OCMC SRAM should not be affected by warm resets (in particular by WD reset). Contents should be maintained across a warm reset, and its power domain also is maintained. The customer should however check which of the OCMC SRAM area is NOT reserved and NOT cleared by any software during the bootloading stage.

Thank you. If there is available region where even ROM does not use, they can use the region right?

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

Anastas Yordanov said:

1. Regarding the AM335x RTC registers - ALARM SECONDS and YEARS the expert told me that the internal RTC specification does not provide any insight to answer the question. The responsible member of the RTC IP design team is currently out of office, and the expert approached the team leader in order to get the feedback from another member.

The customer tests show, there is no active hardware protection (overwrite) logic that is triggered when input is outside of expected BCD range. The behavior for "outside the specific BCD digit context" values is not covered in the official spec. But we are still waiting on some confirmation on the existing risks from the RTC hardware design team. 

Tetsuro Kasai said:

Thank you. If there is available region where even ROM does not use, they can use the region right?

Yes if it is not used by ROM and also NOT overwritten in any of the boot-loading stages, it should be usable. As far as I understand the SRAM memory map depends on the device type - GP or HS. 

2. Alternative solution:

From the below Table, Reset Sources of the Chapter, Power, Reset, and Clock Management / Section, Reset Management / Section, Reset Characteristics  we can see that the DRAM area contents is preserved upon WD and other warm resets. According to table note (1), the AM335x ROM loader does not use DRAM to preserve data.

Is it an option for the customer to use, provided that the selected DRAM area is not touched (i.e. re-initialized) by the SBL bootloader software during warm-reset re-boots ? 

Thank you !

Best Regards,

Anastas Yordanov

Hi Anastas Yordanov,

Anastas Yordanov said:

The customer tests show, there is no active hardware protection (overwrite) logic that is triggered when input is outside of expected BCD range. The behavior for "outside the specific BCD digit context" values is not covered in the official spec. But we are still waiting on some confirmation on the existing risks from the RTC hardware design team. 

Could you let me know when you get feedback?

Anastas Yordanov said:

Yes if it is not used by ROM and also NOT overwritten in any of the boot-loading stages, it should be usable. As far as I understand the SRAM memory map depends on the device type - GP or HS. 

I will let customer know that.

Anastas Yordanov said:

Is it an option for the customer to use, provided that the selected DRAM area is not touched (i.e. re-initialized) by the SBL bootloader software during warm-reset re-boots ? 

Sorry, I missed telling that customer does not want to use DRAM. 

Thank you.

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

Thank you for your prompt replies.

I will let you know as soon as we have the feedback from the RTC design team member.

Thanks 

BR,

Anastas

Hi Anastas,

Cusotmer is pushing us becasue they need to answer it to their end customer within this week. They need the information within tomorrow.

Could you push expert to check if it possible to use all bit filed of ALARM SECONDS and YEARS in ALARM_SECONDS_REG register? 

Thank you.

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

I would like to apologize that I may have mis-leaded you in our communication. For this customer query with "BCD out-of-range" inputs to the AM335x RTC ALARM (YEARS and SECONDS) registers, as I understand, the same AM335x RTC module registers output behavior was NOT specifically tested on EVM or other boards. Hereby the customer expected ALARM (YEARS and SECONDS) registers behavior is NOT guaranteed by TI to be supported by the AM335x integrated RTC.

We can propose to the customer that they perform automatic tests with all numbers in the ranges 0x9A – 0xFF (combined 8-bit size for YEARS) or 0x5A-0x7F (combined 7-bit size for SECONDS). In case the tests do NOT fail, then they can use the ALARM YEARs and ALARM SECONDs for storage purposes within the “scope of their non-standard RTC usage”.

Of course in this case, there will be still some minimal risk and it is at their own responsibility to use this solution.

Did customer performed some tests with freely available OCM SRAM. What is the type of device they use - HS or GP ?

Let me know what are your thoughts  ?

Best Regards,

Anastas Yordanov

Hi Anastas,

Thank you for your feedback.

Is it difficult to check RTL logic circut data? Technically, it should be easy to check how this register is configured by flip flop from RTL.

Actually, this WDT reset is workaround for unexpected EtherCAT PRU-ICSS firmware stall issue. Instead of pushing us to survey complicated things, they compromised to issue warm reset by WDT to recover system. Horiba is quite important customer using a lot of Sitara MPU for many years. There are some important new business. From our sales team point of view, it would be good to show information of RTC ALARM register. However if it is really difficult due to some political circumstances, could you let me know? Based on that information, we try to manage customer.

For SRAM, they need to spend several time to evaluate. It is a bit hard to complete all evaluation by the end of this Thursday. However, we will discuss with them.

Best Regards,

Kasai

Hi Tetsuro Kasai-san,

As requested for the customer's specific workaround, access to the AM335x integrated RTC IP's RTL was provided yesterday, and ALARM YEARS / SECONDS input/output register bitfield logic analyzed by our expert, as follows: 

1. Storage Layer: The registers are implemented using standard flip-flops. There is no hardware  "clamping" or "masking" logic in the write path that prevents a value like 4'b1010 (10) from being stored in a 4-bit register.

   ---

2. Read Path: The read path simply fetches the state of those flip-flops and places them on the rdatap bus. It does not  perform any BCD validation or correction during the read cycle.

   ---

3. The "Functional" Failure: The limitation is strictly in the comparator and carry/increment logic:

        - Comparator: The alarm trigger logic compares the current seconds (which rolls over at 10) against the alarm_seconds.

           If you set the alarm to 10, the seconds counter will go ... 8, 9, 0, 1 .... It will never actually equal 10, so the alarm will never fire.

        - Incrementer: The BCD incrementer logic is designed to detect the transition from 9 to 0 to trigger a carry to the minutes register. It is not

          designed to handle a transition from 10 to 11.

  Conclusion: From a pure register-access (MMR) perspective, it is a transparent 4-bit storage element. From a system-functional perspective, it is a   BCD-constrained field.

Let me know if this information is sufficient for the customer and if we can close the ticket ?

Thank you !

Best Regards,

Anastas Yordanov

Hi Anastas,

Thank you for the detail information.

Anastas Yordanov said:

  Conclusion: From a pure register-access (MMR) perspective, it is a transparent 4-bit storage element. From a system-functional perspective, it is a   BCD-constrained field.

Let me clarify this comment. Can customer use  ALARMSEC0 bit field as full 4-bit register (0000b to 1111b)?

Best Regards,

Kasai 

Hi Anastats,

Thank you for your confirmaiton.

Let me close this thread.

Best Regards,

Kasai