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

AM5716: Boundary scan pin drive issues

Joshua Nejedly
Prodigy 100 points
Part Number: AM5716
Other Parts Discussed in Thread: AM5718

Hello,

I have been trying to set up a boundary scan test on one of our new board configurations that is using the AM5716 processor. We are using this processor as a drop-in replacement for AM572x which we have been using in boundary scan mode with no major issues. However, when I tried to set up the test using the AM5716 I ran into several issues I was not able to resolve, related to the following pins:

ddr1_csn0(#AH23)
ddr1_wen(#AH21)
ddr1_dqs_ecc(#V27)
gpmc_a7(#P5)
gpmc_a13(#R3)
gpmc_a18(#R2)
gpmc_a23(#J7)
gpmc_wen(#M3)
mmc3_clk(#AD4)
uart1_ctsn(#E25)

These pins are able to read signal levels driven by our external test PLDs without issue, but the external PLDs continue to read low signal level when driving high from the AM5716. These pins are not called out anywhere in the AM572x/1x compatibility guide, and as far as I can tell there was no change in boundary scan or signal level for these pins that would explain the issues we are seeing. The behavior is consistent between several of our debug boards. As I mentioned above, we are testing these signals on AM572x without issue.

Let me know if you have any ideas why this might be happening, how to solve it, or if you need any more information.

Regards,
Joshua Nejedly

  • 0
    TI__Genius 13567 points

    Hi Joshua,

    From what you describe I can't think of a possible cause but let's see what we can troubleshoot. I'd like to find out if the AM5716 is at least attempting to drive these pins and perhaps some short circuit is causing the PLD to read "low". That can be done two ways. Eitehr by measuring the power consumption of the VDDSHV10 rail where most of these gpmc pins reside. Power should change whether the AM5718 is trying to drive high or low. Or by driving these pins from the PLD and reading their state from the AM5718. Please let me know if the PLD is able to drive proper signals to the AM5718. 

    It turns out there is an errata / silicon advisory that covers this. Please see i928 in the SPRZ436 doc. You will need to drive resetn low in order for those pins to work. They are not controllable while resetn is high. All other pins are controllable in either situation.

    Regards,
    Ahmad

  • 0 in reply to Ahmad_Rashed
    Prodigy 100 points

    Hi Ahmad,

    Thank you for pointing me to this, I missed that errata note. Unfortunately this was not something that was taken into account with our design, and it does not seem possible to drive resetn low without making hardware changes. I think for now we will have to disable boundary scan for these signals and use functional testing to cover as much as we can. It's good to know why we were having this issue, hopefully this is something that will be fixed in future silicon revisions.

    Thank you!

    Joshua