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.

AM625: Boundary scan issues

Part Number: AM625

Hello,

I have been trying to set up a boundary scan test on one of our new board configurations that is using the AM6254 processor. I am having problems with the following processor pins:
mcu_spi0_clk(#A7)
mcu_spi0_d0(#D9)
vout0_data1(#V24)
vout0_data3(#W24)
vout0_data4(#Y25)
vout0_data6(#Y23)
vout0_data7(#AA25)
vout0_data8(#V21)

I'm still investigating, but from what I've established all of the vout0 pins and the mcu_spi0_clk pin seem to be unable to drive or read correctly. The mcu_spi0_d0 pin is acting like it is connected to the mcu_spi0_d1 pin.

There is nothing else connected to these pins except the external PLD device(s) that can drive or read to verify the connection. Compliance pattern is good and the processor is reset before boundary scan is run as described in the design warning. Over a hundred other signals are working without issue. I checked the errata and nothing is listed regarding these signals.

Are you aware of any issues with JTAG boundary scan on these signals? Are you able to test this behavior yourself?

Thanks,
Josh

  • Josh

    I'll check on this and get back to you, probably Monday.

    --Paul 

  • Thank you!

    Just to add a little more information, I investigated the behavior of mcu_spi0_d0 and mcu_spi0_d1 further. It's odd, definitely seems like the drive state is tied together but d0 is only able to drive to ~2.65V (expected 3.3V). Driving either alone produces the same high/low output on the other. When they are driven together at different levels you get a strange "half step" behavior on both. When both are externally driven only and used as inputs, d1 functions correctly while d0 reads the same values as the external state of d1.

    As far as I can tell there is nothing external to the processor that would explain this behavior.

    The rest of the signals in my list the behavior is not as complicated. When used as inputs they read high regardless of actual state, and as outputs they are stuck low.

  • Josh

    Thank you for the additional information. 

    I have not found any advisories relating to boundary scan.

    I have passed the information to out boundary scan model expert for his input. However, he is out of the office. Therefore I don't expect a reply until Wednesday. 

    I will follow-up with you then.

    --Paul 

  • Josh

    Just touching base.  Still working on addition feedback

    --Paul 

  • I've looked into this further and it seems there may have been some processor soldering or connector contact issues on my development board. Testing another board does not show the same failures. I will continue to look into this and see what the behavior is across more units, but it appears there may not be an issue with boundary scan after all.

  • Joshua

    thanks for letting us know that the problem appears to be an assembly issue.

    I’ll go ahead and close this thread.  

    if you have additional questions please go ahead and open a new thread  

    —Paul