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

AM3359: ROM code changes between SR1.0 and SR2.1

Juan Gonzales
Mastermind 37340 points
Part Number: AM3359


one of my customers have been in production for 1+ years on AM3359 design.  He recently build slightly modified boards (no changes to AM3359) and new batch of boards do not boot.  We have checked sysboot pins and trace vectors to narrow down issue.  What is odd is we are selecting a sysboot pin configuration that does not involve MMC yet trace vectors seem to indicate chip is trying to boot from MMC.

to debug this we have disconnected ethernet hardware for now to avoid issues related to errata.

At the moment, one big question we have is if there are any key ROM code changes we should be aware of between these silicon revs (1.0 vs 2.1).

Thank you in advance

  • 0
    TI__Guru**** 393215 points
    What are your SYSBOOT settings?
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 37340 points
    we have used three different settings, the last one was

    SYSBOOT[15:0] 0100001000110010.

    yielded trace vectors
    1. 000080BE
    2. 00018000
    3. 00100020
  • 0 in reply to Juan Gonzales
    TI__Guru 63385 points

    Please provide more information related to your concern over Ethernet connectivity and specify which Advisory number you are trying to avoid.

    There were some ROM code changes related to Ethernet boot, but the SYSBOOT value provided in your previous post does not have include Ethernet in the boot sequence.

    It may be helpful if you read the control_status register to verify the actual SYSBOOT value latched on the rising edge of reset.

    Regards,
    Paul

  • 0 in reply to peaves
    TI__Mastermind 37340 points
    I was referring to errata advisories 3.1.4 and 3.1.6 which are essentially the same. To ensure we are not running into a bad work-around for this errata, we have completely disconnected GMII2_CSR signal from AM3359 hence there should be no conflicts with NAND boot now.

    I will check control_status register. In addition we are also swapping AM3359 device (to ensure we are not seeing issue with damaged device) and reading sysboot pins and trace vectors on older working boards.

    that said, we are trying to boot from NAND flash. No matter what sysboot configuration we try, trace vectors seem to indicate MMC boot failure even when sysboot is such that MMC is not even part of boot sequence. Is there a document that describes to ROM code changes?
  • 0 in reply to Juan Gonzales
    TI__Guru**** 393215 points

    Juan Gonzales said:
    we have used three different settings, the last one was SYSBOOT[15:0] 0100001000110010.

    Hi Juan,

    For NAND boot please try setting SYSBOOT[9] = 0.

  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 37340 points

    Hi Biser,

    1) we tried setting sysboot[9] but no difference.  we are getting the values that are latched from Control_status register via CCS. 

    2) we also got a second board delivered and we see same behavior, hence probability of device acting this way because it is damaged is pretty low.  I am still puzzled as to why ROM code will fail to boot device and trace vectors would report MMC boot failure when MMC is not even an option on the sysboot configuration the customer is currently using. 

    Since we has already been thru the exercise of trying different bootsys configurations before I started this post, and going thru errata document, I thought perhaps there was a subtle change in the ROM code we needed to be aware of, hence the title of my post.  We are very puzzled and stuck on what else to try. 

  • 0 in reply to Juan Gonzales
    TI__Guru* 89485 points

    Hi Juan,

    are you able to probe any of the NAND signals?  Can you check CSn (or even REn) during boot  These should toggle to indicate the ROM is trying to access the NAND.  Also, probe the WAIT0 signal.  This should be mostly high, but might toggle low for a bit, and is the BUSY signal from the NAND.


    Once you establish the processor is attempting to boot from the NAND, ensure that the NAND is properly programmed.  Have you tried to reprogram the NAND after a board modification?  Is it possible to boot from another source (maybe into u-boot) and perform reads of the NAND to ensure the contents are proper, especially the first block?

    Also, try performing several boot-ups, and connect to JTAG to see where the PC is, and note down the value.  It should be cycling through each of the boot sources. 

    Regards,

    James