Serial Wire Debug(SWD) and JTAG analyzer

[yogeshL]

I am a new user and just started to use the digital discovery. I want to analyze SWD and JTAG protocols for a project– currently these protocols are not supported in Waveform, is there any plans to support it in the future? This would be really helpful. Thank you!

[attila]

Hi @Shalin

Thank you for the info. Meanwhile I also got an board/MCU with SWD.
I'll update the software in about 3 days, after I finalize some other work with this.

[Shalin]

Hello Atilla,

Thanks for taking the above issues into consideration. Meanwhile, I have a query. In SWD protocol section, under Custom tab, is it possible to customize the waveform generated for the reset() command ?. Actually, in SWD protocol, to initialize SWD operation, a 50 bit line reset sequence followed by 16 bit JTAG to SWD sequence and read the ID code register is required. Therefore, I was interested that if there is an option to modify the waveform for this reset() command and develop waveforms for new developed functions related to read/write memory. This will help in providing flexibility to frequent changes raised by our team and we can implement the same by writing a command for a different wave pattern. 

I will be very grateful if you can provide us with some support regarding the same.

Thanks,

Shalin.

 

[attila]

Hi @Shalin

The trail length can be adjusted.

I've also added a "park drive" since without this the communication was not working above 500kHz, probably the pullup is too weak on the board I have.

[Shalin]

Hello Attila,

Thanks for releasing the new version with fixes in the debugging of the logic analyzer amd other bugs in the waveform tool. Now, the Digilent LOGIC ANALYZER is debugging the captured sequence correctly. 

In the SWD protocol part where we can generate the sequence, I have two queries,

1. In reset(), a 50 bit line reset sequence is generated. However, in addition to it there are other sequences which is required to be added in order to enter SWD operation mode. If we do not add the other sequences, we will not receive acknowledgment from the target. The other sequence includes read of ID code register. You can refer page 17, section 7.2.1 of SWD document provided by NXP attached below.

2. I am also attaching the captured logic analyzer waveform for a read command sent from J-link commander tool. I had to use j-link commander tool to send a read command because the Digilent SWD protocol read/write commands created are not functioning correctly and therefore the waveform captured are incorrect. By using Jlink commander, I am sending a read command to read a value at the address h40086ff8. Therefore, at the output, I am able to get the value h00102073 stored at the address h40086ff8. I have also captured the waveform for this read command in Digilent waveform logic and attached the same below. In the waveform, you will see that the address h40086ff8 is written in TAR register and then the data h00102073 is read from the DRW register. 

I would request you to modify the SWD protocol commands based on the captured read waveform so that the output of logic is same. 

Thanks,

Shalin

SWD Programming NXP Doc.pdf read_add_h40086ff8_data_00102073.dwf3logic

[attila]

Hi @Shalin

You can use a Script like this:

Note the read/write does not support wait or fault.

[Shalin]

Hello,

Thanks for providing the solution to our queries. In our read capture, there is a wait present. If we do not give wait, it will result in showing wrong output value at h40086FF8. We need to give wait. Could you please let me know the solution to the same. 

Thanks,

Shalin

[Shalin]

In addition to my above statement, when we give wait (0.01); , we get the parity error in DRW. 

Also tell me what is the syntax for wait/fault ?

[Shalin]

Hello Atilla,

I am unable to get the data 00102073 in DRW register. It shows some invalid data after write to TAR. The first five data values of the registers ID code, ABORT, SELECT, CSW, TAR match with the read waveform. However, the value of last register i.e. DRW should be 00102073 which does not match with the read waveform attached below. In the waveform shown below, you can see the value is 00102073 in DRW register whereas in your waveform protocol (shown below) it can be seen that the value is hFFFFFFE0 in DRW register. Please see if there is any issue of wait which can be seen in the read waveform between TAR and DRW register, whereas there is no option to put wait in your developed protocol. 

read_add_h40086ff8_data_00102073.dwf3logic

[attila]

Hi @Shalin

The SWD read/write is generated as pattern. Even if the target does not acknowledge it will continue to generate the data section.
With the earlier script I was expecting the software wait(0.01) 10ms before read to help, so the target acknowledges immediately.

Support for wait/fault would take a few days. I don't know when I will have time to implement this.

[Shalin]

Hello Atilla,

Thanks for the prompt reply. Meanwhile, I will be very grateful if you can have a look because we are not able to get the right value in DRW register. Is it possible to do something from your end so that we can see the correct value in DRW. Actually, we are stuck in the middle of validating a module. 
Thanks again for taking out time to correct the things in a short span of time. 
 

Shalin

[attila]

Hi @Shalin

FYI: I'm working on it... hope to have it ready today or next week

[Shalin]

Hello Attila,

Thank you so much. I have debugged from my end, the wrong value in DRW is due to the lack of wait command which appears between TAR and DRW access. Once we give wait, the correct value appears in DRW register. 

Thanks,

Shalin

[Shalin]

You will just have to add the Wait command support. I think it should be fine then.

[attila]

Hi @Shalin

Read/Write now support ACK, you have Retry count option/argument...

The SWD is now implemented using ROM logic (state machine). I had to rebuild all the device configurations to have support for three state output for ROM.
I don't like Friday evening releases but I hope most of the thigs are working. 

[attila]

Hi @Shalin

Fixing some minor things:

 

[Shalin]

Hello Attila,

I would like to thank you for putting in so much efforts to make things work and taking out time to work on weekends. Now, the things are working perfectly. In case I face some issue while doing the debug, I will let you know. 

Thanks again for getting the things done so quickly in a brilliant manner. You were very helpful to us. 
Shalin

 

 

 

 

Edited March 20, 2023 by Shalin

[attila]

Hi @Shalin

I thank you for bringing this up and for the help. Now the app has a new feature :)

[JAlaj]

Thank You Shalin and Attila.

I appreciate the good work and prompt responses from both sides to close the gaps.

Moving forward we would like to develop LabView based automation for this application. Would be great, if you can suggest Shalin about the library and .dll files etc. to be used.

Regards,

Jalaj

 

[attila]

Hi @JAlaj

The SWD is currently only available in the WaveForms application.

[JAlaj]

Thanks Attila

We are planning to use Digital Discovery extensively in our project. We are using SPI,I2C, JTAG and SWD

Just wanted to know if there is a roadmap for JTAG and SWD LabVIEW support.

I understand it has been a recent development and I truly appreciate that you put a lot of hard work to get it done. 

Would be great to have a LabVIEW based utility for same

 

Many Thanks,

Jalaj

[attila]

Hi @JAlaj

SWD SDK/API functions are available in the latest version:

 

[JAlaj]

Thanks a lot Attila

I really appreciate the awesome support. You are setting the new standards and increasing our expectations.

Regards,

Jalaj

[Shalin]

Hello Attila,

I have a query. In the protocol and output window tab, I am unable to get the data while I read/write a script. I think the device Digilent digital discovery is unable to pull up. It pulls up when I initially connect using J-link debugger probe and then further read/writes through Digilent. However, in the beginning, when I power up the board and send read/write commands through Digilent, it does not show any data. I am attaching some screenshots below. 

Thanks,

Shalin

[attila]

Hi @Shalin

The Digital Discovery has optional 10k pull up/down for each DIO which can be enabled in the Supplies tool.

The ACK 7, b111 indicates no reply from the target, so the signal is pulled up or pulled up.
Use the Logic Analyzer for more detail.

[Shalin]

Hello Attila,

Thanks for the prompt reply. Yes, I saw that there is no response from the target. It shows the response once it is connected using the Segger J-link. Once it becomes connected, we remove J-link, and attach Digilent to see  further read/write response. Then the Digilent starts showing the response. The Digilent does not show the response initially when I power up. After power up, I need to connect the Segger to establish connection and then I see response in Digilent.

Mainly, I wanted to use Digilent completely for setup. This is the reason I thought that Digilent is not able to pull up the target initially. 

Thanks

Shalin