UART DMA

[9names]

Add DMA support for UART peripheral.
Tested with basic loopback example - works fine for single characters but explodes if you send many at once (you can reproduce this by holding a key, so it's not even that fast)

[9names]

Now it's not even doing as well as before - it either sends nothing or gibberish.

[9names]

Okay, the swapped dreq is what was causing the failures.
I think we're still not clearing some fault state on startup though - once things go weird they stay that way until the reset button is pressed.

[9names]

Yep, while this code works we're definitely hitting some DMA issues with it.
If you run the example from a hard reset it works fine.
If you then launch it again via probe-run, it stops at the first DMA write.
If you break, then then launch it yet again via probe-run, it starts spitting out the binary (which makes all my terminal programs very upset).

[9names]

We weren't resetting the DMA peripheral during init.
It worked the first time because the peripheral was in reset after hard-reset, but not after a soft reset.
The UART DMA demo now works reliably

[jannic]

We weren't resetting the DMA peripheral during init.
It worked the first time because the peripheral was in reset after hard-reset, but not after a soft reset.

IIRC probe-run doesn't reset the device after flashing, it just jumps to the entry point. This may be a bug in probe-run.

[9names]

All the other peripherals were already doing

self.reset_bring_down(resets);
self.reset_bring_up(resets);

on startup to ensure they're in a good state.

DMA and PLL are presently the only things that only do

self.reset_bring_up(resets);

[jannic]

All the other peripherals were already doing

self.reset_bring_down(resets);
self.reset_bring_up(resets);

Just a side note: I wonder if we need a way to skip this reset. After all, the watchdog can be configured to not reset the whole chip but only parts of it. There are probably applications where you'd want to keep some peripherals running when the watchdog fires.

For now, I'd prefer to keep things consistent and reset all peripherals on initialization. (PLL might be tricky - is it possible to get to that point while some clocks are already configured to run from PLL?)

[9names]

Just a side note: I wonder if we need a way to skip this reset

The C SDK and examples do not reset most of the peripherals, which suggests that this should be possible.
The only use-case I can think of currently is the dapper-mime 2nd core mode, where you need to avoid reinitialising the entire chip in order to keep core1 communicating via USB.

[ithinuel]

I think it'd likely also be nice to have it derive defmt when available.

[9names]

I should probably add more derives than that to the public-facing types too. Nice catch

[9names]

I updated this and the DMAError struct to use

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[cfg_attr(feature = "defmt", derive(defmt::Format))]