USART receive with DMA not working on STM32F1xx

[elmar]

Posted on August 19, 2015 at 19:43The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on August 19, 2015 at 19:56

Do you have some defines supporting this?

[elmar]

Posted on August 19, 2015 at 20:07

Oops, sorry. These are important of course...

---

#define

DMA_CHANNEL_USART_TX

DMA1_Channel4

#define

DMA_PRIORITY_USART_TX

DMA_Priority_Low

#define

DMA_COMPLETE_USART_TX

DMA1_FLAG_TC4

#define

DMA_CLEAR_USART_TX

DMA1_FLAG_GL4

#define

DMA_CHANNEL_USART_RX

DMA1_Channel5

#define

DMA_PRIORITY_USART_RX

DMA_Priority_High

#define

DMA_COMPLETE_USART_RX

DMA1_FLAG_TC5

#define

DMA_CLEAR_USART_RX

DMA1_FLAG_GL5

---

[elmar]

Posted on August 19, 2015 at 20:10

And this perhaps as well for completeness: 

#define

LINK_USART

USART1

[Tesla DeLorean]

Posted on August 19, 2015 at 21:21

I'd switch the ordering of these

 DMA_Cmd (DMA_CHANNEL_USART_RX, ENABLE); DMA_Init (DMA_CHANNEL_USART_RX, &dmaInit);

[elmar]

Posted on August 19, 2015 at 22:03

Hmm, yes I tried that before and tried it just again with a bit more care. Things are weird.

There seems to be some change, but that is only directly after programming, not after a power cycle. What I find are two differences:

• It still does not show the DMA complete flag, but once I can see that the receive buffer is non zero. After that first event after startup the receive buffer remains zero.
• before the change I would keep receiving data directly through the USART. If the DMA is working that should be nearly impossible. Now I can't see anything come in on the USART directly any more, so the DMA seems to be doing something. But at the same time, still no show on the DMA.

After a power cycle it reverts back to the old thing in that I can clearly read from the USART directly but no response at all from the DMA.

BTW here are the byte counts for the DMA: 

#define

STANDARD_PACKET_SIZE

5

#define

STARTUP_PACKET_SIZE

1

[waclawek.jan]

Posted on August 19, 2015 at 22:28

- don't look at the USART registers with the debugger (reading the status register by debugger clears the receiver flag and that spoils things for DMA)

- post the relevant DMA registers' content JW

[elmar]

Posted on August 19, 2015 at 22:45

Thanks for the hint regarding the debugger, particularly for anyone else coming across this conversation. I my case, I am never using the debugger. But just in case reading the memory location at the receive buffer does interfere, I removed that code and I am now just looking at the DMA complete flag. That changed things to the degree that I now get this flag, but just once. This even works after a power cycle.

Real progress, but not quite there yet. Somehow that feels like I am doing something wrong now when it comes to getting the DMA ready for the next go. I'll be poking around that code... To that end one question: Should I set the memory base address each time when I set the DMA byte count? Clearly the byte count gets modified by the hardware as each byte is received. Since it's incrementing the memory address, does that get modified as well? The driver API has not function for that, so the assumption was I didn't need to do that, though I tried it both ways.

[elmar]

Posted on August 19, 2015 at 23:12

DMA1-ISR gets to 0x00007007 all the time (as far as I can see). I have channel 1 running on the A/D converter for continuous conversion. Once a the beginning it gets to 0x00077007. This is matching hat I am observing otherwise.

[elmar]

Posted on August 22, 2015 at 01:49

For the benefit of anyone else coming across this port, it seems the glaring omission was:

RCC_APB2PeriphClockCmd

(

RCC_APB2Periph_AFIO

,

ENABLE

)

;

Though I am not sure why the transmit worked...