cancel
Showing results for 
Search instead for 
Did you mean: 

DMA cannot read SPI Data Register while Debuging in STM32F745

TA1
Associate III

Dear All,

I faced a problem and I would like to issue a note for other developers. If it is a hardware bug in microcontroller, it may also be helpful for ST developers to fix it for a later revision. Let me explain what I faced in detail. (While trying to find what was the cause of the problem, I made a hardware setup and tested the code. I conducted a lot of try and error methods until I understood what happened. I won’t give all these steps in detail.)

---------------------------------

I developed SPI communications between another microcontroller. One of SPI port is set a transmit only mode and other SPI port is set a receive only mode. Transmit only mode SPI sends 30 half-word every 40us at 27 MBit/sec baud rate. It is expected that the other microcontroller should response the same word counts at the same speed and receive only mode SPI receives these data. DMA1 is responsible for transmitting and receiving data.

First of all, I tested transmit only SPI with scope (Tektronix MSO54-SPI debug tool). What DSP sent; Scope visualized exactly. So, I assured that DMA and transmit only SPI were working well.

Secondly, I needed to test the receiver side but I did not want to put another unknown parameter. Therefore, I made loop back configuration in the hardware. So, what DSP sends, it also receives. Since I am sure about the transmit part, then I can focus the receive part. I also added a control block in software and it compares the sending data with received data. If there is a difference between sent data and received data, a counter increases by one. I run the code in debug mode. I use ST Link as debugger hardware with the trace feature. SPI2 (receive only), SPI3 (transmit only), DMA1, GPIOC and Watch1 watch windows were opened to check registers and other parameters while debugging. After for a while, error counter increased. After 5 minutes, I got 4 errors in communication. Then I made another hardware setup to understand what happened with a test code. I realized that 29 half words were same but only received one half-world was different then what it sent. First figure shows what it sent and what it received. If you look at RX Buffer, 14th and 15th words are same. However, 14th and 15th words of TX Buffer are not same. Then, I thought that DMA might send the same data twice rarely or DMA could not receive the correct data and it copied the previous data. Or maybe over-run happens etc. I checked over-run flag but nothing was there. Then, I used scope again. Whenever DSP realises an error, it toggles one of its output and scope uses this output to trigger and catch both SPI receive and transmit data. I used digital probes because I need 6 channels for it. Second picture shows transmitted (Bus1) and received (Bus2) data. Bus1 shows that 0x5BF1 is followed after 0x77F2. Bus2 shows the same. So, I made sure that the transmitter side (SPI3 and DMA) was working well. I should focus the receiver side, which were SPI2 and its DMA. I thought that it might be about debugging (I tried many things to come this stage). Then, I closed debug session and waited 20 minutes but scope didn’t catch anything. Also, I set a LED to light if any error happens. The LED stayed off during the test. That means there wasn’t any communication error happened. I opened debug session again and received the first fault in 30 second. As I mentioned, many screens were opened in debug mode and I closed most of them except Watch1 window. I didn’t receive any wrong data even in debug session. Then, I opened watch windows one-by-one. I opened GPIOC, DMA, SPI3 respectively and I didn’t receive any wrong data for a long time. Finally, I opened SPI2 (receive only SPI port), I got an error in two minutes. I closed SPI2 again and it worked. Whenever I open SPI2 watch window, I got errors. (I closed SPI3 but SPI2 was still open and error was happened, so it is not about how many watch windows is opened. It is about SPI2 watch window)

I think that the debugger tries to read SPI2 data register at the same time with the DMA1. Most probably, a collision occurs. The DMA1 cannot read correct data and uses the last data. I closed SPI2 watch windows and I left the setup for 14 hours and DSP didn’t receive any wrong data. I don’t know whether or not it is written in any document. If you know any document mentioning this problem please share me. If it is unknown problem, please issue a note for other developers.

Regards

 0690X00000As8HhQAJ.png0690X00000As8HXQAZ.png

1 ACCEPTED SOLUTION

Accepted Solutions

Debugging *is* intrusive, especially if you read registers reading of which has effects to the hardware.

Here, in particular, if the debugger reads out the data register, it advances the internal FIFO pointer, "stealing" the data from the DMA. It's exactly the same effect as if you'd attempt to read the SPI by the processor simultaneously with DMA.

This should be taught as one of the basic facts of mcu programming.

JW

View solution in original post

2 REPLIES 2

Debugging *is* intrusive, especially if you read registers reading of which has effects to the hardware.

Here, in particular, if the debugger reads out the data register, it advances the internal FIFO pointer, "stealing" the data from the DMA. It's exactly the same effect as if you'd attempt to read the SPI by the processor simultaneously with DMA.

This should be taught as one of the basic facts of mcu programming.

JW

Dear Jan

I didn't understand the reason at the first time. After spending hours I realized it is caused debugging but hours have already passed. I've prepared this post for the benefit of other developers. If they will search the similar subject, they will read and understand easly.

I hope it will be useful for the community and save their time.

Thank you very much your explanation and confirming my diagnosis.

Regards,