• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 543 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM5728: Reset issue

Sylvain PALMERI
Expert 1145 points
Part Number: AM5728

Hello,

I just received my board prototype including an AM5728. I think that I have an issue with the reset output of the CPU following power up.

The AM5728 rstoutn is connected to the PMIC (on NRESWARM) and the PMIC RESET OUT is connected to the PORz of the CPU. When I power up the board, The PMIC reset out (in blue)  rise up after few ms, the rstout of the CPU stay low during ~2ms and rise up. That seems to works fine, but few ms after the CPU send a warm reset (on the rstout pin) to the PMIC which reset after ~3ms. That reset the CPU and so on... This sequence starts again and again indefinitivly

Could you help me to figure out why the CPU send this warm reset (watchdog, boot failed...)?

CH1 (yellow) : AM5728 RSTOUTn (F23)

CH2 (blue): PMIC RESET_OUT (G6)

Thank you

Sylvain

  • 0
    TI__Mastermind 46460 points

    Sylvain,

    I recommend that you first break the loop so that you system is in a static state that you can debug.  Then you can examine the sequence of events from power-up to understand what is happening.  The RSTOUTn from the AM5728 probabvly goes through a voltage divider to reach the nRESWARM input of the PMIC.  You can simply remove both resisters in the divider to stop the feedback path.  The nRESWARM input has an internal pull-up resistor and it can be left unconnected when not used.

    A few additional questions:

    1. How many prototypes did you build?
    2. Are they all behaving this way?
    3. What BOOTMODE are you using?
    4. Does it even start accessing the BOOT media?
    5. Do you see the oscillator running?
    6. Have you verified that the PMIC is properly configured and providing the expected power-up sequence?

    Tom

  • 0 in reply to Tom Johnson 16214
    Expert 1145 points

    Hi Tom
    Thank you for your feedback.

    The boot1 pin of th PMIC was pulled to the 3V3. I changed the config by pulling it down to 0, and the result is different: now the PMIC does not longer respond to the rstoutn assigment, and does not reset the CPU anymore.
    I finally reach to connect the emulator (via FTDI USB).
    However the CPU still continue to reset periodically. I guess it's due to the blank memory and no boot device connected... I think but I'm not sure.

    To answer your questions:
    - We received 4 prototypes. I only tested one.
    - The boot sequence is setup for 1. USB2 2. uSD 3. Flash EMMc
    - The 20MHz is running properly, the 32KHz not, but I guess it must be enabled by software...
    - The PMIC power-up sequence seems to be correct.

    Regards,

    Sylvain

  • 0 in reply to Sylvain PALMERI
    TI__Mastermind 46460 points

    Sylvain,

    Can you change the SYSBOOT pins to select UART boot?  (Se section 33.2.4.4 Booting Device Order Selection of the TRM.)  That should allow you to easily connect the emulator and take control of the device.

    Tom

  • 0 in reply to Tom Johnson 16214
    Expert 1145 points

    Tom,

    Do you mean sysboot[5:0] 0b01 0011 ? If so I can do that, but what is the next step?

    Sylvain.

  • 0 in reply to Sylvain PALMERI
    TI__Mastermind 46460 points

    Sylvain,

    The UART boot timeout is very long.  This will allow you to easily connect the emulator and to halt the processor.  I assume that you will then use the emulator to validate your board and to provision your DDR memory interface.  Once all of this is verified robust, then you can start integrating your application code.  Please refer to the ProcSDK documentation for additional guidance.

    Tom

  • 0 in reply to Tom Johnson 16214
    Expert 1145 points

    Tom,

    I already reached to connect the emulator via FTDI. Once connected the reset signal stop and stay high, I can also start the clock of the DSP with the script of the gel files. When the DSP is running, the periodic reset signal that I have on the rstoutn pin stops and the signal stay high. 

    Do you thing that it is a good progress or the periodic signal on the rstoutn pin hides something wrong?

    According to your suggestion, if I can emulate via the FTDI, do you think it will help to boot on UART? 

    Sylvain.

  • 0 in reply to Sylvain PALMERI
    TI__Mastermind 46460 points

    Sylvain,

    If you can get the emulator connected and the cores halted without changing the SYSBOOT pins, then you do not need to change it.  The change to UART boot would have been to simply making this emulator connect sequence easier.

    The warm reset loop is caused by the BOOTROM once it determines that the boot media is not available.  There is a statement in the TRM under the SYSBOOT table which makes this clear.

    You can proceed with board provisioning and validation using the emulator.  Once all hardware is checked out, then you can proceed to booting over the desired media.

    Tom

  • 0 in reply to Tom Johnson 16214
    Expert 1145 points

    Thank you for your help Tom