Hi,
We are currently testing the Boundary Scan over JTAG on our Vybrid modules. We are currently using a VF60.
There are some issues.
We try to set output pins through JTAG boundary scan on Vybrid. We are using a Lauterbach JTAG adapter and our own JTAG solution. We are using the BSDL file attached here:
Debugging BSCAN test for Vybrid. Chip doesn't seem to respond correctly with this BSDL file
and in general it looks like it works. We are able to read the ID Code, we are even able to read from the pins (input). But we fail to set outputs. We set the corresponding output enable cell but the output doesn't change. We are able to change the value of this ball externally and can successfully read it back. Is there anything we have to set-up prior to being able to set output pins through JTAG?
One remark, as soon as we enter EXTEST mode, the RESETB / RESET_OUT signal gets asserted (0V). But this is normal I guess.
Do you have an idea what could be missing? Is there any JTAG boundary scan documentation or application note other than in the reference manual?
Unfortunately I couldn't test it on the Vybrid tower as I don't have a the right JTAG cables and adapters here.
Thanks for your help.
Roman
Toradex AG
已解决! 转到解答。
Hi Roman,
The feedback that I received is that we were able to replicate the issue.
I do not yet have a report that explains the issue in detail as the team is still investigating. I can share with you what we believe may be causing the problem. Maybe it helps you with your efforts.
The current thinking is that the drive strength setting(DSE) in the I/O is set to '000' (high-impedance) during the EXTEST instruction and therefore the pin will not respond when driving it high or low. One option to work around the issue would be to run execute an EXTEST followed by a CLAMP instruction. The EXTEST will load the scanchain and the CLAMP instruction will then enable the output buffer without forcing DSE to '000'.
I assume the same can be done with PRELOAD and CLAMP, but I'm not really a JTAG engineer so maybe I'm wrong here.
I will update this thread when we have conformation and/or a workaround from the design team.
Best regards,
Richard
Final update for this issue.
Please see the attachment for a method to work around the BSDL issue.
Method 1 allows for testing connections, but it is not suitable for programming external devices over JTAG.
Method 1 preserves the outputs between scan operations an can therefore be used for programming external devices.
Best regards,
Richard
Good catch! Thank you for reporting this.
I compared this to the original and found that the line was truncated. the missing part is 00"
The last lines of the header should be :
JTAG-IR: "11001“, traverse through “pause-dr” state for this step.
JTAG-DR: "100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000“
Regards,
Richard.
Hi Richard,
Thanks !
Unfortunately I am still NOT able to get the output to drive correctly after following the step in the document.
All outputs seem to be in High-Z.
JTAG-IR: "11001“, traverse through “pause-dr” state for this step.
Can you explain how the above "pause-dr" being executed.
Has anyone successfully get it working ?
Yes, several people have used this and some reported back that it was working.
I'm not really familiar with JTAG instructions. I believe that the pause-dr state means that the shifting of the data register is temporarily halted. I assume this is to preserve the state of the (outputs enabled). The chain on which this state is applied is not the chain with the output cells. It is an internal chain that controls the output buffer' enable.
After this header, you have to run your patter. Notice that the reset pin must be active throughout the test. Otherwise the PADs will return to HiZ state.
Hope this helps.
Regards,
Richard
Dear Roman,
Sorry for delay!
It looks like the JTAG channel is working properly, but the default state of the pin of interest is "Input", and you have to reconfigure it into "Output" based on the list of registers in the Reference Manual - have you tried that yet?
(You may also take a look at the http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf document (similar one for Vybrid is not ready yet).)
Sincerely yours, Naoum Gitnik.
Dear Naoum Gitnik,
We did some further investigations. This time we used the tower system and a Lauterbach JTAG solution. We used the bsdl file as mentioned above and tried to drive the pin PTB11 (on test pin TP14 on the tower board). We were able to read from this pin, but not to drive it. Of course we set the correct boundary control cell to output first, but this didn't help. We just used the CPU board of the tower system powered through USB. We really can't find anything we didn't do or did wrong. Can you check this on your end on the tower with PTB11 as well and let me know exactly what you were doing?
Thanks a lot.
Roman
Dear Roman,
I am not a software person and cannot say the information you provided suffices, but when he jumps in, quite likely he will ask you to provide either a piece of code or simply all(!) the register settings you are using in your test.
Sincerely yours, Naoum Gitnik.
Dear Naoum,
I have some additional information about our test on the tower board TWR-VF65GS10 powered through USB port J3. We didn't do too much, just loaded the bsdl file for the VF60 into the Lauterbach JTAG environment. We made a soft reset (toggle JTAG CLK a couple of times with TMS =1 n order to get to the test logic reset state). Then we read the ID register which reported the correct ID (0x1980101d). After this we go to EXTEST Mode (the RESETB signal goes automatically to low). We can read e.g. PTB10 or PTB11 correctly by applying 3.3V or GND to these signals (TP12 and TP14 on the tower board). Then we try to drive these signals. Therefore we set the control cell of these two signals to output and the data cell to either 0 or 1. But in both cases it isn't possible to drive the pins.
Is there any other setting we need to do in order to being able to drive levels in boundary scan mode? Is this somehow a security feature which needs to be changed first?
Thanks a lot for your help.
Roman
I'm no BSDL expert, but believe the problem here is the reset set up. Vybrid has no dedicated JTAG-RST, which you might normally expect, the TWR board connects the JTAG-RST to the system reset (RESETB), so if the EXTEST tries to issue a JTAG-RST this will, as you are seeing, force RESETB low. Referring to table 17-1 in the RM you'll see the reset functions defined, a RESETB will clear all SJC/TAP settings, and force all pads to Hi-Z.
I think you have to modify the EXTEST and use only a software-JTAG reset. As mentioned I'm not the expert in BSDL, but we went through this with another customer and once we highlighted this we heard nothing further from them.
Ross
Dear Ross,
Thanks for your suggestion. Our JTAG setup doesn't modify the reset pin. We actually didn't connect it even. As soon as we enter EXTEST mode, the reset goes low automatically. But in this mode, we are able to read back external pin-levels sucessfully. Just driving doesn't work. It would be great, if somebody could test it on their tower with a JTAG debugger to see if it is possible to output levels over boundary scan. If yes, what was done exactly. Thanks.
Dear Roman,
Below is reply from our boundary scan expert:
Sincerely, Naoum Gitnik.
Hi,
Thanks for your comments so far. We tested PTB10 and PTB11 on the tower as these two pins have a test point (TP12 and TP14). We now also tested it under u-boot. We were able to configure these two pins to gpio output and successfully set them to 0V and 3.3V. So the HW is OK in general. We tested another pin on our own HW with the same behavior. So it's definitely something which is wrong with the boundary scan in general.
Regarding the direction control bit in EXTEST, yes, we tried both, 0 and 1. Both didn't work. The pin was always floating. We also tried to set more output cells in the same 'region'. This didn't help either.
Can you please test this using the BSDL file, the tower HW, and a JTAG adapter and let me know if you were able to control PTB10 and PTB11 as output 0 and 1? Did you ever test the boundary-scan EXTEST output on the Vybrid tower, or Vybrid in general? If yes, how was the set-up (HW and SW)?
It really starts worrying us as we need this mode for testing our modules. We are ramping up our volumes and need a good test for all of them.
Thanks.
Hello Roman,
One should be quite cautious if there are no other outputs connected to the lines of interest forcing them into a logic state different than that to be defined by Vybrid, e.g. just based on the Rev.G schematic:
· PTB11 is connected to PTB18 via two 0-Ohm resistors, R76 and R77,
· PTB18 is connected to the U19 (octal buffer, see https://www.fairchildsemi.com/ds/74/74LCX541.pdf) output O6,
· During your test "the RESETB signal goes automatically to Low”, and it controls the U19 transparency (active Low OE), therefore, the logic High from its D8 input is translated into logic High on its O6 output, i.e. the PTB18 line of the board.
BTW, are you using the board stand-alone, since both the PTB10 and PTB11 are connected to the edge Elevator connector (J17A)?
Regards, Naoum Gitnik.
Dear Naoum Gitnik,
Thanks for your feedback. We already tested this issue with R76 removed and the behavior was the same. The two pins PTB10 and PTB11 are both floating. When reading them back through boundary-scan, they show as 1, when I measure the voltage on these pins with a normal voltage meter, I measure almost 0V and the value read back through boundary scan also goes back to 0. It really looks like the output driver of these pins are always off. So please try to set-up a TWR HW using the BSDL/Boundary-scan and verify it on your end. I really don't know what else to do. We even started with setting all cells to 1 and 0. But this didn't have any effect at all, the pins were still floating!
We need to get a solution soon as we are blocked for higher volumes without having this testing method. Thanks for your support.
Regards,
Roman
Dear Roman,
Our team is currently checking this issue with the Vybrid IC design team, and, unfortunately, it will take some time.
Regards, Naoum Gitnik.
Dear Naoum Gitnik,
Is there any update on this issue? Has the design team made any progress? Are there any open questions I should answer to speed things up?
Thanks for an update and have a nice weekend.
Roman