• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 364 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3358: RTC alarm update issue

gustavo ramirez
Prodigy 10 points
Part Number: AM3358
Other Parts Discussed in Thread: AMIC110

I'm developing software for AM3358BZCZ100 using linux.

 

When using the "bbbrtc" (https://github.com/bigjosh/bbbrtc) as testing starting point I found that using the function cmd_long_reset there is an issue working with AM3358BZCZ100  RTC registers

During the test the sequence:

1.-freeze the RTC  (  set32reg( base , RTC_CTRL_REG ,  0x00);     // Write a 0 to bit 0 to freeze the RTC so we can update regs)

2.- write desired ALARM and ALARM2 timing information.

3.- read now, alarm and alarm2 registers.

After that, reading the NOW RTC registers (starting in "0H" as in "20.3.5 RTC Registers" "Table 20-63. RTC Registers" from "AM335x and AMIC110 Sitara™ Processors" "Technical Reference Manual"

(SPRUH73Q October 2011–Revised December 2019)

the actual time is shifted 3 hours ahead of original value.

I made a workaround re-writing the NOW registers with previous read data and it worked... but I believe this is not expected behavior from RTC.

Is there a different procedure to operate the RTC ?

  • 0
    TI__Guru 69707 points

    Hi Gustavo,

    the Processor SDK RTOS for AM335x (http://software-dl.ti.com/processor-sdk-rtos/esd/AM335X/latest/index_FDS.html) contains low-level RTC sample code under pdk_am335x_1_0_16/packages/ti/starterware/examples/rtc/, I suggestion you inspect this and/or used this as a known-good reference point.

    Other than that make ure you follow all the read/write processes exactly as shown in the Technical Reference Manual chapter you already found. Just because you found some code on Github doesn't necessarily mean it follows the right process and strictly obeys to the required steps.

    You can also try experimenting with reading the 'hour' register value differently. For example read it and print its actual HEX value. Or read it multiple times. I find it odd that it would always be 3 hours difference so you can probably figure out exactly what is causing it by experimenting with and breaking down the code you already have some more.

    Regards, Andreas