2021-10-18 09:01 AM
Hi, I am trying to receive 19 bytes in UART in DMA mode. I have configured both the peripheral (DMA_CCR_PSIZE) and memory alignment(DMA_CCR_MSIZE) as byte.
When I Enable the UART receive in DMA mode, I encountered with Hardfault exception. After debugging the hardfault exception, I found the reason as un aligned data access. With this, now i configured the UART receive in DMA mode for 20 bytes. Now it is working without hardfault exception.
Can Some one help me to understand what happened exactly here? Is this the data alignment issue since I configured for 19 bytes? If yes, then what is the meaning of DMA_CCR_PSIZE and DMA_CCR_MSIZE in DMA_CCRx?
2021-10-18 09:17 AM
The DMA isn't the cause of the hard fault here. It can transfer bytes no problem, and certainly it can do an odd number of transfers.
The issue has to be elsewhere. Perhaps you are accessing uint16_t data from an odd address. Step through your code and see which line causes the issue. The call stack when you're in the hardfault handler should be informative.
Please include your chip number next time. I'm assuming it's a Cortex-M0.
2021-10-18 09:44 AM
DMA can't use CPU side Hard Faults. The DMA flag it's own bus/address issues, but you have to fish those out of status registers.
Also DMA should not have issues with odd numbers of bytes when doing byte width transfers.
>>DMA_CCR_PSIZE and DMA_CCR_MSIZE
Width of transaction on the bus, will need memory suitably aligned, ie 4-byte WORD needs to be occurring on 32-bit aligned memory address, so (addr & 3) == 0
The memory is byte addressable, 32-bit data spans 4 address locations.
2021-10-19 12:27 AM
hello TDK,
Thanks for your reply.
I am working on Cortex-M33. Controller is STM32L562xx. Trusrtzone is not enabled. I am new to this device. IDE I use is IAR EWARM 9.10.2.
I agree that DMA is not the cause of this problem here. I have tried to trace the line at which hardfault is triggering. Step by Step execution is not giving any result here. I tried to see the stacked frame in onoline debugging by keeping breakpoint at the entry of Hardfault handler.
Current LR is 0xFFFFFFA8. From this I have decoded this and understood that exception occurred in Thread mode and Main Stack pointer is used. So I tried to locate the MSP_NS from registers window. But this value is appearing as 0x00. I am not sure what is the used stack address here.
Debug log window is showing this message - "A precise data access error has occurred (CFSR.PRECISERR, BFAR) at data address 0x55504340".
I couldn't understand why data address is pointing at 0x5550xxxx Since my code address is located in between 0x08000000 to 0x0807FFFF and SRAM is in between 0x20000000 to 0x2003FFFF.
2021-10-19 09:05 AM
> I couldn't understand why data address is pointing at 0x5550xxxx
Because you have some bug in your program, using some pointer incorrectly.
Do you have somewhere a string saying "@CPU"?
JW
2021-10-20 01:14 AM
Hey, From the stacked frame, I found the root cause. Due to un intended increment of one buffer index, USART Instance is pointing to 0x5550xxxx which is not a valid address. Corrected this and now my code is working as expected.
Thank you all.