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.

AM3354: data abort in SPL during power on off test

Part Number: AM3354

Linux SDK 2.0. UBOOT 2015.07

During power on off test, there are some boards hang in SPL over thousands cycle power on off test. add more log in SPL, sometimes hang in gpmc_init function., sometimes hang without log of "U-Boot SPL..."

on one hang scenario hang without log output, connect JTAG observe it enter data abort handle, 

From data abort SPSR knows the previous mode is supervisor. and the supervisor LR(R14) register value is a odd address 0x472F07AB, which should be 32bit aligned address.

Load symbol, the assembly around address 0x472F07AB as below, it is after gpmc_init.

and the cp15 data fault register value is 0x4830E048 which is LCD ceiling address register, which is not enabled or accessed in SPL code.

If just change the PC to entry point of SPL to run again, can run over to UBOOT, there should be something impacted CPU running when trigger the symptom. 

What can result in such abnormal?

  • Hi,

    Please expect delayed responses due to the holidays.

    Thanks for your patience.

    Regards,

    Vaibhav

  • Hello Tony,
    Have we booted the non-working boards ever?
    The issue seems more correlated with HW board.

    The disassembly instruction @402f07aa looks normal, which loads r0 with *(0x402f07aa + 0x54)
    The data abort seems triggered by gpmc_init()? It might be related with clock/PRCM after PoR when running power cycling test ?

    Best,
    -Hong

  • Have we booted the non-working boards ever?

    Yes, need to power on off hundreds to thousands cycles to reproduce once fail on the same board.

    he data abort seems triggered by gpmc_init()? It might be related with clock/PRCM after PoR when running power cycling test ?

    This is the phenomena, actually GPMC is enabled in default, and actually enabled by checking PRCM register, and it is the default spl code of SDK.

    The issue seems more correlated with HW board.

    I think so also, like to know what factors to exclude and improve.

  • Hello Tony,
    The issue looks to me correlating with timing/clock/PRCM after reset when running power cycling test.
    Best,
    -Hong

  • Tony, can you confirm the problem only occurs after a power cycle?  For example, does the failure ever occur if you leave the power on and issue a power on reset to the entire system?

    If not, the issue appears to be related to cycling power.  Have you confirmed all power rails have decayed below 300mv before turning power back on?  Have you checked the quality of the power sources when this occurs to confirm there is not an issue with the PCB Power Distribution Network (PDN), where the processor power rails encounter a brown-out condition that causes the supply voltage to drop below the Recommended Operating Conditions (ROC) for very short period of time?