Hello,
I made a boundaryscan project for a board with a Vybrid module MVF50NS151CMK40 using the "Cascon" tools from Göpel electronic.
I have a bad answer when I read the ID register:
Cascon tools reads 0100 1011101000000000 01000111011 1 (4BA00477).
Value expected (see BSDL): 0001 1001100000000000 00000001110 1 (1A80001D).
The value reads (4BA00477) is the "debug ID code from the JTAG DP port" (see sheet 1286 of the VFXXX controller reference manual).
So, I understand that the Vybrid is in debug mode, not in test mode (JTAG 1149.1).
In the BSDL (VYBRID_364_F.bsdl), there is no compliant pattern or design warning.
Is there a special configuration to work with the "test" tap port, based on IEEE1149.1 specification ?
Regard.
Luc
Hi Luc
The picture is too small for me to see the details but you mention :
"-Load IR (Instruction Register) with IDCODE opcode."
According to Table 9-19 in Reference Manual the IDCODE for
JTAGC should 4'b0000 (as opposed to 4'b1110 for ARM DAP).
Perhaps you can verify what IDCODE is being sent by the tool
are using.
Hope this helps.
Regards
Sinan Akman
Hi Sinan,
The IDCODE "opcode" sent by the tool is 4'b0000, the tool use informations from the bsdl file.
Sorry for the picture, I put a new one:
I don't understand why I am in the ARM DAP, I should be in the JTAG TAP : perhaps a bad hardware configuration, but I did not find
any information on this subject.
Thanks for your help.
Luc
Hi Luc
On my TWRVF65GS10 board I have no problem reading both idcodes :
JTAG>wir 4 00
JTAG>rdr 32
1980101d
JTAG>wir 4 0e
JTAG>rdr 32
4ba00477
Are you able to send out IDCODE instruction manually to your board ?
Your SoC is slightly different than mine but it should work the same
way. Perhaps you can contact to your test vendor and see if this a bug in
their software.
If you prefer you can capture your JTAG lines using a logic analyzer from
start until you see the problem and send my way. I can then take a look
and probably see what's going on.
Regards
Sinan Akman
Hi Sinan,
Thank you for the time spent answering me.
The goal of this test is not only to check the IDCODE, but to communicate with the
boudary scan register to read/write external I/O (not chek internal functions of the SOC).
Checking the ID code validates the jtag chain (the right component in the right place) and after the testor go to the next step who is "interconnections test" to chek connections between boundary scan devices.
I did this test, and I got anything as a result.
My understanding is that I am not communicating with the right jtag chain, but I do not understand why.
Normally, if the component complies with standard 1149.1, the IDCODE register of the bsdl should be accessible through the jtag bus, without the need to write in the instruction register (see below):
if the component is not in phase with this procedure, this must be specified in the bsdl (compliant pattern or design warning), but, at this time, I don't find these informations.
I do not have a logic analyzer, but I think it is possible to visualize with the tester the TCK / TMS / TDI / TDO signals. I will send you the captures if it works.
Thanks for your help.
Luc
Hi Sinan,
Using the analyzer of the tool,I realized that the tester came directly to read the IDCODE without sending the instruction before: it is an error on my part, it is possible to preload the instruction register before reading the IDCODE. I made the correction and it's now ok. I apologize for the inconvenience.
Many thanks for your help.
Luc
Bonjour Luc
I am very happy to hear that you resolved the issue. The idcode is also available in the data register right after when the TAP is reset. But in your case Vybrid is a bit unusual in that the DAP and JTAGC are sharing the same instruction register and it seems out of reset it is returning the idcode of DAP. By retrieving the idcode explicitly now using the IDCODE your test software seems to be working well.
Happy to hear you can continue your projects. If you have any other questions related to JTAG particularly for NXP SoCs please don't hesitate to ping me either directly or via this forum here.
Best regards
Sinan Akman
Hi Sinan,
I keep developing the test program and it seems that the Vybrid I/O are not driveable.
The output remain in hight impedance state even if I try to drive a 0 with the EXTEST instruction.
I found in another thread a document "BSDL_errata", but I would like to be sure that this errata applies to the component
use by the customer.
Do you know if I can fin a "more official" information on NXP Website about this issue ?
Many thanks for your help.
Luc
Hi Luc
Sorry for the late reply. The only documents I have access on Vybrid SoCs are the documents that are on the web. I believe at one point NXP granted Timesys the support for Vybrid SoCs. Perhaps you can ask them if they have an official errata on BSDL. Likewise Yuri might be able to send you any known official errata of this SoC.
Are you having difficulty driving a set of pins or only a particular one ?
Regards
Sinan Akman
Hello,
According to the following Community thread, it contains workable BSDL.
https://community.nxp.com/thread/309613
Regards,
Yuri.