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

AM5749: Boundary scan issues

Joshua Nejedly
Prodigy 100 points

Part Number: AM5749
Other Parts Discussed in Thread: AM5716,

Hello,

I have been trying to set up a boundary scan test on one of our new board configurations that is using the AM5749 processor. I am running into the same signal failures as I see on this AM5716 issue:
https://e2e.ti.com/support/processors/f/791/t/714939

Which correspond to AM5716 errata i928. However, there is no equivalent errata for AM5749.

There is also an additional issue with ddr2_dqs0-3 and ddr2_dqsn0-3. In boundary scan test these are behaving as if they are shorted together even though they are physically separate and not connected to any devices.

I think these issues may be missing errata items, could you please check if you can confirm the behavior?

Thanks,
Josh

  • 0
    Prodigy 100 points

    In addition to the AM5716 signals, there are an additional two which seem also not be controllable in the same or similar way: ddr2_cs0n and ddr2_wen.

  • 0 in reply to Joshua Nejedly
    TI__Genius 13567 points

    Can you try this with EMU0 pulled to GND and with EMU1 pulled high to VDDSHV3? This puts the SoC into a Wait-in-Reset mode where you may have better luck accessing those pins. So far we have not heard of any AM574x family devices with the problems you describe. 

  • 0 in reply to Ahmad_Rashed
    Prodigy 100 points

    I actually am already running this test in Wait-in-Reset mode by externally driving EMU0 low and EMU1 high to prevent the processor from doing anything else while boundary scan is running. This fixed some issues we had before on other processor configurations but not the errata issues for AM571x or apparently AM574x. The signals that were failing due to the AM571x errata are failing in exactly the same way on the AM574x, I can't imagine that is a coincidence.

  • 0 in reply to Joshua Nejedly
    TI__Genius 13567 points

    Hi Joshua,

    It appears AM571x errata i928 should be also applicable to the AM574x family. This exclusion from AM574x errata appears to be a mistake so I will have it corrected.

    Other than signals mentioned in the errata, are you still seeing any others failing to respond?

  • 0 in reply to Ahmad_Rashed
    Prodigy 100 points

    Two that are failing in the same way (not controllable):

    ddr2_csn0(#P24)
    ddr2_wen(#U25)

    And my boundary scan software is indicating that these two groups of signals are shorted together, perhaps they are all being controlled via the same register somehow?:

    ddr2_dqs0(#G28)
    ddr2_dqs1(#H27)
    ddr2_dqs2(#K27)
    ddr2_dqs3(#M28)

    ddr2_dqsn0(#G27)
    ddr2_dqsn1(#H28)
    ddr2_dqsn2(#K28)
    ddr2_dqsn3(#M27)

    It's somewhat unusual to be testing differential signals like this so it's very possible there is something configured incorrectly on my side.

  • 0 in reply to Joshua Nejedly
    TI__Genius 13567 points

    We've been able to confirm on an internal AM574x EVM the behavior of i928. The signals in the group ddr2_dqs[3:0] and ddr2_dqsn[3:0] actually showed no toggles in our test. It's still being looked into on our side if there are additional signals not mentioned in i928 that are affected so there's not a final answer yet. Are you able to proceed with the resetn work around? 

  • 0 in reply to Ahmad_Rashed
    Prodigy 100 points

    Unfortunately as with the previous issue on AM571x, due to our hardware design I do not have control of the RESETn signal (it is pulled up). So I will need to exclude these signals from the test. However, the impact on test coverage is minimal as most of the signals are covered by other functional testing.

    Were you able to confirm the same control issue on ddr2_csn0 and ddr2_wen?

  • 0 in reply to Joshua Nejedly
    TI__Genius 13567 points

    Hi Joshua,

    Sorry for the delay. Our team for DFT is starting to look at this now. They plan to simulate the device to verify additional pins affected. They last simulated this on AM571x devices, however those did not have a ddr2 interface, only the ddr1. So we need to simulate again on AM574x to check these ddr2 pins.

    From the previous AM571x simulations they do have ddr1_csn0 and ddr1_wen confirmed not behaving as expected. So I would expect the same pins on the ddr2 side to see the same behavior. They also have ddr1_dqs[3:0] and ddr1_dqsn[3:0] confirmed as not scanning out, so again the chance of ddr2 seeing the same issue is likely. 

    Regards,
    Ahmad