• State
  • Locked Locked
  • Replies 24 replies
  • Subscribers 99 subscribers
  • Views 1784 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.

AM3354 not booting on high state of MII1_RXD0

Steve Deschryver
Expert 1115 points
Other Parts Discussed in Thread: AM3354

Dear,

 We got some boards (5 pcs) with the AM3354 not booting right from the start in production, this is a mature product (> 25k in the field) so we want to know the root cause.

I measured all the power lines and where ok, also the 26MHz clock is running but no other reaction from the AM3354 (no read from NOR, SD, debug output; …)

We use pin MII1_RXD0/GPIO2_21 to detect if an external cable is connected, normally this pin is high (2.2V).

But when I inserted the cable (this pin is than then grounded) the system boots like normal.

I can reproduce this many times on all the boards, any possible reason ?

PS : we don’t use the ENTERNET pins, only as GPIO.

 

Regards,

Steve

  • 0
    TI__Guru**** 393215 points

    Hi Steve,

    What is your SYSBOOT sequence?

    Steve Deschryver said:
    We use pin MII1_RXD0/GPIO2_21 to detect if an external cable is connected, normally this pin is high (2.2V).

    Does this mean that a voltage is present on this pin before the AM335X is powered?

  • 0 in reply to Biser Gatchev-XID
    Expert 1115 points

    Hi Biser,

    The boot settings is SYSBOOT[4:0] = 10111 MMC0 (µSD) , SPI0 (NOR flash), COM0, USB0

                                    SYSBOOT[15:5] = 1100 0000 000 (26MHz, ECC by ROM, CLKOUT1 disabled)

    The voltage on this pin is applied 50µs after the power good output went high of the PMIC,  the external supply is switched on by the Power Good signal.

  • 0 in reply to Steve Deschryver
    TI__Guru**** 393215 points
    Strange, I don't see anything that could cause this from the information you provided so far. I will ask the factory team to take a look at this thread too.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru* 86820 points
    Steve, can you try to read address 0x44e10040, either thru JTAG, or by booting through u-boot? My theory is that on the failing boards, the SYSBOOT pins are being latched differently, and maybe a boot sequence is being chosen that includes Ethernet, and it's getting hung in there because of the voltage on that signal. The register will tell us what SYSBOOT values was latched at reset.

    Regards,
    James
  • 0 in reply to JJD
    Expert 1115 points
    I do have a XDS200 JTAG but never used it, I will give it a go tomorrow.

    But is it normal to have no debug output on, not even the CCC ?

    Regards,
    Steve
  • 0 in reply to Steve Deschryver
    TI__Guru* 86820 points
    You'll only get CCC... if UART is in the sequence. So if it is inadvertently choosing a different boot sequence, you may not see that or anything at all.

    You can also read that register in uboot when you successfully boot (with the cable connected)

    Regards,
    James
  • 0 in reply to JJD
    Expert 1115 points

    Dear,

     I have connected my JTAG and are able to read most of the Registers (example core, ...)

     But I'm not able to read Memory, got ???????? at 0x44E10040 "Control Module control status.

    Is it possible to read the value anther way please ?

  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    But I'm not able to read Memory, got ???????? at 0x44E10040 "Control Module control status.

    I think the Control Module registers should always be enabled, and thus should be readable through JTAG without having to change any other registers.

    If you hover the mouse over the "????????" CCS should display a tool-tip which explains why it can't read the memory. Can you try that, and post the reason why CCS is not able to perform the read.

  • 0 in reply to Chester Gillon
    Expert 1115 points

    On first read after start = CPU View: Could not read 0x44EA0040: execution state prevented access

    But when I then suspend the processor I still have ??????? but only the error = CPU View: Target failed to read 0x44EA0040.

  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    CPU View: Could not read 0x44EA0040: execution state prevented access

    That means CCS can't read memory since the Cortex-A8 is running. With the Cortex-A8 selected in the Debug view, use Suspend (Alt+F8) on the debug toolbar. That should suspend the Cortex-A8 and allow CCS to read memory.

  • 0 in reply to Chester Gillon
    Expert 1115 points

    Now I did reset the cpu and did some single steps and where able to read the memory : 00C00317.

    Found it : Can I found any info on this register, don't seem to be int he SPRUH73K doc ?

  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    Now I did reset the cpu and did some single steps and where able to read the memory : 00C00317

    Decoding that value using the TRM, I get the expected SYSBOOT settings you mentioned previously:

    Steve Deschryver said:
    The boot settings is SYSBOOT[4:0] = 10111 MMC0 (µSD) , SPI0 (NOR flash), COM0, USB0

                                    SYSBOOT[15:5] = 1100 0000 000 (26MHz, ECC by ROM, CLKOUT1 disabled)

    i.e. the SYSBOOT settings latched at cold-reset are the expected ones.

    Of the possible boot source, which one do you expect the board to boot from?

    [your first post mentioned no signs of trying to boot from either SD, NOR or UART]

  • 0 in reply to Steve Deschryver
    Expert 1115 points
    The value 0x17 read is correct for a boot sequence MMC0 / SPI0 / COM0 / USB0.

    I'm a novice to CCS debug but is there another way to check what the processor is doing after power on ?
  • 0 in reply to Chester Gillon
    Expert 1115 points

    Possible boot sequences are :

    1. I also tested it with a bootable µSD card (works on other devices) no reaction on the pins.
    2. There should be an image in the NOT flash to boot from, no reaction on the SPI pins.
    3. We don’t boot from UART but normally if there isn’t a µSD card nor image in the NOR flash we get CCCCC on the uart output. Not now !

    To me it seems the A8 is running some internal code from ROM (all power lines are ok and the xtal is at 28MHz).

  • 0 in reply to Chester Gillon
    Expert 1115 points
    Normaal BOOT sequences are :

    1. I also tested it with a bootable µSD card (works on other devices) no reaction on the pins.
    2. There should be an image in the NOT flash to boot from, no reaction on the SPI pins.
    3. We don’t boot from UART but normally if there isn’t a µSD card nor image in the NOR flash we get CCCCC on the uart output. Not now !

    To me it seems the A8 is running some internal code from ROM (all power lines are ok and the xtal is at 28MHz).
  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    I'm a novice to CCS debug but is there another way to check what the processor is doing after power on ?

    The BOOT ROM stores tracing vectors in memory, which record how it tried to boot. This is detailed in section 26 Initialization of the AM335x TRM.

    http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips#Analyzing_Boot_Issues_with_CCS_and_JTAG contains a DSS script which can be run from CCS to collect (and decode) useful registers for debugging failures to boot - including decoding the ROM tracing vectors. Suggest you follow the instructions on the referenced Wiki page and post the results of the DSS script.

    [It would also possible to use CCS single-step the BOOT ROM in assembler from a processor reset, but that would be tedious as there is no source code]

  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    (all power lines are ok and the xtal is at 28MHz)

    Is 28MHz a typo?

    For SYSBOOT[15:14] = 11b the expected Crystal Frequency is 26 MHz.

  • 0 in reply to Chester Gillon
    Expert 1115 points
    Yes, it should be 26MHz (2MHz more then the normal 24MHz)

    I'm looking at the Wiki page and notice the PC is at 0x20088 (interrupt table vectors), probable in a dead loop.
  • 0 in reply to Chester Gillon
    Expert 1115 points
    I'm looking at the Wiki page and notice the PC is at 0x20088 (interrupt table vectors), probable in a dead loop.

    I then cleared the complete L3 RAM to check if it is used when booting and ... now the board boots correctly !
  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    I'm looking at the Wiki page and notice the PC is at 0x20088 (interrupt table vectors), probable in a dead loop.

    0x20088 is documented in the AM335x TRM as the "Pre-fetch abort exception default handler" dead loop. So, if the PC is at 0x20088 it sounds like the boot ROM has crashed/halted due to an exception.

    Steve Deschryver said:
    I then cleared the complete L3 RAM to check if it is used when booting and ... now the board boots correctly !

    Is the act of clearing the L3 RAM making the board boot repeatable?

  • 0 in reply to Chester Gillon
    Expert 1115 points
    Yes, boots every time now. Even switched off the power supply for 5 minutes and booted again correctly.
    Will repeat the test again tomorrow (power off now) and also check this on another board.

    Thanks for the help given.
  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    I'm looking at the Wiki page and notice the PC is at 0x20088 (interrupt table vectors), probable in a dead loop.

    There is the following note for Table 26-3 RAM Exception Vectors in the AM335x TRM:

    The default handlers for pre-fetch and data abort are performing reads from CP15 debug registers to retrieve the reason of the
    abort:
    • In case of pre-fetch abort: the IFAR register is read from CP15 and stored into R0. The IFSR register is read and stored into the R1 register. Then the ROM Code jumps to the pre-fetch abort dead loop (20088h).
    • In case of data abort: the DFAR register is read from CP15 and stored into R0. The DFSR register is read and stored into the R1 register. Then the ROM Code jumps to the data abort dead loop (2008Ch).

    Therefore, after attaching the processor after a failure case when the PC is at 0x20088 also note:

    - The R0 (saved IFAR) value

    - The R1 (saved IFSR) value

    The saved Instruction Fault Address Register (IFAR) and Instruction Fault Status Register (IFSR) should hopefully give more indication of what triggered the Pre-fetch abort exception.

  • 0 in reply to Chester Gillon
    Expert 1115 points

    Dear,

     I got the script running on five different boards with typical two types of output :

     SYSBOOT on all ok.

    CONTROL: control_status = 0x00c00317

    * SYSBOOT[15:14] = 11b (26 MHz)

    * SYSBOOT[11:10] = 00b No GPMC CS0 addr/data muxing

    * Device Type = General Purpose (GP)

    * SYSBOOT[7:6] = 00b MII (EMAC boot modes only)

    * SYSBOOT[5] = 0 CLKOUT1 disabled

    * Boot Sequence : MMC0 -> SPI0 -> UART0 -> USB0

    ROM: Current tracing vector, word 1 = 0x0000009f

    * Bit 0 : [General] Passed the public reset vector

    * Bit 1 : [General] Entered main function

    * Bit 2 : [General] Running after the cold reset

    * Bit 3 : [Boot] Main booting routine entered

    * Bit 4 : [Memory Boot] Memory booting started

    * Bit 7 : [Boot] GP header found

    ROM: Current tracing vector, word 1 = 0x00011000

    * Bit 12 : [Memory Boot] Memory booting trial 0

    * Bit 16 : [Memory Boot] Execute GP image

    ROM: Current tracing vector, word 1 = 0x00001000

    * Bit 12 : Memory booting device SPI

    ROM: Current copy of PRM_RSTST = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000001

    * Bit 0 : [Memory Boot] Memory booting device NULL

    Cortex A8 Program Counter = 0x8fe1aecc

    And the otherone is :

    ROM: Current tracing vector, word 1 = 0x0000009e

    * Bit 1 : [General] Entered main function

    * Bit 2 : [General] Running after the cold reset

    * Bit 3 : [Boot] Main booting routine entered

    * Bit 4 : [Memory Boot] Memory booting started

    * Bit 7 : [Boot] GP header found

    ROM: Current tracing vector, word 1 = 0x00011000

    * Bit 12 : [Memory Boot] Memory booting trial 0

    * Bit 16 : [Memory Boot] Execute GP image

    ROM: Current tracing vector, word 1 = 0x00001000

    * Bit 12 : Memory booting device SPI

    ROM: Current copy of PRM_RSTST = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000000

    ROM: Cold reset tracing vector, word 1 = 0x00000001

    * Bit 0 : [Memory Boot] Memory booting device NULL

    Cortex A8 Program Counter = 0x402f87d0

    Do the different PC mean something, could it be a bad DDR3, all voltages are ok on the PMIC.

    Where do I go next in y search please ?

  • 0 in reply to Steve Deschryver
    Guru 92251 points

    Steve Deschryver said:
    Do the different PC mean something,

    Cortex A8 Program Counter = 0x402f87d0 means a program running in the on-chip SRAM. Cortex A8 Program Counter = 0x8fe1aecc means a program running in DDR3. This is different to the previous Program Counter values which were in the boot ROM.

    From just those addresses not sure what they mean. Do you have the symbol table / memory map from your software to be able to resolve those addresses to locations in the source code?

    Steve Deschryver said:
    could it be a bad DDR3

    Do you have any test programs for the DDR3? e.g. is it is possible to run a program in the on-chip SRAM to test the external DDR3 memory?