F7 bare metal ADC+DMA won't work with ugfx

[Ivan.L]

Hello!

I can't get the adc to work using dma. The code works perfectly without ugfx initialization. But as soon as I initialize it the dma stops working. I can get a maximum of 1 reading from it.

Perhaps it is somewhat related to the GADC module of ugfx? But I didn't enable it in the config... 

Any suggestions on what could I do?

[inmarket]

The STM32LTDC gdisp driver by default uses DMA. Perhaps there is a conflict there. Some drivers that use DMA support a config variable or have a setting in the driver config file that specifies whether dma should be turned on. I can't remember off the top of my head if the stm32ltdc driver has such a flag but you can check in the source code.

This won't have anything to do with GADC.

[Joel Bodenmann]

Definitely unrelated to the GADC module as @inmarket already mentioned. It is likely due to a DMA stream collision (if your ADC peripheral has been set-up to use the DMA as well). It has been a long time, I really can't remember which DMA stream the STM32 LTDC driver uses (or even if at all) but you should be able to check the sources and then use a different DMA stream for your ADC.

If you say that "it stops working", does that mean that just the DMA halts or do you experience a hard-fault or some other from of crash? As in: Does the CPU keep working and it's just the DMA that gets stuck?

[Ivan.L]

Looking into the ltdc drivers I only see the use of dma2d. 

It is just the dma that halts. The cpu keeps working and even the gui updates fine.

[Ivan.L]

Just changed from stream 0 to stream 1 and it started working. But now there is a problem that the dma gets the data from adc only when something on the screen updates. Everything else seems to work fine.

[cpu20]

Are you sure you aren't experiencing cache coherency problems as described here?

I've ran into this problem several times already on the M7-platform and it's a pain in the *** to debug the problem. But the fact that your data on the screen must update first before you see the DMA transfer happen is probably because the data from the ADC is then removed from cache and replaced with that from the screan. The cpu will look at the data in the RAM directly. Thats what I think happens. But it is probably more complex is the cache is set assosiative.

[Ivan.L]

21 hours ago, cpu20 said:

Are you sure you aren't experiencing cache coherency problems as described here?

I've ran into this problem several times already on the M7-platform and it's a pain in the *** to debug the problem. But the fact that your data on the screen must update first before you see the DMA transfer happen is probably because the data from the ADC is then removed from cache and replaced with that from the screan. The cpu will look at the data in the RAM directly. Thats what I think happens. But it is probably more complex is the cache is set assosiative.

How can I check it? If looking at the array that the dma fills I see only the data from the adc without anything that could be from the screen. 

 

If I understand correctly ugfx doesn't use the sdram default and I should manually enable it. Won't it solve my problem? 

[cpu20]

37 minutes ago, Ivan.L said:

If I understand correctly ugfx doesn't use the sdram default and I should manually enable it. Won't it solve my problem? 

It has nothing to do with what type of RAM or which part of the RAM you are using. The MCU will cache any frequently used data from any part of the memory.

38 minutes ago, Ivan.L said:

How can I check it?

The easiest way to check if this is the problem, is to invalidate the buffer you are using for the DMA transfer. If this is the problem, you will see the data appearing in your buffer immediately after you invalidate it.
Note that the data you see in your debugger is the data the CPU sees and not the data that is currently present in the RAM. So in your debugger you will see the cached memory.

[Ivan.L]

2 hours ago, cpu20 said:

It has nothing to do with what type of RAM or which part of the RAM you are using. The MCU will cache any frequently used data from any part of the memory.

The easiest way to check if this is the problem, is to invalidate the buffer you are using for the DMA transfer. If this is the problem, you will see the data appearing in your buffer immediately after you invalidate it.
Note that the data you see in your debugger is the data the CPU sees and not the data that is currently present in the RAM. So in your debugger you will see the cached memory.

So I just tried invalidating the buffer. No data appears in it until the screen updates.

[Ivan.L]

Just solved my problem. 

I didn't really understand what invalidating ment. Now I copied the dmaBufferInvalidate() function from chibiOs and use it before reading the data. It works fine this way.

Thank you!

[laksonobufi]

On 14/08/2017 at 00:42, Ivan.L said:

Just solved my problem. 

I didn't really understand what invalidating ment. Now I copied the dmaBufferInvalidate() function from chibiOs and use it before reading the data. It works fine this way.

Thank you!

hai, i have same problem with u when i use DMA interrupt to do aquire data ADC external with spi, interrupt doesnt show up. can u tell me step by step?