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.

reboot issue with AM335x when GPIO3_7 is set in output low

We have found a strange behaviour with the phyCORE-AM335x. It is easy to reproduce this default with our kit and our current linux BSP PD13-1-2.

1 - Remove JP18 and JP19 -> GPIO3_7 and GPIO3_8 are then open
2 - Force GPIO3_7 to output 0
cd /sys/class/gpio
echo 103 > export
cd gpio103
echo out > direction
echo 0 > value
3 - enter a linux reboot comand
reboot
4 - It starts to reboot but it freezes early. the reset button has then no effect. It is necessary to switch off and on the power supply.

Now, if you force GPIO3_7 and GPIO3_8 to 0, the reboot is ok. The reboot is also ok when GPIO3_7 and GPIO3_8 are forced in input.

This problem looks like the following errata but I am not sure. What is your point of view?

http://www.ti.com/lit/er/sprz360f/sprz360f.pdf

  • Hi Patrick,

    I suppose you mean Errata Advisory 1.0.36, right? GPIO3_7 and GPIO3_8 happen to be exactly the EMU0 and EMU1 pins. These pins must be externally pulled up at reset release time for the processor to start normal operation.

  • Hi,

    Yes, I mean Advisory 1.0.36. We use EMU0 and EMU1 pins as GPIO: respectively GPIO3_7 and GPIO3_8. 

    The behaviour is the same with pull-up resistors. the problem here comes from GPIO state before booting. If state is output low, reboot freezes.

    EMU0 (GPIO3_7) is used to drive lcd backlight in our application. There is a pull-up resistor. This gpio is drived low to switch on the backlight. If we want to get a correct reboot behaviour, it is necessary to switch off the backlight before rebooting.  

    It seems that it isn't possible to reboot the AM335x while EMU0 is drived in output low. Do you confirm?

    If yes, it means that it isn't recommended to use these 2 pins as GPIO. Do you confirm?

    Thanks for your help,

    Pierrick LADISLAS 

        

  • The  Advisory 1.0.36 recommended workaround says:

    "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."