2016-02-02 05:20 AM
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'') breakelse{ send a line to COM Port delay 500 ms} //End while loopon 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-!stm32f4012016-02-02 09:40 AM
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.2016-02-02 10:13 AM
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.2016-02-02 10:23 AM
#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.
2016-02-02 11:45 PM
2016-02-09 08:19 PM
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=false2016-02-10 07:44 AM
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.2016-02-10 07:55 AM
Dest = &Msg->Data[source]; // Check the scope hereAnd anywhere you write into data structures.
2016-03-09 02:06 AM
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=falseHard_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=falseHard_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=falseHard_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=falseHard_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=false2016-03-09 03:27 AM
>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 ?