DMA giving hardfault in STM32F4 Nucleo @84Mhz

[darla14]

Posted on February 02, 2016 at 14:20

I have modified an STM32F4 example and developed a windows application to interact with it for sending data continuously.I am reading a file on PC line by line and sending continuously each line on a serial port (COM9) to which STM32F4Nucleo board is connected.

STM324 is running @84Mhz and UART is configured at 921600 Baudrate.

Host code : 

loop : 

while(1)

//being while loop

//read a line from a text file

 if(line == ''EOF'')

   break

else

{ send a line to COM Port 

   delay 500 ms

}

 //End while loop

 

on STM32 : 

int main(void)

{

  

 HAL_Init();

  

  /* Configure the System clock to 84 MHz */

  SystemClock_Config();

  

/* Initialize UART */

USARTConfig();

        

  /* Infinite loop */

  while (1)

  {

    

if (UART_ReceivedMSG((TMsg*) &Msg)) {

 //do the processing of the MSg data

                   printf(Msg.Data);

}

attached is the file where UART_ReceivedMSG is defined.

So here I am able to see the data coming (on console I/O of the IDE I am using - IAR)

but at times I am getting a hardfault at 

Get_DMA_Flag_Status > 

uint32_t Get_DMA_Flag_Status(DMA_HandleTypeDef *handle_dma)

{

  return (__HAL_DMA_GET_FLAG(handle_dma, __HAL_DMA_GET_FE_FLAG_INDEX(handle_dma)));

}

What could be the cause for this?

Is it some sort of non atomic operation happening at the handle_dma.How can I avoid it.

Thanks in advance !

#hardfault #hardfault #hardfault #uart #dma #dma #dma #stm32f4 #!stm32f4-!stm32f401

[Tesla DeLorean]

Posted on February 02, 2016 at 18:40

You'd have to look explicitly at the assembler code and processor registers where the fault is occurring.

DMA itself will not cause Hard Faults. If it trashes the memory arena (stack, heap, statics) you can expect all manner of knock on effects, including Hard Faults. Here handle_dma is likely corrupted.

I'd make sure my stacks were big enough, and place the DMA buffers with guard zones painted at each end, and then making sure it remained within those limits.

Really can't help you with problems in the HAL code.

[darla14]

Posted on February 02, 2016 at 19:13

I'd make sure my stacks were big enough, and place the DMA buffers with guard zones painted at each end, and then making sure it remained within those limits.

>>Can you please tell more about this trick.Painting the ends of DMA buffer.May be I can try to check with this where the memory corruption is happening.

[Tesla DeLorean]

Posted on February 02, 2016 at 19:23

#define BUFSIZE 256
char bigbuffer[BUFSIZE + 128];
char *buffer = &bigbuffer[64];
memset(bigbuffer, 0xCD, sizeof(bigbuffer));

Periodically check the 64 byte areas at the front and back of the buffer have not been modified. A memcmp() of the front and back would be crude but effective.

[darla14]

Posted on February 03, 2016 at 08:45

Windows application is running on 1.8Ghz PC intel i5 processor , sending data in a while loop, while STM32 is runnign @84Mhz.COuldnt it be the reason for this?How can we synchronize this huge frequency difference .Can STM32 take care of this internally, but UART RAM RX buffer is of   length 512 (as per below)

#ifdef USE_USB_OTG_HS

#define TMsg_MaxLen             512

#else

#define TMsg_MaxLen             256

#endif

To use ''DMA'' or not to use ''DMA'' is the question now?

[darla14]

Posted on February 10, 2016 at 05:19

Hi,

Any update on this.I am attaching the snapshot of the stack, DiAssembly at the time when the hard fault occurs.I doubt there is some concurrent access to the DMA status variable by the hardware as well as the firmware(my view - though less likely).

The hard fault occurs after receiving some 5500 lines of data , where each line has average 200 characters.

The STack being used is 0x5000 (20K) , heap = 0x200 .RAM is total 94Kb and ROM is 5

I have enabled the the Graphical Stack usage analysis and I can see at the hard fault there is no stack overflow sign(at the time of stack over flow the bar turns RED ) , figure -> hard_fault_stack.png.

I am not able to figure it out or the way to debug this cause?Memory issues or DMA hardware fault?

Looking for some expert opinion to know this mysterious behavior !!Ask for any other thing if required.

________________

Attachments :

Hard_Fault.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzWN&d=%2Fa%2F0X0000000bN5%2F_AYHMwCYFkWMprH4bv6vBvIWLRmEaznY3xSugMRhiUs&asPdf=false

[Tesla DeLorean]

Posted on February 10, 2016 at 16:44

Looks like handle_dma (&hdma_rx), or the structures it points at, are getting corrupted. You'll have to look at how you are managing the data as it comes in. And a what point the corruption occurs.

You'd want to look at the value held in R0 at the fault, and then work backward from there.

[Tesla DeLorean]

Posted on February 10, 2016 at 16:55

Dest = &Msg->Data[source]; // Check the scope hereAnd anywhere you write into data structures.

[darla14]

Posted on March 09, 2016 at 11:06

I am revisiting this.Please see the attached snapshot.The hard-fault is coming form the cube_hal.c code .I see no sign of stack overflow or any other memory corruption.

LDR R0,[R0,#0x4] is giving hardfault.

Is there any simple code I can use to transfer data from the PC over UART to STM32F401 RE.This is very strange to me as I am doing some processing of the data ,if I remove that code and do just receiving of the data no hard-fault occurs.So I wonder if that code is reaching or corrupting that memory which is used by the dma handle instance?

Rgds,

Rp

________________

Attachments :

Hard_fault_1_Register_Window.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtkK&d=%2Fa%2F0X0000000aWU%2FKT2ozo93WieQIRxrl6XPkoJcXKFqjpVD0K692fYElK0&asPdf=false

Hard_fault_2_stack_size.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hthq&d=%2Fa%2F0X0000000aVz%2FmPLnMT2pk7QAsiAaTTeZuEwIBpzHuWjVAs4t1NuQeaQ&asPdf=false

Hard_fault_3_Optimization.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtkZ&d=%2Fa%2F0X0000000aWV%2Fls9q_3uNcZ4ZYoq0lFS26Z.aXN9Feu60kGmW644xQSM&asPdf=false

Hard_fault_4_Exception_Frame.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htkj&d=%2Fa%2F0X0000000aWW%2FAmT.6L8VEy65Kh42f9t1mF0dTvdtxdomCApOBU5ImZU&asPdf=false

Hard_fault_5_stack_Window.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htjr&d=%2Fa%2F0X0000000aWO%2Fp4h0ERguitPIkuarv4EotnMnlm18eNZy7sabIXbPoik&asPdf=false

[AvaTar]

Posted on March 09, 2016 at 12:27

>LDR R0,[R0,#0x4] is giving hardfault.

 

And what are the contents of R0 before executing this instruction ?

Or, in other words, which address you try to access when hardfaulting ?

[darla14]

Posted on March 09, 2016 at 12:38

And what are the contents of R0 before executing this instruction ?

Or, in other words, which address you try to access when hardfaulting ?

I think above two Qs are different(one is before executing the instruction .what was the content of R0 and second is what was the content at the time of access which gives HF).Answer for the second is in the snapshot I have attahced in previous post.

Correct me if I am wrong !

How can I find what you asked in 1st Qs?

There is while loop where this code is running and it is coming after some 10-15 minutes of run.I may have to debug step in and out to find this.I can do that and paste the result here if you want it.