External SRAM + USART Interrupt IO = USART RX Overrun?

[mfranklin]

Posted on May 02, 2013 at 15:23

I have the following configuration:

- STM32F4 MCU - 2 external SRAM chips (at 0x6000000 & 0x64000000) - USART1 running in Interrupt IO mode. - Stack in CCM The SRAM and USART code is almost verbatim from the STM32F4 peripheral library examples. Both SRAM chips work great.  The USART works great.  However, when I'm receiving a lot of data on the USART (approx 1024 bytes @ 115200 baud), and simultaneously reading and writing heavily to the external SRAM (a few hundred kilobytes at a time), the USART starts to get RX buffer overrun errors, and the data received is less than accurate.  If I increase the addressSetupTime and dataSetupTime of the SRAM, the RX buffer overruns occur more frequently.  If I decrease these settings, I get fewer RX buffer overruns.  However, if I decrease them too much, the SRAM doesn't work.    Decreasing the amount of reads/writes per second to external SRAM also decreases/eliminates the occurrence of the RX buffer overruns. It's as if the heaving reading and writing to SRAM causes resource contention for the MCU, and the USART RX interrupt can't be serviced in time.  I've tried setting the USART interrupt priority to the highest possible, but the problem remains the same. Can anyone take a guess as to what might be causing this behavior? #usart-sram #usart #external-sram-usart-stm32f4

[jpeacock2399]

Posted on May 02, 2013 at 15:47

Assuming you are running the F4 at full speed, 168MHz, I'd first run a test using internal SRAM to make sure it is the external SRAM causing the problem.  The F4 should not be dropping data at 115Kbaud if it's the highest priority interrupt.  I run an F2 (120MHz) at 115K with no problem writing to internal SRAM.

You might also consider using DMA, at least for USART out, and if you have fixed size messages for USART in too.  Interrupt overhead drops dramatically.   Jack Peacock

[mfranklin]

Posted on May 03, 2013 at 10:56

I solved the problem.  As many of you probably assumed it had nothing to do with the SRAM.  The SRAM only exacerbated the problem.

In my USART ISR, I was handling interrupts in this order: 1.  Handle Errors 2.  Handled RXNE 3.  Handle TXE When I changed it to ... 1.  Handle TXE 2.  Handle Errors 3.  Handle RXNE ... the problem vanished.  No more overrun errors. If someone wants to offer an explanation for why the order is significant, I would be grateful.