• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 747 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.

Linux/AM3358: Data abort writing to RTC KICK0R register

Bill Morgan
Expert 1550 points

Part Number: AM3358

Tool/software: Linux

Hi,

I am debugging an issue with new hardware causing a data abort writing the unlock code 0x83e70b13 to the KICK0R register 0x44e3e06c.

This is during execution of uboot-spl.

If I look at registers at 0x44e3e00 and following in Lauterbach data.dump window, they are all question marks ????????.

Any idea on what would cause this?

Thanks.

  • 0
    TI__Guru**** 393215 points
    Please provide more details, Linux/U-boot version, EVM/custom board, 32kHz crystal availability, etc...
  • 0 in reply to Biser Gatchev-XID
    Expert 1550 points
    ti-u-boot-2017.01
    custom board
    32kHz clock available.

    this is new custom hardware. We just discovered missing ground to VSS_RTC A5 and are working to correct it now.

    Could that cause this data abort?
  • 0 in reply to Bill Morgan
    Expert 1550 points
    we have added missing ground to A5 and it did not resolve this issue.
  • 0 in reply to Bill Morgan
    TI__Guru*** 125430 points
    Do you have a 32 kHz crystal populated? Normally the reason registers show up as ??? is because there's not any clock provided to them. I've seen people run into issues when configuring RTC_OSC_REG. Specifically, bit 3 chooses between an internally derived 32k clock (divided down from the high speed clock) or an externally provided crystal. If you select the external crystal but don't have one populated (or it can't oscillate properly, etc) then you end up with no clock being provided to the RTC subsystem. This would result in the ??? behavior, and if you access that register space can cause an abort/hang.

    Can you check in your code -- how are you configuring RTC_OSC_REG? Is that perhaps happening just before you access the KICK register that hangs? That might be an artifact of improper RTC_OSC_REG configuration.
  • 0 in reply to Brad Griffis
    Expert 1550 points
    we found a hardware issue related to the RTC core power supply configuration and have corrected it.