SPI DMA delays or misses SYSTICK ISR?

[gds23]

Posted on July 10, 2011 at 23:26

I have SysTick generating an IRQ every 100 usec. With no SPI DMA occurring I see about 881383 isr occurrences in 90 seconds (ideally 900000) if all clocks were perfect.

When I enable fairly active  SPI DMA while running the same test, I only see about 750000 isr occurrence in 90 seconds.  From what I understand, the SysTick timer is only supposed to stop when the system is halted for debug. So with DMA active, it appears the Systick ISR can get delayed or possibly even missed. Does this seem possible? -g

[Tesla DeLorean]

Posted on July 11, 2011 at 01:52

So with DMA active, it appears the Systick ISR can get delayed or possibly even missed. Does this seem possible?

It's not missing it, rather you have some other servicing going on, of higher priority, which exceeds the tick rate you'll end up servicing a subsequent tick. The interrupts do not accumulate. Examine very carefully your DMA interrupt routines, and other interrupt routines, and your priorities. If you do anything that writes flash memory, or spins in loops, you'll want to look at that. You also have finite memory bandwidth. Determine how many processor cycles you actually have at 100us, consider the DMA, consider the FLASH wait states. The consider how many of these cycles are consumed by your code. Are you doing any floating point computations?

[gds23]

Posted on July 11, 2011 at 05:09

So with DMA active, it appears the Systick ISR can get delayed or possibly even missed. Does this seem possible?

It's not missing it, rather you have some other servicing going on, of higher priority, which exceeds the tick rate you'll end up servicing a subsequent tick. The interrupts do not accumulate. Examine very carefully your DMA interrupt routines, and other interrupt routines, and your priorities. If you do anything that writes flash memory, or spins in loops, you'll want to look at that. Currently I only have the SysTick_Handler ISR. The SPI DMA is running ''full duplex'' in that I provide a send buffer and a receive buffer and begin the DMA transfer and wait for by polling for DMA complete on both transmit and receive -- not using an ISR for any DMA events right now. Priority of ISR and DMA is still ''default''.You also have finite memory bandwidth. Determine how many processor cycles you actually have at 100us, consider the DMA, consider the FLASH wait states. The consider how many of these cycles are consumed by your code. Yes, during the 100us tick ISR a lot needs to happen including the DMA transfers. Not sure if enough time to do much considering how it is looking right now with just a simple stripped-down ISR. Also, not sure how to figure the number of cycles the DMA transfer actually uses.Are you doing any floating point computations? No floating point.

[gds23]

Posted on July 19, 2011 at 22:51

[Tesla DeLorean]

Posted on July 20, 2011 at 03:28

Doesn't sound too hard to replicate.

What kind of transfer lengths are you using, do you have HT and TC interrupts?

[gds23]

Posted on July 20, 2011 at 04:41

What kind of transfer lengths are you using, do you have HT and TC interrupts?

The transfer length on SPI is currently 22 bytes (11 half-words) plus a 2 byte CRC automatically generated. I am running full duplex so the receive and transmit DMA channel are active simultaneously.  I am continuously running the DMA SPI transfer in a fairly tight loop.  I have not enabled any of the DMA transfer complete (TC) or half-transfer (HT) interrupts.  I am currently just polling the DMA_ISR register for transfer complete on the send and receive channel -- no interrupt is produced. As I mentioned before, the only IRQ I have enabled is systick running at 100us tick-rate.

[gds23]

Posted on July 20, 2011 at 17:12

New information: If I disable the automatic CRC generation and checking on SPI, the systick ISR occurs with no apparent skips or misses.

So there appears to be a bug/errata in the chip on the STM3210E-EVAL board.

[gds23]

Posted on July 22, 2011 at 16:33

> New information: If I disable the automatic CRC generation and checking on SPI, the >systick ISR occurs with no apparent skips or misses.

>So there appears to be a bug/errata in the chip on the STM3210E-EVAL board. Sorry, problem *not* caused by CRC at all.  Problem is in the nature of the cortex-m3 core systick itself in that ''disabling'' its interrupt at the systick control register 0xe000e010 does not allow its IRQ to remain pending after it is re-enabled so it will be missed or skipped. Problem is discussed in depth here: http://forums.arm.com/index.php?/topic/14203-temporarily-block-systick-interrupt-but-not-lose-it/ (Note: I could not get the solution proposed here to work correctly.) http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/p/60082/215015.aspx (This basically just confirms the issue with systick interrupt disable.) The solution to my problem is 1. Never actually disable systick IRQ at its control register, or 2. If systick must be disabled, use the global disable, i.e. __disable_irq() since this will allow systick to be pending when __enable_irq() is called. Of course, this disables all interrupts which may or may not be OK, or 3. Use a STM32 timer like TMR2 instead of systick. Disabling its interrupt does not cause it to be skipped but it seems harder to setup and control than the simple systick.

[root]

Posted on July 22, 2011 at 16:46

Hello,

Why not use BASEPRI instead of disabling all irqs ?

Don't know for sure if systick priority is configurable but I think so.

Thomas.

[gds23]

Posted on July 22, 2011 at 22:03

> Why not use BASEPRI instead of disabling all irqs ?

> Don't know for sure if systick priority is configurable but I think so.

  Yes, I have not researched this but I think the links above also mention this as an option that is now on my list. Thanks for the suggestion. -g