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.

WEBENCH® Tools/AM6546: Boundary scan for DDR4

Part Number: AM6546

Tool/software: WEBENCH® Design Tools

We are trying to implement boundary scan testing using an AM6546.  We have encountered a couple of issues, the main one is testing the connections to the DDR4 – using standard DDR4 test files that work with other processor/DDR4 combinations we are getting no response from the DDR4 connected to the AM6546.  Whilst investigating this we observed that the device’s behaviour does not seem to match that defined in the BSDL file.  For example the BSDL file defines that port DDR_DQS0N uses cell 565 (control) and cell 566 (bidir), whilst port DDR_DQS0P uses cell 567 (control) and cell 568 (bidir).  However, we have observed that both DDR_DQS0N and DDR_DQS0P seem to use cell 567 as their control cell.   This can be easily observed by setting cell 565 high (disable): when cell 567 is high (disable) then toggling cells 566 and 568 has no effect, but when cell 567 is low (enable) then toggling cells 566 and 568 does have an effect.  We have also observed this same behaviour on other pairs of ports, such as DDR_CK0N and DDR_CK0P.

 

Please can you investigate why we are observing this behaviour instead of that defined in the BSDL file?  If you do find that the BSDL file is incorrect, please can you also verify that there are no other errors in the remainder of the BSDL file.

 

We were also aiming to test the connections to the eMMC using boundary scan, but have observed that all of the MMC signals are marked as ‘linkage’ signals within the BSDL file.  Interestingly we also noticed that there’s a section of ‘internal’ cells from cell 319 to cell 370 in the boundary scan register.  Is this where these signals should be controlled from via boundary scan, but TI found a problem and therefore removed them from the BSDL file?  If this is the case, are you able to share any information on what this issue was and why they were removed?  In the past, with previous similar TI devices, we have found it necessary to configure the pads via the ARM core before boundary scan will work successfully on the MMC signals.  Therefore, if something similar is required for this device then it would be useful to know this to enable us to achieve the best test coverage possible.

 

I hope this makes some sense, but if you need anything clarified then please ask.