Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SAMD51(J19) revision F DMA issues with 2 identical TCCx trigger source #356

Open
flety-emmanuel opened this issue Mar 18, 2024 · 1 comment

Comments

@flety-emmanuel
Copy link

flety-emmanuel commented Mar 18, 2024

Fully documented here:
https://forum.microchip.com/s/topic/a5CV40000000b1BMAQ/t394578

TL;DR :
use case : TCCx timer set as PWM pulse train generator. DMA in charge of setting the duty cycle of the PWM channel at each new period, hence trigger source selected is TCCx-OVERFLOW. DMA channel writes new duty cycle in the TCCx[concerned channel & pin].CCbuf

Bottom line: in rev F of the silicon, if you allocate a dma channel and set it with a trigger source then allocate another channel with the SAME trigger source, first channel will never start its job and will not finish it. Triggering the SECOND one will eventually sometimes allow for the first channel, sometimes not. As soon as you revert the trigger source of the second DMA channel to another source, like another timer, different from the first channel timer, the first channel works correctly and triggers interrupts and such. Reverting can be done on the fly as code offers (by pressing a switch on a GPIO or shorting it) and first channel falls back in order.

Test code made to work with an itsty bitsy M4 and could be simply adapted to a M4 express with the exact MCU (51J19) using for instance pins D8 and D9 which feature the same TCC0 timer, on respective (timer) channels 1 and 0. The itsy M4 I ordered last week from adafruit are unfortunately rev D as well as my older M4 express I own. I tested that simple code on my custom board that uses a 51J19A-AU in TQFP format, using both D and F versions to compare and highlight the issue. F revision MCU were acquired from both microchip direct and mouser.

test_ledstrip_dma4-itsy.zip

@flety-emmanuel
Copy link
Author

flety-emmanuel commented Mar 22, 2024

For additional information : I did a MCU swap this morning on one of my lab's Metro M4 express using a SAMD51J19A (MU, QFN obviously) ordered at mouser 2 days ago. The 51J19 MCU is dated 2328 (july last year) and the issue described above with test code can be reproduced.

Microchip asked me about the markings and sent me back to the errata sheet which is related to rev A and D (for which DMA has been working properly, D rev at least, because I don't think I've ever had my hands on a rev A and my dev board from 2019 is rev D already). My working MCU are dated from 2051 but also 2307. The first batch of non working MCU (confirmed F via JTAG / Microchip studio) I got is dated 2319, just a few weeks later.

Problem can be reproduced therefore on both TQFP (AU) and QFN (MU) of the F revision of the silicon. I haven't been able yet to swap a 51G19A on an itsybitsy M4, but I might do that later today, they probably share a lot based on the errata sheet but it doesn't hurt to double check, plus adafruit wonderful M4 boards are concerned as they are the type of board you can ask a lot to (audio processing in particular) using DMA channels.

[addon] : swapped the 51G19 to F rev on a itsy M4, issue confirmed, chip mfg marking 2328 (k8p)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant