Bug or misleading documentation in XDMAC controller (at least SAME/V/S70)

1 post / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear all,


I'm still working to setup a XDMAC linked list to write to different addresses of different I2C devices on my custom board. Because I2C is far too slow to be ready for the next descriptor I set 'software request' for all descriptors instead of hardware request. The idea is that I will set this software request descriptor by descriptor (or better say block-by-block) to pace the execution. From the user manual I was sure that will work: Software Triggered Synchronized Transfer
The Peripheral hardware request can be software controlled using the SWREQ field of the XDMAC Global Channel
Software Request Register (XDMAC_GSWR). The peripheral synchronized transfer is paced using a processor write
access in the XDMAC_GSWR. Each bit of that register triggers a transfer request. The XDMAC Global Channel
Software Request Status Register (XDMAC_GSWS) indicates the status of the request; when set, the request is still


However, I realized that right after I enable the corresponding XDMAC channel the DMA transfer is started. It is not waiting for the SWREQ bit to be set. Even more strange, the unintended DMA transfer stops in my 3rd descriptor. If I now set the SWREQ bit it is continuing till the end.

Unfortunately I couldn't find any example in the internet that make use of the SWREQ bit for the XDMAC (only one example at ZephrOS if I remember correct that I think was buggy). There is a hint in some SAM5A github sources that this bit is not implemented. However, even for these devices there is nothing in the errata sheet that is confirming a bug on silicon level.

Anybody has experience with the SWREQ to pace the execution of a XDMAC linked list?

I will create a ticket at Microchip for this and will post their answer as soon I will get one.


Best Regards