Skip to main content
MSatish
MSatish
Associate II
October 18, 2021
Question

Can I configure the UART in DMA mode for transmitting and/or receiving ODD number of bytes?

  • October 18, 2021
  • 5 replies
  • 1447 views

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?

This topic has been closed for replies.

5 replies

TDK
TDK
October 18, 2021

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."
MSatish
MSatishAuthor
Associate II
October 19, 2021

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.

Tesla DeLorean
Tesla DeLorean
Guru
October 18, 2021

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
waclawek.jan
waclawek.jan
Super User
October 19, 2021

> 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

MSatish
MSatishAuthor
Associate II
October 20, 2021

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.

Terms & ConditionsAccessibility statement