STM32F407 Memory to Peripheral (GPIO) Transfer with ext. DMA Trigger

[Zaher]

Posted on January 10, 2018 at 21:52

Hello everyone!

I had to postpone this for some time as I had reached a deadlock with the previous legacy ASIC I picked up for a project, and after spending some time researching my other options, I dropped that ASIC for a much better, relatively newer (not in today's terms) ASIC. 

Instead of a native DMA interface, my new device provides dual bus access to the chip. PAD[7:0] for access to internal registers, and DB[7:0] for DMA data-transfer transactions. I have interfaced the device with the FSMC peripheral of the STM32F407 and I can now read/write registers perfectly. 

So far, I have found a lot of interesting resources that I can build upon. AN4666 seems to be the solution to my problem on how to simulate a DREQ/DACK handshake. The solution provided by Mr. Clive on the following thread is a great starting point, too, to learn a lot from:

https://community.st.com/0D50X00009XkhgoSAB

 

Because I'm building my firmware based on the Cube/HAL libs, I believe this one has the best solution for my situation:

https://community.st.com/0D50X00009XkX2CSAV

 

However, I noticed that the GPIO has been configured as output for transfer from Memory (Buffer)  to GPIO. What if I want to receive data back from GPIO to the memory buffer, also utilizing the DMA and external trigger? By then, I will have to re-configure the GPIO before initiating the transfer transaction? 

Thanks,

Zaher

null

[Tesla DeLorean]

Posted on January 10, 2018 at 22:36

Need to use DMA2 on the F4 series, pick a trigger off a supported TIM, and use the TIMx_CHx in an input capture mode.

DMA can pick the direction of the transfer, so you can go either way (read or write), you can only use a single GPIO bank, use BSRR if you want to write a subset of pins within the bank.

[Zaher]

Posted on January 10, 2018 at 23:23

Although the interface provides a parity bit (9th bit), I will disable parity checking in the settings of the ASIC and use only an 8-bit access. In this case, I suppose a half bank GPIO is sufficient? And by the way, why BSRR and not ODR?

[Tesla DeLorean]

Posted on January 11, 2018 at 00:06

ODR writes all 16-bits so will change all pins, where as BSRR is a 32-bit write but you can selectively write bits within the ODR

[Zaher]

Posted on January 11, 2018 at 18:44

Yes, the ASIC is interfaced with the FSMC on BANK 1 (

0x60000000

) and I have no problem accessing all registers, including the 16-byte FIFO on chip. The FIFO maybe accessed by both of the microprocessor bus and the DMA bus. 

Well, reading through the different examples and replies provided so far on multiple threads on a similar topic, I thought my problem has been already solved, but I'm a little bit confused now. I can see that the STM32 arch doesn't support the DREQ/DACK mechanism out of the box, but with the aid of the mentioned tricks, I don't see why it's still not possible to do it? 

DREQ/DACK are just signals that have to be asserted/de-asserted at certain intervals and here I quote the ASIC's datasheet: 

The DMA Request signal (DREQ) is

asserted when the DMA is ready for a transfer to or from the DMA channel.

DREQ is asserted only when the DMA Acknowledge signal (DACK/) is

inactive, and is released on the leading edge of DACK/. DREQ remains

asserted until the chip receives as many DACK/s as it needs or can handle.

Where is the problem here to adopt that magic utilizing a TIM in input/capture mode? What I missed here? 

Please bear with me, as this is beyond the scope of the DMA usage you face on a day to day basis, especially on the STM32's. 

Thanks again,

Zaher