Imprecise bus fault

dsjnews · ‎2013-06-27

Posted on June 27, 2013 at 17:48

I have recently run into a imprecise bus fault problem as indicated by my hard fault handler. I am using an Olimex STM-P103 development board (STM32F103RB CPU) and there is no OS or RTX present.

I am pretty certain that my issue is not caused by a stack under/over flow problem (my stack has guard regions containing a pattern which I can see has not been corrupted).

Essentially my applciation uses DMA transfers to and from an SPI channel in order to interface with an SD card. In addition I have USART and SYSTICK interrupts occuring and lots of my non-interrupt level code uses bit-banding to access control register bits etc.

I have investigated the problem and I am finding that the store instruction (str R2, [R3]) that causes the problem has somehow got a corrupted R3 value. Its top byte value is changed to 0xFF instead of its usual value of 0x42, hence the hard fault. R3 in this case is the bit-band address of an I/O port used to control an LED. Prior to executing this instruction R3 is loaded from a local variable on the stack so it is possible that the stack value is being corrupted before it is loaded in to R3.

I recently implemented the SD card interface without using DMA transfers and I never got any hard faults at all. In changing to DMA transfers the hard faults have started to appear. Its almost as if a DMA transfer is writting the 0xFF value either to R3 (if that is possible) or to local variable on the stack. In the normal course of events DMA transfers do write the value 0xFF (a clock pattern) to the SD card.

Has anyone else experienced problems similar to these?

Regards

FarmerJo

#dma-spi-stm32-sd

Danish1 · ‎2013-06-29

Posted on June 29, 2013 at 18:00

One ''gotcha'' is if the data you are trying to DMA is on the stack.

The DMA can happen some time later - long after you have returned from that function and the stack is now used for somethig else.

You say you are using SPI. I haven't done SPI on stm32 but as I understand it, for every byte send out, you (can) receive a byte in. If you are writing to SPI by DMA, do you set up another DMA channel to read SPI at the same time? If I were doing so, I might clear MINC so I only need allocate one byte to this ''dummy'' read and (without thinking) tell this dummy-read memory to be a variable on the stack.

Hope this helps,

Danish

dsjnews · ‎2013-06-29

Posted on June 29, 2013 at 19:49

Yes that's good thinking!

The data, however, that is transmitted by DMA to the SPI channel is local to a function and not on the stack. I do use two DMA channels, one for transmitting data to the SPI channel and another for the reply data which is written to a buffer that is also local to a module.

Regards

FarmerJo

emalund · ‎2013-06-29

Posted on June 30, 2013 at 05:06

website error, see below

emalund · ‎2013-06-29

Posted on June 30, 2013 at 05:07

is local to a function and not on the stack

I do not know which compiler you use, but for most ''local to a function'' means ''on the stack''

double post due to website problem.

dsjnews · ‎2013-06-30

Posted on June 30, 2013 at 12:06

Sorry my fault. I should have said local to the module.

Regards

FarmerJo

dsjnews · ‎2013-07-01

Posted on July 01, 2013 at 13:29

Problem resolved!

All my DMA transfers to/from buffers used buffers local to my module except for a single transfer required at the end of a reception used to clock out a single 0xFF value. This was to a local function variable. I have since made this local a static local and the problem has been sorted.

Regards

FarmerJo