Kl17 DMA LPUART0 hardfault

[johannes_ferch]

Hey guys,

I'm having trouble getting started using the DMA0 engine on an MKL17Z256CAL4R to receive data from LPUART0 and transferring it into a simple ringbuffer in RAM. The basic setup seems to be working fine, the buffer is populated with the correct bytes (at least). However, when I exceed a quarter of the configured max size (DMA_DCRn DSIZE) during the first run, I can trigger a hardfault in a reliable manner (see attached screenshot). There is no apparent problem in the status register (DMA_DSR_BCRn) that I can observe prior to this happening, no bus/configuration errors visible, the BCR is decrementing as expected. I also checked the erratas and couldn't find anything that would fit.

Can you point me into a direction of what's a possible problem here? Please let me know if you need additional code snippets or other information that would help diagnose this issue.

Thanks so much,
Johannes

[FelipeGarcia]

Hi Johannes,

You could also take a look to our lpuart_dma_rb example from the SDK which I think is very similar to your implementation. In this example, data is received in ring buffer first, then a routine will read out the received characters, and echo back them to the terminal by using DMA mode.

Have a great day,

Felipe

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored. Please open a new thread and refer to the closed one, if you have a related question at a later point in time. 

------------------------------------------------------------------------------ 

[johannes_ferch · Accepted solution]

I finally had the chance to look into this issue again and came up with a working solution for my needs. As far as I can see, the lpuart_dma_rb_transfer example seems to work fine for ring buffer sizes smaller than 64 bytes, but has issues when exceeding this number. Adjusting the alignment of the buffer to a 256 modulo boundary seemed to fix the problem for my 256 byte sized array, however.

Is there a general guideline on how the buffer needs to be aligned for the utilized DMA engine on the KL17? On other NXP MCUs, 16 byte alignment seemed to work fine regardless of buffer size. 

Besides that, the initial hardfault most likely originated from function name mangeling introduced by the  c++ compiler in my setup. Adding the missing extern "C" annotations around callback/interrupt routines I forgot helped to resolve this. 

[johannes_ferch]

Hi Felipe,

thanks for you reply, yes I've seen that as well. Trying to get that working on my board as soon as I find the time. Will let you know how it goes.

Cheers

[johannes_ferch]

Thanks for the quick reply. I'm under the impression that the shown address in the screenshot is rather arbitrary and isn't really correlated to the hardfault at all but just the current location of execution when the issue happens. When repeating this procedure multiple times, there's always a different address listed in there. The program itself is not that spectacular and runs fine without any non-aligned accesses or the like unless I enable DMA and receive data over LPUART. The memory buffer is 32-byte aligned and currently not even processed. 

[bobpaddock]

What does the assembly listing show for the address, and a few before it, at the top of the screen shot?

Is everything properly aligned? The M0+ core will trap on non-aligned accesses.