Parallel signaling using fsmc

[MDrac.1]

Okay so I'm trying to use FSMC in order to control 16 bitlines and a (custom) clocksignal for driving multiple LED drivers. (the final goal see "data-signal")

My first goal was to be able to drive the 16 bitlines, this works as expected. (see "without-adr")

Then I tried to generate a clock-signal using the address pins (using fsmc_adr). This however causes some weirdness at the datalines and the clock-signal is also not as clean as I'd have hoped. (see "with-adr")

I measured the following signals:

First 4 datalines

D0: FSMC_DA0

D1: FSMC_DA1

D2: FSMC_DA2

D3: FSMC_DA3

Last 4 datalines

D4: FSMC_DA12

D5: FSMC_DA13

D6: FSMC_DA14

D7: FSMC_DA15

Address-lines

D8: FSMC_A16

D9: FSMC_A17

D10: FSMC_A18

D11: FSMC_A19

D12: AFSMC_20

D13: FSMC_A21

D14: FSMC_A22

D15: FSMC_A23

Can anyone give me some insight into how to control the address-lines (FSMC_A16-FSMC_A23)? Why does it affect the output from the data-lines?

PS: I've added my current settings for the FSMC block (see "fsmc-settings")

EDIT: using the STM32F407 discovery board

github

[waclawek.jan]

IMO you misunderstand the function of FSMC.

Why don't you simply output the values onto pins set as GPIO Out?

JW

[MDrac.1]

Well mainly because there are 16 lines+clock that need to be controlled, at a pretty high frequency (>1MHz, higher is better).

I've looked at SPI/I2S and as far as I'm aware it only works when there is only a limited amount of lines.

Then I saw this and I've decided to try using FSMC.

In the next stage I want to combine FSMC with DMA for a quick and efficient execution that doesn't overload the uC.

[waclawek.jan]

Which STM32?

The link you gave starts with

Address generation will be disregarded, as well as other control signals dedicated to memory chips.

and says this for a reason.

So, use 17 FSMC data pins, toggling the 17th pin for clock. That may work, but there's no guarantee the controller won't insert unexpected states in between the writes, running your bit pattern. Simply, FSMC is not intended to work in this way.

I personally would DMA onto a whole GPIO port, triggered from a timer, while providing the clock signal from one of the timer's channels.

JW

[MDrac.1]

Which STM32?

STM32F407 discovery board

So, use 17 FSMC data pins, toggling the 17th pin for clock.

So yes, this is what I'm trying to do, however as you said if I start to try to mess with the address pins it messes up the data-lines for some reason? (Remember I need 16 data-lines, so it's necessary to get the clock out through one of the FSMC_A pins).

That may work, but there's no guarantee the controller won't insert unexpected states in between the writes, running your bit pattern.

Hmm this is disappointing, so this is 'normal' behaviour then? This would mean I need to start looking at other ways to generate the clock signal.

I personally would DMA onto a whole GPIO port, triggered from a timer, while providing the clock signal from one of the timer's channels.

If the timer is triggered at a frequency of let's say 10Mhz wouldn't it clog up uC? (In the future I would need to be able to still use some cycles to read in data from an Ethernet connection, that's why I'm asking btw).

PS: I'll try the DMA->GPIO method tomorrow and see what results I get and report back

[waclawek.jan]

FSMC has 32 data lines - not on the QFP100 package, though. The Disco is not the best platform for this kind of experiment. Note, that many pins are connected to on-board circuitry, potentially colliding with your intentions.

Timer runs autonomously, without processor intervention.

10MHz may be at the upper edge of what's possible, especially having other processes on DMA or accessing the same memory will result in collisions. But you initially talked about 1MHz, that's 10x less, and that's a whole other story.

If you need to stretch the frequency, you have to resort to different hardware (FPGA).

JW

[MDrac.1]

Note, that many pins are connected to on-board circuitry, potentially colliding with your intentions.

Ok, I'll need to check this as well then.

Thanks for the help!

[MDrac.1]

Ok, so I got the DMA working.

For those interested, my upper limit for the data rate using DMA is 1.873Mhz. (see screenshot, D0->D14 are the datalines, D15 is the clock signal. The cause of the 'dips' are still unknown to me but for now I'm assuming this is due to using the disco board.)

One more question:

I saw that there is also something called DMA2D, which has a register-to-memory mode, could this be helpful towards improving the datarate (I assume reg-to-mem is faster than mem-to-mem?)

Next I might also try to take a look at FSMC again, I'll report back if I find anything useful.

PS: the code can be found at the github-link provided in the first post ("DMA stable" commit is my current setup)