• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 860 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.

AM5718: AM5718 custom board RESET issue

Rakesh Muralidharan
Expert 2810 points

Part Number: AM5718

Hi,

In my custom board I have adopted reset scheme from AM572x GP EVM board. Attached is the schematics for the board.Scematics_reset.pdf

I guess this scheme follows i862 implementation 2

On operating SW6 ,I can apply manual reset  to  AM5718 similarly there is provision for JTAG to apply reset to AM5718.

Voltage railvddshv3 is 1.8V and all rails are operating on 1.8V rail. (Difference from AM572x)

In normal case reset functions properly. The issue is occasionally when i apply reset via SW6 or JTAG reset device enter to state where RESETOUTn remains LOW even after PORTZ asserts high. Device recovers from this only after power cycling PMIC.

RESETOUTn is routed to nRESWARM of PMIC and reset pin of flash (S25FL256S)

I have referred to schematics check list & reference schematics for AM572x but could not identify the issue.

  • 0
    TI__Guru 57187 points

    Rakesh,

    How often does the failure occur?  Can you share a waveform of a passing and failing scenario?  Please provide porz, resetn and rstoutn signals.

    Thanks,

    Kyle

  • 0 in reply to kcastille
    Expert 2810 points

    I am now able to consistently replicate the issue.... Though the cause I am not able to identify... The processor AM5718 is connected to an FPGA.... As long as FPGA is not programmed reset works properly... If I load bit file to FPGA and then apply reset issue appears... In this non working condition if I clear FPGA via program_b, reset starts working without power cycling....

    My first inkling was to doubt FPGA code interaction with reset but could not find any.... Later my conclusion is it doesn't matter what the code may be, I tried a min version of FPGA  with unused external pins so that no way FPGA could interact with am5718 via logic....... Even here after loading the FPGA code issue occurs... Once I apply low signal to PROGRAM_B pin of FPGA.... AM5718 resetout_n returns to normal behaviour.....

    Now my guess is does GPMC have any role to play  on reset behaviour as I share gpmc address/data bus with FPGA...

  • 0 in reply to Rakesh Muralidharan
    Expert 2810 points

    Working condition. Applying Reset via SW6 in schematics (B_CPU_POR_RESETn)

    1. Blue for RESETn

    2. Green for RESETOUTn

    3. Yellow for PORZ

    RESETOUTn going High -Z can be observed.

  • 0 in reply to Rakesh Muralidharan
    Expert 2810 points

    Non Working condition (After loading FPGA). Applying Reset via SW6 in schematics (B_CPU_POR_RESETn)

    1. Blue for RESETn

    2. Green for RESETOUTn

    3. Yellow for PORZ

  • 0 in reply to Rakesh Muralidharan
    TI__Guru 57187 points

    Rakesh,

    The gpmc_ad[n] bus is muxed with sysboot pins.  These pins need to be pulled up/down to a valid state during reset and control the boot mode of the device.  These should be checked.

    Also you should check the primary oscillator input clock.

    Thanks,

    Kyle

  • 0 in reply to kcastille
    Expert 2810 points

    Hi , 

    I tried measuring B_AM57XX_OSC0_OUT (xo_osc0) 20MHz when during normal working condition and when issue occurs.

    I could not find any issue here the pin oscillates at 20MHz normally on both the occasion. 

    VDDA_OSC is at 1.8V on both the occasions.

    In TRM i could find the following

    ""

    All PRM reset outputs are asynchronously asserted, while the deassertion is synchronous to the
    SYS_CLK1 clock. The reset managers in PRM use this clock to stall, or delay, deassertion of reset upon
    source deactivation.

    ""

    So is guess RESETOUTn will be asserted on PORZ but to release it needs SYS_CLK1.

    Can GPMC affect SYS_CLK1 functioning?? I guess sysboot pins are latched on release of reset.

    Is there any other dependency for SYS_CLK1

    My problem still persists

  • 0 in reply to Rakesh Muralidharan
    Expert 2810 points

    Now the problem is resolved!!

    As you suggested it was GPMC creating issue. After programming FPGA , it was corrupting the sysboot(8) sysboot pin defining clock source. The voltage level there dropped to 0.49V from 1.8V after programming FPGA. Resistor configurations were overridden by FPGA.

    After providing default pullup/pulldown in  FPGA code  as per sysboot resistor configuration this issue got resolved.