Vybrid VF60 no output in JTAG boundary scan

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Vybrid VF60 no output in JTAG boundary scan

Jump to solution
6,633 Views
romanschnarwile
Contributor III

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

Labels (1)
1 Solution
4,397 Views
richard_stulens
NXP Employee
NXP Employee

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

View solution in original post

40 Replies
1,794 Views
naoumgitnik
Senior Contributor V

Dear Roman,

When an issue cannot be resolved by us, the Applications team, alone and the IC design team gets involved, it means the issue is quite serious and, unfortunately, needs relatively long time for resolution. It is our best interest, too, to resolve it once and for all, and we will notify you about the results once we have them.

Sincerely, Naoum Gitnik.

Ross McLuckie

0 Kudos
1,794 Views
romanschnarwile
Contributor III

Dear Naoum Gitnik,

We made some more tests. This time we took our iMX6 module together with the same JTAG adapter (Lauterbach) as we used for the Vybrid tests. Using this set-up was working perfectly in boundary scan. We were able to read and write to the boundary scan cells and we could measure it on the respective physical pin. We did this test to verify our Lauterbach system. So it looks like everything works well in general. But of course we haven't been able to get further with the Vybrid modules. Can you give us an update on your investigations. If not, please tell me, when we can expect some results or further information. This project is getting very time critical. We haven't been able to solve this problem for more than half a year now.

Thanks for your effort.

Regards, Roman

0 Kudos
1,794 Views
RossMcLuckie
NXP Employee
NXP Employee

Hi Roman,

Thanks for the additional information, I have forwarded this to our design team. As for progress, all I can tell you at the moment is the design team are actively working on this right now, we will update you with any progress that is made.

Ross

1,794 Views
karina_valencia
NXP Apps Support
NXP Apps Support

RossMcLuckie do you have an update on this case?

1,794 Views
naoumgitnik
Senior Contributor V

Hello Karina,

Our and the design team are still working on this issue.

Regards, Naoum Gitnik.

Ross McLuckie

Richard Stulens

1,790 Views
romanschnarwile
Contributor III

Thanks Karina for pushing this important issue.

Naoum, have you or the design team been able to recreate the issue? Can we help somehow? Can you at least give me some more information where you are with your investigations. Only knowing, that you are working on it is not enough unfortunately. We need to meet our schedules and I at least should have a little bit more information. So any update is helpful. Can you please also make sure you send us an update on a regular basis, like every week. If it is hard to handle for you, I can also poll every week for a short update.

I hope you understand our situation. I know this issues can be hard, we are also a development company and also have customers asking such questions. So I know how it is. I really don't want to stress anybody. Please just send me a short update with at least some details.

Thanks a lot.

Roman

0 Kudos
4,398 Views
richard_stulens
NXP Employee
NXP Employee

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

1,794 Views
romanschnarwile
Contributor III

Hi Richard,

We did some tests with your proposal (CLAMP). It really seems to work like this. We load the boundary scan with EXTEST (or also sample/preload, it behaves the same). All pins are high-z. Then we go to CLAMP, after this, the output is driven as specified in EXTEST before. This means we can use this approach to drive signals.

Unfortunately, this doesn't solve our whole problem. We would like to program the NAND over boundary scan. To do this we would have to toggle many pins over EXTEST. But every time we go into EXTEST, all signals are high-z and therefore lose their current state. This leads to signal edges which don't allow us to program the NAND flash.

Do you have any idea how we could solve this? Is there any other way of loading the boundary scan chain with values other than using EXTEST and PRELOAD? Are there any undocumented JTAG modes on the Vybrid like INTEST, etc?

Another solution would be to load code directly into internal RAM of the Vybrid. We could then write some code which writes to the NAND flash. Do you have any documentation for Vybrid about how to load code over JTAG to internal SRAM and execute it?

Thanks a lot,

Roman

0 Kudos
1,794 Views
richard_stulens
NXP Employee
NXP Employee

Hi Roman,

Thank you for the feedback. It confirms our findings.

As for programming NAND Flash, there are a few possibilities:

1. We now have manufacturing tool (mfgtool) for Vybridwhich allows for programming the on-board devices over USB. It requires a USB connection to a PC, but is probably the easiest way to do it.

2. If programming over JTAG is a requirement, then you'll have to use the Debug Access Port (DAP).

This is an ARM debugger port based on JTAG that allows for downloading and executing code on th processor. In essence, this is what the debuggers used to communicate with the device. Chapter "Debug Architecture"in the Reference manual describes the interface and JTAG configuration. On the ARM web site you will also find more information about DAP.

Some debuggers have the functionality built-in (IAR have a QSPI programmer of CMSIS-DAP). There may also be stand-alone software or open source software to do that.

Best regards,

Richard

0 Kudos
1,794 Views
pedrovitoriano
Contributor I

Hi Richard,

There's any new regarding the JTAG issue on Vybrid?

About the mnfg Tool where can I download it.??


Thanks

Pedro Vitoriano

0 Kudos
1,794 Views
richard_stulens
NXP Employee
NXP Employee

Hi Pedro,

Design is still working on this issue to see if there is a better solution but for now there is no update.

MfgTool can be downloaded from the Vybrid tools section: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fpsp=1&tab=Design_Tools_Tab#

Look under Programmers for the download button or clck the link below:

https://www.freescale.com/webapp/Download?colCode=VYBRID_MFG_TOOL_PRG&appType=license&location=null&...

Best regards,

Richard

0 Kudos
1,794 Views
andreas_veges
Contributor II

Hi Richard,

I urgently need a BSDL file because an EEProm should to be programmed via the SVF512R3K1CMK4 (VF5xxR) controller.

See also my question Chip doesn't seem to work correctly with this BSDL files "Vybrid F Series 364MAPBGA BSDL Silicon Rev... .

Can you help me?

Best Regards,

Andreas

0 Kudos
1,794 Views
romanschnarwile
Contributor III

Hi Naoum and Richard,

Thank you very much for the additional information. We will also try the suggested workaround for now and let you know about the results. I hope you can identify the issue and we find an even better workaround, as the one suggested takes of course some more time during our testing phase which is money at the end. But it would definitely be better than nothing. I'll get back to you once I have an update.

Best regards,

Roman

0 Kudos
1,794 Views
naoumgitnik
Senior Contributor V

Dear Roman,

Sorry for being too brief.

It looks like we have indeed found some "particularities" in the JTAG operation and are further investigating them, with the cooperation of the Vybrid IC design team, at the same time thinking about possible solutions if they get confirmed.

My Applications team colleague Richard Stulens might probably be more specific since he is leading this effort on our side.

Sincerely yours, Naoum Gitnik.

Ross McLuckie

1,796 Views
RossMcLuckie
NXP Employee
NXP Employee

Roman,

We are working with the Vybrid design team and one of our JTAG/BSDL experts to better understand this. The applications team are not familiar with BSDL, the Vybrid design team have confirmed all JTAG/BSDL functionality has been verified and tested on our ATE's (test equipment), we do not use is as part of our TWR testing procedure, we are investigating the possibility to set up a bench test.

Ross

0 Kudos
1,796 Views
jiri-b36968
NXP Employee
NXP Employee

Hi Roman,

we are training to confirm bsdl file with designers. Please confirm that pin itself works correctly. Could you please check it you can toggle pin from normal code? Is the issue only on PTB10 and PTB11?

/Jiri

0 Kudos
1,796 Views
karina_valencia
NXP Apps Support
NXP Apps Support

juangutierrez please continue with the follow up.

0 Kudos
1,796 Views
juangutierrez
NXP Employee
NXP Employee

Hi karinavalencia

I think this is a HW-related question, or to somebody familiar with this CasLan SW or with the BSDL files.

0 Kudos
1,796 Views
karina_valencia
NXP Apps Support
NXP Apps Support

naoumgitnik will you check it with RossMcLuckie?

0 Kudos
1,796 Views
romanschnarwile
Contributor III

Dear support team,

any comment on the request above?

Thanks a lot.

Roman

Toradex AG

0 Kudos