mspm0: add dma driver #4338
mspm0: add dma driver #4338
Conversation
|
I do have some experience with this DMA controller in a real application and I think your issue might be the software trigger. With an external trigger from the ADCs the single transfer mode works as expected. I have not verified this myself but I suspect that the software trigger just holds the trigger active and makes the transfer mode redundant given that I see no actual way to control the software trigger. |
|
Yeah it does feel like software triggering the dma doesn't behave right. If I set the destination to 4 bytes in single transfer mode 2 bytes are written as well. That doesn't match the idea of the software trigger letting the DMA run to completion. This feels like a hardware bug or the datasheet is too ambigious to answer? |
|
Hmm that is strange. Based on the software trigger behavior of the ADC I expected it to be similar. It does seem like a pathological case though. When would you use such a configuration in a real application? Perhaps it’s considered undefined behavior and just not documented very well like most of this series. |
Probably not practical to do single software triggered single transfers for an array of reads (basically using the CPU for memcpy with extra steps). Exhaustively testing the driver options is why that test case came to exist. |
|
Fair enough and that’s what I guessed was happening. The rest of the driver matches what I know of this module so I think it’s sound except for this one test case. |
i509VCB
force-pushed
the
dma
branch
3 times, most recently
from
66f19f4 to
1b03d0f
Compare
| } | ||
| } | ||
|
|
||
| // TODO: u128 (LONGLONG) support is available but not on every part number (do any currently released |
There was a problem hiding this comment.
Doesn't it say in the G3507 reference that it supports u128? Maybe I am wrong
There was a problem hiding this comment.
Okay so there is a target. I probably need to find some metadata info so that I can feature gate u128 transfers to parts that support it.
| let events = pac::DMA.int_event(0); | ||
| let mis = events.mis().read(); | ||
|
|
||
| // TODO: Handle DATAERR and ADDRERR? However we do not know which channel causes an error. |
There was a problem hiding this comment.
Am I correct that we need to handle this on the channel level, because of the way the chip raises the error?
So each channel would need to check the IIDX[j].STAT register individually?
There was a problem hiding this comment.
So the array access for int_event is selecting the "CPU event" interrupts. Index 1 for int_event is the GEN_EVENT group.
Looking at the STAT values (and it matches with INT):
We see that the DMA address and data errors do not specify what channel caused the error. We can be told of course when a channel finishes, but if an error happens we don't know which channel failed.
Add a DMA driver for mspm0. So far only implement features available on all (basic) channels. copying slices is also not implemented yet nor anything related to source/destination stride.
A few things pending before this is ready to reviewFigure out why(likely hardware bug)TransferMode::Singlewithdst.len() > 2performs 2 transfers instead of 1 (as expected in datasheet)Test multiple triggers (resume())