I am using a MCIMX6D4AVT08AD working on a customer supplied board for a boundary scan tool development company (XJTAG), I cannot get certain GPIO2 (16-31) , and GPIO3(1-15) pins to behave according to their BSDL specification. As best that I can tell they appear to read but not write. Do I need to initialise any registers etc to make the device behave according to the BSDL file?
Hi, yaJFPb and BSTest users:
yaJFPb software and BSTest software have an update to add workaround for this issue. Please contact us for latest software. BSTest V2.9.3.0 and later versions, yaJFP V3.3.3.0 and later version will support i.MX6 Dual/Quad for all tests.
Hello,
JTAG Technologies customers can contact JTAG Tech support for a special script(JFT) which can be used to enable full boundary-scan access on the EIM-interface.
Any solution on this?
All the compliance and requirements are taken care., still having failure on the bsdl script.
Hello,
You may create request in order to get some preliminary information,
that may help.
Regards,
Yuri.
Is this problem solved? I am having the same with Jtag Technolgies software.( compliance patterns are acc. the bsdl)
regards, Hans
Hello,
You may create request in order to get some preliminary information,
that may help.
Regards,
Yuri.
Please look at general considerations below.
1.
Please check if SATA and PCIe volatges are applied :
according to footnote of Table 2-21 (Recommended connections for unused
analog interfaces) of the Hardware Development Guide, linked below ,
SATA and PCIe supplies must remain powered if boundary scan test needs to be done.
< http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf >
2.
JTAG_MOD (SJC_MOD) should be pulled up (to NVCC_JTAG) for Boundary Scan Mode.
3.
Please check in BSDL file is correct for the i.MX6 part.
Please use the recent BSDL file(s) from the Freescale Web
4.
Please pay attention on COMPLIANCE_PATTERNS of the BSDL file.
attribute COMPLIANCE_PATTERNS of MX6S: entity is
"(TEST_MODE, JTAG_MOD, POR_B) (011)";
Check if :
TEST_MODE is LOW ;
JTAG_MOD is HIGH ;
POR_B is HIGH.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thanks for the prompt response.
Unfortunately I still have the issue even though all of the points in your reply have been tested and are OK.
It is behaving as if the EIM interface is disabled in some way and cannot drive out, but the pins I have access to do actually read correctly.
The pins affected are
EIM_DA[0] to EIM DA[15]
EIM A16 to EIM A24
EIM LBA, EIM_RW and EIM Wait
Is there some register or configuration that needs to be enabled to allow EXTEST to behave according to the BSDL setup for these pins?
As this is connected to a Strata flash , this problem is preventing any tests on this device.
Thanks
There are no specific features about i.MX6 JTAG testing, except the mentioned earlier.
Perhaps - because of power up issue - the Strata flash pins enter latch state
so that i.MX6 pins cannot overdrive them. Is it possible to test corresponding pins
without the flash ?
~Yuri.
No this is not the case.
I can inject signals onto these nets through a resistor and see the state of the pins changing with next to no current, so these pins are tri-stated from the flash (not latched) , also the flash nCE pin is disabled.
These pins are not driving with JTAG boundary scan only reading.
Looking through previous customers history we have also had this with another project that used the iMX6, which we could not explain.
These pins appear to be disabled in some way from the iMX.
~Dave
Dave, good day !
Please check if - maybe during JTAG EXTEXT - there are no pins, that can
influence on JTAG : say, if an external i.MX6 reset can be caused by
asserting some signal (WDOG output - for example ).
~Yuri.
Yuri,
Thank you for this information.
However, after further investigation, we have realised the problem is only occurring on the 32 pins that can also be used as BOOT_CFG pins. This doesn’t include the two BOOT_MODE pins (which behave correctly).
The boards have no eFuses set, the BOOT_MODE pins are both low, and the attached flash is not programmed (ie the boards are direct from manufacturer pre-programming).
This makes it appear as though the iMX6 is keeping the output buffers disabled on the 32 BOOT_CFG pins when we are trying to use EXTEST, no matter what the pins are told to do via the boundary scan register.
Does the iMX6 boot process override the boundary scan control of the boot configuration pads? Does the device need particular clocks running, or a particular startup sequence, for it to allow these pads to be driven via boundary scan?
In section 56.5.3 of the reference manual, it states that:
“The EXTEST instruction also asserts internal reset for the cores (through CCM, refer to Figure 56-14) to force a predictable internal state while performing external boundary scan operations.”
Could the assertion of this reset be associated with forcing all of the BOOT_CFG pins to be inputs?
Any further input you could provide would be very useful!
~Dave
This is correct - " the assertion of this reset be associated with
forcing all of the BOOT_CFG pins to be inputs".
~Yuri.
If selecting EXTEST asserts this internal reset, and assertion of this reset forces all of the BOOT_CFG pins to be inputs, then why does the BSDL file include output cells for those pads?
Is there any way to prevent this internal reset from occurring, so that the BOOT_CFG pins can be used as outputs whilst in EXTEST?
~Dave
New erratum regarding JTAG Boundary Scan will be issued soon :
EIM signals fail to drive as outputs during boundary scan test
Regards,
Yuri.