Is the programming protocol of the SWD interface of STM32 public?

According to the Arm manual, each conversion on the sender side requires a TNR, but when I look at the JLINK waveform, there is no damn TNR.

The manual says that asynchronous SWD requires it and synchronous does not - or vice versa, but I didn't find a description of synchronous vs asynchronous.

For now, just ignore the TNR and read the damn IDR.

In addition, the reset timing of JLINK is very strange, roughly

70clk High, 0xe79e (note, SWD is LSB First),

70clk High, 0xedb6 (weird here, can't find a description),

70clkHigh, 16clkLow, 0xa5,

Note that this should be the TNR bit according to the protocol - but this bit is not actually observed.

0b100 (ACK-OK), 0xba01477…

In actual testing, the IDR can be read as usual without adding the strange 0xedb6.

Also note that the data on the device side should be read at the falling edge of CLK, or after a delay of 1/2 bit after the rising edge.

If you want to go deeper, you can go to sourceforge.net to download SWD Lib and openOCD. It will be very convenient to compare the two.

It is very comfortable to write programs using bitband, especially when processing SWD bit streams. An int32 pointer jumps very smoothly, and it is an LSB First structure.

There are absolutely no obstacles.

In addition, it is found that after reading IDR, after the ACK of other read and write commands, SWDIO will have a slowly rising waveform of two bits.

And they are pulled down by Target at the falling edge of clk. If the format is followed rigidly, these two bits should be ignored.

No explanation for these two positions has been found so far.

Sometimes, it can be seen that when JLink reads the last bit of information, it will pull down the parity that should have been sent by the Target and ignore it.

It is also important to note that, except for reading the IDR, CTRL, and ABOUT registers, reading other registers has a data frame delay.

For example, if you initiate the first read, the data read is meaningless.

The second read frame reads the data corresponding to the first address, and so on.

In terms of hardware, the pull-up of SWDIO must be strong enough, otherwise the rising edge may not be steep enough. I am currently using 2.2k, which is okay.

I saw that the source code of SWD LIB is based on 8-bit reading and writing and 32-bit reading and writing.

In other words, as long as SWCLK is controlled well and no SWDIO bit information is lost, SPI can also be used to simulate the SWD timing.

This part refers to the LibSwd project of SourceForge. The project is open source, written very rigorously, and the code style is also very good. I strongly recommend you to take a look.

The original code has four functions, read, write, 8, 32. I reduced it to two functions, using the bitband structure so the entry is simpler, just the buffer and the number of bits.

int iLibSwdMosi(unsigned int* pBits,unsigned int iLen)
{
        unsigned int i;
        
        for(i=0;i

What do you think when you see return(0)?

Hey, originally I used a timer to control clk, so I needed to consider the return code when the program ran into an error.

Later I realized that this was stupid, so I just waited until death.

In this way, there is no need to return exception information, but in order to maintain the consistency of form, the function still has the appearance of a return value.

Here is the delay function, the capitalized quantity is the macro definition

int iLibSwdDelay(unsigned int iDly)
{
        unsigned int i,k;
        
        for(i=0;i

Here is the function that switches to SWD mode and reads the IDR.

int iLibSwdSwitch2SWD(void)
{
        unsigned int i;
        
        for(i=0;i

If the read is successful, a pointer will be returned. The buffer corresponding to this pointer is pre-allocated. Since the program has not been modified, it is not very nice here. You can use your own ideas.

The part shielded by /**/ is the weird part in JLINK waveform. There seems to be no difference between shielding and not shielding when reading IDR.

I don't know what JLINK is used for. Does anyone know?

Sometimes, in order to distinguish whether the bit is sent by the host or the target, some adjustments can be made to the timing.

Target always sends data on the rising edge of Clk, and Host can send data a little before the rising edge.

In this way, you can use an oscilloscope to distinguish whether it is the Target or the Host that sends the 0

In addition, the manual mentions that several extra clk cycles are appended to each data frame.

The JLink waveform does show this, but it doesn't seem to appear all the time.

I haven't found any impact on this yet, maybe it's for universal considerations.