k10dx256VLH7 UART DMA with periodice trigger only sending every other byte

[andrewparlane]

I'm working on a new product using a MK10DX256VLH7 microcontroller on a custom board. Since that chip is not supported by the KSDKs I've ported the 100MHz MK10 KSDK so I can use the pre-existing drivers. I'm aware there are differences between the 100MHz chips and the 72MHz ones but I think I've accounted for all of those, and ruled them out as being the cause of my current issue.

I have pre-existing code that outputs UART data with a specific delay between each byte (DMX with a configurable inter-slot time), the way I achieve this is by using a EDMA channel (2) with the source set as the UART Tx, I then enable the periodic timer mode in the DMA Mux, so a byte is sent out every Xus. This code works fine on the MK12DX128VLF5 for which it was originally written. However when I attempt to use it on my MK10DX128VLH7 it has the odd behaviour that it only sends out every other byte.

If I adjust the PIT timeout, I see the frequency of the bytes being sent change appropriately, so it's not that my PIT fires too fast. I also tested it and confirmed it is correct.

If I disable the periodic trigger mode, then I get all bytes sent out, but obviously with no gap between the bytes.

I've examined the TCD registers and everything is correct before the transfer (CITER / BITER are 10, source and destination addresses are correct, no modulos, src offset 1, data widths 1, etc... When the transaction has completed the done bit is set, the source address is as expected (start + 10).

I built a small standalone test to demonstrate the issue: https://pastebin.com/VqQSvJtG Which produces the output:

You can see that the bytes are sent every 300us as desired (top right) and that the values are 0,2,4,6,8 (bottom right) which is every other byte.

The examples I have for the 72MHz K10 don't have anything that does periodic DMA triggering.

Since the DMA works fine without periodic triggering, and the PIT works fine in interrupt mode, I can only assume that the issue lies in the dmamux peripheral, but that literally only has one register per channel. And since it works without periodic triggering, the source and the enable bits are correct. Since periodic triggering does do something, it can't just be that this feature isn't supported on my chip.

I've seen errata issue e4588, which sounds similar, but it specifically states using the "always on" source, which I'm not using.

I think the obvious work around is to change the source to a timer (one of the FTMs), since if I set the timeout sufficiently high so that the UART will definitely be idle by the time the timer expires, then I don't particularly need to use the UART as a source. I would however prefer to avoid this if there's a simple fix, since it would require changing existing code in a way that would affect other products.

Any suggestions?

Thanks,

Andrew

[andrewparlane]

Hi Mark,

Thanks for the reply.

That certainly sounds familiar, although there are definite differences (The MK10 doesn't have cycle steal and it's my source address that's incremented by 2).

I have tested that the workaround of using an FTM does fix things, but it's not ideal as it would require a decent bit of reworking of the code, since some of our other products that use this don't have any other suitable timers to spare. Not the end of the world though.

Thanks again,

Andrew

[mjbcswitzerland]

Hi

Your issue rings some bells with me. When I developed the uTasker DMX512 + RDM module for the Kinetis parts I also needed to implement gaps between transmission (otherwise some on-the-market DMX devices are known not to operate correctly if there is no inter-character space). I also use DMA for transmission and reception and the PIT to control the inter-gap tx spacing:

                 https://www.utasker.com/docs/uTasker/uTasker_DMX.pdf

I found that it worked well on some Kinetis parts but others would generate two DMA transfers per PIT trigger. This is a known issue in masks 1N97F, 2N97F (maybe others) where it is referenced as errata 5746. I certainly had the problem myself when testing on a KL25 part but maybe it is an issue in other parts - possible not being officially entered as errata since the mask erratas are not always 100% complete (?)

On certain other parts that essentially worked there is a double DMA transfer on the very first PIT trigger only (which can be worked around by sending a dummy frame on power up) and I believe I reported this in a post here a number of years ago (it was as if there was a pending DMA trigger when the PIT module was enabled, even though it hadn't yet fired for the first time).

Basically it is best to be flexible with the timer(s) used so that a different one (such as FlexTimer or TPM as you suggest) can be swapped in since some HW funnies may be built into the chips.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements