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 02:05

Thank you Mr. Clive. I believe I have enough foundation now to start experimenting, however, just to make sure I'm going in the right direction, I would appreciate it if you can elaborate more on the following:

- DREQ of my ASIC is used to feed the input/capture TIM channel?

- As per the datasheet, DREQ has to stay asserted (HIGH) until the FIFO empties or fills, and each DACK received indicates an end of frame or successful transmission of data. On page 15 of AN4666, a TIM used for detecting end of transmission. How the DACK is utilized in such a scenario?

Thank you for your excellent follow up! 

Zaher

[Tesla DeLorean]

Posted on January 11, 2018 at 02:22

The STM32's really don't support that type of signalling, you will likely need to gate externally to generate multiple pulses, or use some more bus like transaction via FSMC/FMC interface.

It might be possible to use TIM1/TIM8 in a one-pulse with repetition count mode, but that won't work if the word depth is variable.

[Zaher]

Posted on January 11, 2018 at 14:08

Could you please show me an example on how to configure the DMA to use a memory mapped on the FSMC bus as the destination/source of the transfer? And what do you mean by 'variable word depth'? Is that still applies to 8-bit access of memory?

** update **

I'm generating my project configuration from CubeMx, so it would help a lot if you can provide an .ioc project, or example on how to configure it from within CubeMx. Do I have to create two streams/channels for each direction like this: Periph-to-Mem, Mem-to-Periph? Also, in the 'x-cube-paral-com' demo package, there are two different versions created, one for transmit with GPIO configured as output, and the other for receive, with GPIO configured as input. I'm a little bit confused here! 

[Tesla DeLorean]

Posted on January 11, 2018 at 16:27

Really can't provide support on the CubeMX front.

The FSMC/FMC memory would typically be in the 0x60000000,0xC0000000,0xD0000000 regions, for FPGA/ASIC's likely the former.

Memory-to-Memory would be on DMA2, you'd need to select the source/destination and directions as needed.

The variable word depth relates to how deep the FIFO depth is in a given instance, you indicate the DREQ is modulated by the FIFO, and presumably the number of bytes/words in there is not guaranteed to be consistent, ie variable. You might need a CPLD, or some logic, to cause DREQ to pulse requests, because the STM32 really isn't geared to the DRQ/DACK model of external DMA, and needs a request per transfer.

[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/) isinactive, and is released on the leading edge of DACK/. DREQ remainsasserted 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