• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1801 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.

Original question:

AM5728: QSPI bootloader issue

Linux/AM4377: QSPI can not boot up after 60 times hard reboot

rance zhuang
Intellectual 570 points

Part Number: AM4377
Other Parts Discussed in Thread: TPS65218

Tool/software: Linux

Dear Sir:

     We use the QSPI nor flash as the first boot device, noramlly, the SPI NOR flash boot up successfully.

The boot up sequence is "QSPI" is first,  "eMMC" is second.  

Strap pin config:   SYSBOOT[4:0]:  01000

     After reboot about 60 times with power off/on, the QSPI nor flash can not output any information, the device can not boot up anymore.

Because the first device is QSPI NOR,  it also influence boot up from eMMC(sdcard), (The ROM code may detect the spi nor uboot, Maybe it loaded, but it can not boot up, so it block it boot up from eMMC)

We have to disturb the SPI NOR clock((short the pin 15 and 16)) , and  let it can boot up from secode boot device eMMC(sdcard).

After boot up from the sdcard,  I use the dd command to dump the SPI NOR flash u-boot part,  and compare with the u-boot.bin which I compiled,  It is the same.

So  I am not sure why this occured after several reboot test? Does the ROM of AM437x can not regonize the NOR flash? or something else.

The console don't have any information, even uboot info.

Could you please help to anaylze the root cause about this?

Thanks

  • 0
    TI__Genius 9510 points

    Please enable  u-boot debug logs.  This will provide more details and insight into the problem.

    An addition debug technical is to step thru the u-boot source code to localize where the problem occurs (CCS debug)

    Also take a memory dump, using CCS, of the ROM code trace vector values (see TRM for more details)

  • 0 in reply to Marcus Cooksey
    Intellectual 570 points
    Hi Marcus Cooksey :
    do you mean open the flag in the u-boot/include/common.h as following when compile the uboot?
    #define _DEBUG 1
    if this method is not right, please help to provide the correct method for uboot debug flag setting.

    Because we didn't reserved the debug port for connect to the CCS, Could we use the dev2mem to read the related registers from Sdcard booting up when the failure occured?
    Thanks
  • 0 in reply to rance zhuang
    TI__Genius 9510 points

    Correct enable #define DEBUG 1.

    You'll need to read the memory at the point when the boot failure occurs. Based on your problem statement, switching to SD boot results in a successful boot. Therefore, the previous boot vectors, when QSPI NOR boot was attempted, are overwritten with the SD boot vector statuses.

  • 0 in reply to Marcus Cooksey
    Intellectual 570 points
    Yes, you are right, if boot from sdcard, we can not detect the correct info. It will be over right.
    So I try the first method and open debug info, and try to reproduce the problem to check if have any info print when failed.
  • 0 in reply to rance zhuang
    Intellectual 570 points
    The QSPI flash can not boot up after quickly power on /off test. If I don't have the CCS tools, do you have any other way to analyze this issue?
    After the QSPI can not boot up, there is no any console info print, even I open the "DEBUG" info for u-boot.

    I dump the uboot from the QSPI first 512 byte and compared with the original u-boot.bin compiled, It all the same.
  • 0 in reply to rance zhuang
    Intellectual 570 points
    There is another phenomen, If the QSPI flash can not boot up, we use the sdcard boot up the device for about 1 or 2 times, and then remove the sdcard, the QSPI flash is also can boot up as usual. We didn't do anything for the QSPI flash.
    Does this phenomen related with HW power sequence or something?
  • 0 in reply to rance zhuang
    Intellectual 570 points
    is there any suguestion?
    Thanks
  • 0 in reply to rance zhuang
    Intellectual 570 points
    If occur this status, we boot up from SDcard, It should be boot up the kernel fully, the QSPI flash can boot up in next power on. If we only boot up uboot in SDCard, the QSPI flash can not boot up in next power on.
    Does the kernel do something for the CPU ? reset or .... ? and let the CPU to a pure status??
  • 0 in reply to rance zhuang
    Intellectual 570 points
    When this phenomen occured, the QSPI flash CS pin always in high. So the CPU can not choose the QSPI flash boot up.
    Does this related with CPU ROM code, it didn't send out the QSPI flash CS signal? Does this related with uboot code?
    Could you please ask your expert help to analysis and pay attention to this issue at the same time?
    Thanks
  • 0 in reply to rance zhuang
    TI__Genius 9510 points

    I suspect the problem is with you power down power on sequence.  Do you have a delay between power cycles?  What happens when a delay is added between cycles?  

  • 0 in reply to Marcus Cooksey
    Intellectual 570 points
    We also suspect the power down sequence, If we do quickly power on/off, the problem occured also quickly. And we add 2~3s delay when power off, it is about 1000 times no problem yesterday.
    But do u any suggestion for power down sequence to solve this?
  • 0 in reply to rance zhuang
    TI__Guru* 92691 points

    Rance, you are probably not getting a proper POR when quickly powering on/off.  What is your power solution?  PMIC or discrete?  I would monitor the reset coming from the power circuitry to determine if you get a proper reset to the processor.  You may have to implement a voltage supervisor in your circuit if you are concerned about getting this to work everytime.

    Regards,

    James

  • 0 in reply to JJD
    Intellectual 570 points
    Hi James:
    Thanks for your support, I will discuss with our HW Engineer about this, I know we use the PMIC tps65218 to control the power of Am4377, And let the HW engineer to implement a method to monitor the reset signal at same to debug this issue.
    And will give you the test result about this.
  • 0 in reply to rance zhuang
    Intellectual 570 points

    Hi James:

       there is another issue about the QSPI flash, the CS and clock pin is going down at the same time,  Acturally, its clock should be delay about 5ns for the CS pin.

     Please refer to the following picture to analyze the issue.

    The NO.4 shows that the td(CS-QSPI_CLK) should have 5ns delay, But the 3td picture shows that they are going down at the same time.Please give a suggestion about How to solve this?

    Does this will influence the power on/off test?

  • 0 in reply to rance zhuang
    TI__Guru* 92691 points
    Rance, i think you have to zoom in much closer to see which signal falls first. Iit almost looks like the clock goes low first, which means technically that's not the first edge after CS active edge. I think the controller is setting up for active high polarity before the CS is active.
    At any rate, i don't think this is really affecting the on/off test. I'd be curious to see what the QSPI bus looks like when you fail to boot from QSPI.

    You should also check if you are violating the power up/down of the QSPI flash. There is a diagram in the QSPI flash datasheet that shows tPWD must be a minimum of 300us to ensure proper initialization will occur. Also, tVSL must be met to ensure you have waited long enough after power up for full device access.

    Regards,
    James