• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 288 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.

AM3352: AM3352 start up fail

Roy Lin1
Intellectual 1080 points
Part Number: AM3352

Hi support team,

Our customer use AM3352 in their products.
They've produced over 100 units, only one of them cannot successfully startup.

1. They use NAND flash for startup, the software such as MLO, uboot are programmed in this NAND flash.

2. After power on, console program six C then shut down.

3. They dump the image data of MLO and uboot, and the image data is correct.
    (The over image size data are garbled.)

4. They maintain original MLO, burn into NAND flash again, can successfully startup.

They have these questions:
1. Why MLO, uboot and NAND are correct, but AM3352 program six C and shutdown.

2. The over MLO image size data should be 0xFF.(They erase all flash when they burning)
    Why it shows garbled data in their case.
    

  • 0
    TI__Guru* 85950 points

    Hi Roy, some questions:

    -the garbled data indicates that maybe the NAND flash was not erased properly, and thus maybe not programmed correctly.  When you dump the data, are you doing a full diff of all the programmed bytes, or just checking certain portions?

    -does this one board repeat the failure?  So if you program it again after a successful startup, does it fail, and then a subsequent programming makes it success again?  Or did it only happen one time?

    -what is your boot order?  It is possible that it is getting stuck in a boot mode between UART and NAND.

    -can you dump the tracing vectors after a failed boot.   There are located at addresses 0x4030Ce40-0x4030CE58.  These may give us some indication on how far the ROM executes.

    -when the board fails to boot, let it continue to run for several minutes to see if you see another set of C on the console.  This should tell us if the watchdog timer is kicking in or if it is truly hung somewhere

    Regards,

    James

         

  • 0 in reply to JJD
    TI__Intellectual 1080 points

    Hi James,

    Thanks for your quick response.
    Here our customer provides the information of the questions you ask in the previous mail.

    -the garbled data indicates that maybe the NAND flash was not erased properly, and thus maybe not programmed correctly.  When you dump the data, are you doing a full diff of all the programmed bytes, or just checking certain portions?
    : They already found the root cause (extra garbage data inside the flash). This one can be ignored.

    -does this one board repeat the failure?  So if you program it again after a successful startup, does it fail, and then a subsequent programming makes it success again?  Or did it only happen one time?
    : for the booting up issue, yes, it always failed to bootup (always stop at Cx6 ). It can be good after re-write the MLO image which is dump from original flash.

    -what is your boot order?  It is possible that it is getting stuck in a boot mode between UART and NAND.
    : They don’t think so since it can be good after re-flush the same MLO image. The booting up sequence is UART0->XIP->MMC0->NAND

    -can you dump the tracing vectors after a failed boot.   There are located at addresses 0x4030Ce40-0x4030CE58.  These may give us some indication on how far the ROM executes.
    : As mentioned, they already re-flushed the MLO image and it goes well now, so they need to re-produce the problem first and then can dump the data you want. the problem is they don’t know when can they duplicate this issue. 

    -when the board fails to boot, let it continue to run for several minutes to see if you see another set of C on the console.  This should tell us if the watchdog timer is kicking in or if it is truly hung somewhere
    :  They waited several seconds (around 10~15 seconds) after it stop at Cx6, so what is the watch dog timeout time inside the controller.


  • 0 in reply to Roy Lin1
    TI__Guru* 85950 points

    Ok, if and when they do reproduce the issue, have them connect with JTAG and record the program counter and tracing vectors.  There may just be something marginal on that one board which is causing the error.

    Regards,

    James