Bug in generated STM32DMA class on newest version 4.17.0

[jimmii]

Hello

Just as an information; (@Alexandre RENOUX​ )

You added the function OSWrappers::taskYield() when using L8 images.

TaskYield() is called in the function setupDataCopy.

The problem: setupDataCopy is also called from ISR as you know, TaskYield() is not allowed to be called from ISR and you get Thread-Errors.

I think this should be fixed in the next release...

Cheers, Roman

[Romain DIELEMAN]

Could you see if the following process solves your issue ? I will update the Known Issues article in the documentation and write a post in the forum with it if it works for you.

• Navigate to your Users/<user name>/STM32Cube/Repository/Packs/STMicroelectronics/X-CUBE-TOUCHGFX/4.17.0/CubeMX/templates/Target folder
• Depending on your bit depth open the dma_XXbpp_implementation_tmp.ftl file (in your case dma_16bpp_...)
• Delete (or comment) the OSWrappers::taskYield() call in the while ((READ_REG(DMA2D->FGPFCCR) & DMA2D_FGPFCCR_START) != 0U) loop

while ((READ_REG(DMA2D->FGPFCCR) & DMA2D_FGPFCCR_START) != 0U)
            {
//                OSWrappers::taskYield();
            }

• Regenerate code from STM32CubeMX for your project.

The taskYield call should be gone now :thumbs_up:

/Romain

[jimmii]

Hi @Romain DIELEMAN​ , this workaround is working fine.

/jimmii

[Martin KJELDSEN]

I apologize for this bug. It's my fault. It's clearly stated in the cmsis os documentation that one should never call threadYield() from an ISR. Unfortunately, when using FreeRTOS (which we do through cubemx) the cmsis_os2 code checks if the function is being called from ISR and then does nothing.

/Martin