FIFO Error from DMA to DAC caused by CubeMX - when can it be fixed?

[design23]

Posted on March 14, 2017 at 05:01

Fellow Programmers, STMicro Staff, and CubeMX Coding Team:

After a whole day of debugging, I found an error in CubeMX code generation that results in FIFO errors from DMA when streaming to DAC.  How soon can CubeMX be corrected?  It is a nuisance to edit the generated C file to fix the bug every time after CubeMX is used to generate new code again.

Here are the details:

(1)  DMA -> DAC normal trigger from any timer, with Interrupts enabled for DAC errors.

(2)  CubeMX generates file 'STM32F7xx_HAL_DMA.C' file, with line 486 setting the FIFO Error Interrupt Enable (which is a mistake) even though FIFO Mode is supposed to be disabled.

(3)  CubeMX Generated code looks like this ...

    /* Enable Common interrupts*/

    hdma->Instance->CR  |= DMA_IT_TC | DMA_IT_TE | DMA_IT_DME;

    hdma->Instance->FCR |= DMA_IT_FE; // Mistake - Always enable FIFO Error contradicting FIFOMode setting

(4)  Generated code should be like this ...

    /* Enable Common interrupts*/

    hdma->Instance->CR  |= DMA_IT_TC | DMA_IT_TE | DMA_IT_DME;

    if (hdma->Init.FIFOMode == DMA_FIFOMODE_ENABLE)  // If FIFOMode enabled

    {

        hdma->Instance->FCR |= DMA_IT_FE;  // Only enable FIFO Errors if FIFOMode enabled

    }

(5)  With this CubeMX code-generation error, I have to ask why is the hardware even generating an error since the FIFOMode has been set to disabled? Where does this FIFOMode change the hardware operation?

(6)  Does this mean that FIFO errors will always occur when FIFOMode is required to be enabled? 

I think there is a hardware problem here as well.  Please confirm what is going on.

Thanks,

Garry Anderson.

[Imen.D]

Posted on March 21, 2017 at 14:12

Hello,

I will share your issue internally with CubeMx team for check and we come back to you as soon as possible.

About hardware problem, you can check if you have the same conditions in the errata sheet related to your device.

Imen

[Peter Olsson]

Posted on November 22, 2017 at 08:59

Hi Imen,

Any progress on this? We're also seeing a similar issue when using DMA for UART TX (with no FIFO enabled). When disabling DMA_IT_FE everything works as expected. Is that the right way to do it?

What I can't understand is how a UART TX DMA could ever trigger a FIFO error. Even if the DMA is busy for a long time, it should just send the data when possible, there should never be any errors involved here? On RX I can understand, but not TX.

It seems that it's especially sensitive to this issue if calling HAL_UART_Transmit_DMA() directly inside the HAL_UART_TxCpltCallback() callback. I'm not sure why this would make any difference though.

/Peter

[Tesla DeLorean]

Posted on March 21, 2017 at 15:52

>>How soon can CubeMX be corrected?

It is generally unwise to set critical path requirements on third-parties, especially unpaid ones, they tend to have their own time lines and agendas. The tools have been in the process of being 'corrected' for several years now.

I would suggest sandboxing your stable design, and merging in changes if you use CubeMX in an iterative fashion

[askari.nima]

Posted on October 11, 2017 at 10:43

I have This Problem.

[Pevy.Andy]

Posted on October 12, 2017 at 13:22

Use a little sed script that is called before the build or manually just after you regenerate the code that rewrites the relevant lines.

Install a sed tool from somewhere out there in net land...

Put the following in a file called dma.sed

's/hdma->Instance->FCR |= DMA_IT_FE;/if (hdma->Init.FIFOMode == DMA_FIFOMODE_ENABLE) { hdma->Instance->FCR |= DMA_IT_FE; }/g'

Create a batch file containing::-

rename

STM32F7xx_HAL_DMA.C

STM32F7xx_HAL_DMA.C

XX

path to sed -f dma.sed

STM32F7xx_HAL_DMA.C

XX >

STM32F7xx_HAL_DMA.C

del

STM32F7xx_HAL_DMA.C

XX

Run it after a regenerate.

I have a number of these 'Fixes' in my codebase...

Andy

[Daniel Studer]

Posted on October 30, 2017 at 11:30

Hello,

Is there any reply from CubeMX Team yet?

I have the same problem, when i use the ADC and an SPI with DMA toghether. The SPI TX DMA has a high priority and ADC a low priority. If I use only SPI (ADC is not configured), everything is working correctly. But when I also configure ADC with DMA, the SPI DMA is getting the FIFO Error eventhough  FIFO is disabled at ADC and SPI.

By disabling FIFO Interrupt in function 'HAL_DMA_Start_IT' it works fine.

Dani

[Daan Lubbers]

Posted on November 10, 2017 at 09:54

Thanks! This solved my problem as well. I kept getting the FIFO error even though fifomode was disabled. I fixed it by adding the following line after HAL_ADC_Start_DMA

// Start ADC1 with DMA

if(HAL_ADC_Start_DMA(&adc_handle, (uint32_t*)adc_values, 16) != HAL_OK) {

    printf('error hal_adc_start_dma');

}

// Manually disable fifo interrupt.

dma_handle.Instance->FCR = 0U;

[Cyril FENARD]

Posted on May 04, 2018 at 12:40

Hi

Anderson.Garry

‌,

As reminder, the following is part of RM0431 Reference manual, 'STM32F72xxx and STM32F73xxx advanced Arm®-based 32-bit MCUs'

...

In direct mode, the FIFO error flag can also be set under the following conditions:

• In the peripheral-to-memory mode, the FIFO can be saturated (overrun) if the memory

bus is not granted for several peripheral requests.

• In the memory-to-peripheral mode, an underrun condition may occur if the memory bus

has not been granted before a peripheral request occurs.

...

Note: When a FIFO overrun or underrun condition occurs, the data is not lost because the

peripheral request is not acknowledged by the stream until the overrun or underrun

condition is cleared. If this acknowledge takes too much time, the peripheral itself may

detect an overrun or underrun condition of its internal buffer and data might be lost.

Disabling FIFO error is going to prevent from being informed of underrun.

Before doing this, please may you check that the stream priority of the DMA is enough high.

As information, development team fed back that it is planned in next deliveries (end of the year):

- FIFO error will be de-activate as default configuration in interrupt mode

- a new service will be created to set DMA_IT_FE in hdma->Instance->FCR, if one wants to be informed of such errors.

Hopping it clarifies and may you confirm this thread is completed.

Regards.

Cyril

[design23]

Posted on May 05, 2018 at 06:00

Hi Cryil:

Have you considered that the DAC is being driven by DMA Peripheral, therefore “underrun� or “overrun� is impossible, unless the hardware design is faulty.

So please have your development team try to figure out how the FIFO error can even occur with DMA as the controller. Either the DMA is faulty or the DAC is faulty.

Thanks,

Garry.

[Tesla DeLorean]

Posted on May 06, 2018 at 02:05

I would agree the answer doesn't really address the issue you posed.

A Validation Engineer needs to review the issue, and a CubeMX Engineer needs to understand why the code doesn't behave in a normative manner as generated, and limit the options or code generation to things that are going to work properly and consistently. We need significantly more rigour to what is tested and released. The CubeMX software should be aware of all the nuances described in the Reference Manual.

Does the DMA to DAC work properly?

Does it generate a FIFO Error Flag in normal operation, if so why?

Does ignoring the FIFO Error mask a deeper underlying issue?

Is there an issue with the address of the source data?

[Synthetech]

I am so glad I found this!

I am just now tinkering around with these uC's...

I was trying for a few days to get a simple DMA triggered DAC project going with either a F407VET6 or a H7 Nucleo board.

Using STM32CubeMX Version 4.27.0

used this fella's example

http://elastic-notes.blogspot.com/p/blog-page_1.html

I had no luck getting DMA to work with just Direct DMA transfer (FIFO disabled in the Cube..)

I could get the DACs to work with the basic HAL_DAC_SetValue usage, but everytime I tried to use DMA/TIM6 and HAL_DAC_Start_DMA with it it, would sit and do nothing. No output.

I am very new to debugging as well and perhaps it would have indicated to me long ago this issue.

Anyway, to make things short.. I ended up ENABLING the FIFO("Use Fifo"), "Full" Threshold, "Single" Burst options on the cubeMx DAC/DMA configuration window and BAM!

It suddenly started to create Sinewaves from the preconfig'd array.

I tried the OP's fix, but all it did was cause a severe Make error in the DMA.o file (I guess that's what it was indicating to me..)

So I figured, if you cant beat them, join them and enabled the FIFO instead of fighting it.

Now I can move on with some tinkering.

But I figured I would drop my findings in here in case some other poor soul out there is frustrated like me.