• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 428 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:

reboot issue with AM335x when GPIO3_7 is set in output low

AM3352: how to workaround to use EMU0/1 as GPIO

Tony Tang
Mastermind 30202 points

Part Number: AM3352
Other Parts Discussed in Thread: TPS65217

Customer board use EMU0/1 as GPIO, some board hang during operating GPIO3-7(EMU0): set PINMUX as GPIO, direction OUTPUT, no matter 0 or 1. with the same software procedure, most board works, only a few boards has this problem. now accumulated 10+ pcs board.

Pulled up EMU0/1 already, captured signal during power up. the PMIC is TPS65217

In errata advisory 1.0.36.

If the secondary GPIO function of the EMU[1:0] terminals is not required, only connect
these terminals to pull-up resistors.
If the EMU[1:0] terminals are configured to operate as GPIO, the product should be
designed such these terminals can be pulled to a valid high-logic level within 190 ns
after the falling edge of WARMRSTn.

How to ensure EMU0/1 pulled up within 190ns after falling edge of WARMRSTn? for a power on operation, WARMRSTn is output in default, before IO voltage ramp up, WARMRSTn is default to LOW. there is not a falling edge during power up.

  • 0
    TI__Guru* 92691 points

    Does your board hang at the time you switch the pinmux to a GPIO, sometime after while using it as a GPIO, or after a warm or cold reset?   Can you give more explanation on the exact point of failure.    I'm trying to get more info on the errata.  

    Regards,

    james

  • 0 in reply to JJD
    TI__Mastermind 30202 points

    James,

    Hang on accessing GPIO module register GPIO_CLEARDATAOUT, not all boards have the issue although with same software, just a few boards have issue.

    If add a 500ms delay before GPIO_CLEARDATAOUT accessing, software can run pass GPIO access, and everything works fine.

  • 0 in reply to Tony Tang
    TI__Guru* 92691 points

    Tony, thanks for the details.  The only way i can see this happening is if the GPIO is enabled, and then a reset occurs, whereby the EMU1 gets re-latched incorrectly because the voltage level hasn't settled by the time the re-latching occurs.  Can you ensure that POR and WARMRESET signals are stable immediately or around the point of accessing the GPIO_CLEARDATAOUT register.  Also, what is the GPIO connected to?

    REgards,

    James  

  • 0 in reply to JJD
    TI__Mastermind 30202 points
    JJD said:
    Can you ensure that POR and WARMRESET signals are stable immediately or around the point of accessing the GPIO_CLEARDATAOUT register

    Yes, there is not hardware or software reset operation after power up reset.

    JJD said:
    Also, what is the GPIO connected to

    In order to identify the issue, disconnected external component  already. just pull EMU0/1 to high. please check the picture in first post.

  • 0 in reply to Tony Tang
    TI__Guru* 92691 points

    How soon after the rising edge of POR is the access to the GPIO_CLEARDATAOUT register (without adding the 500ms delay)?  Does the issue occur if you perform a warm reset instead of a POR?  What software base are you using?

    Since you can get it to work by adding the long delay, the issue may be that a PLL is taking a long time to stabilize, or other voltages are not valid and stable immediately after POR.  

    Regards,

    James

  • 0 in reply to JJD
    TI__Mastermind 30202 points

    James,

    #1. The PMIC is TPS65217. so the power sequence should be good.

    #2. Access GPIO3-8(EMU1) instead of GPIO3-7(EMU0), no such issue. access other GPIO bank also is OK. 

    #3. It is Linux system, this is in UBOOT,  did not touch PLL configuration code.

    #4. Another experiment: Boot from SD card without accessing GPIO3-7 code, then remove SD card and execute reboot from Linux (warm reset) to boot from on board NAND flash with GPIO3-7 accessing code, software can run pass the code and everything is OK. no matter how many times reboot(warm reset) from Linux.

    #5. delay 500ms is just a experiment, it is hard to determine the exactly delay can make it work. 

    JJD said:
    How soon after the rising edge of POR is the access to the GPIO_CLEARDATAOUT registe

    If you think it is useful, I will try to let customer measure it. but I think it is not worth to do it as accessing GPIO3-8 is OK.

  • 0 in reply to Tony Tang
    TI__Guru* 92691 points

    I'm was just trying to understand if the access to configure GPIO3-7 is the very first access to the GPIO module.  If you are saying that they can exchange GPIO3-8 at the exact same point in the code, then i agree the measurement is not very useful.

    There is something unique about that access which is causing the problem.  You said there is a hang when accessing that register, which clears or sets a GPIO.  You also said even if you disconnect that GPIO from the rest of the board, there is still a hang.  There is most likely some code which sets up the GPIO3 module prior to accessing CLEARDATAOUT, so other register accesses to that GPIO3 module must be successful, which rules out an issue with the module clock.  You also said all other GPIO bits in that register can be toggled successfully (for example GPIO3-8).  So it seems it has to be related to the changing of that GPIO signal.  Here are some more ideas:

    -can they probe EMU0 at the point of the hang?  Does it toggle?

    -can the break in with JTAG after the hang to see where the program counter is, and see if they can still access the GPIO module

    -is there a possible assembly issue on the few boards that don't work, possibly where EMU0 is affecting other signals

    -is the OE enabled on the GPIO at the point of the hang.  If so, can they reverse the order of instructions (enable the bit in CLEARDATAOUT, then enable the output using OE), and see if they still get a hang?

    Regards,

    James