STMCubeMX STM32F411RE MX_DMA_Init()

[Rob.Riggs]

Posted on March 10, 2015 at 01:47

I have created an STMCubeMX project for the STM32F411RE Nucleo board and it is going pretty well until I tried to use DMA.  I do not get very far because in no case does the MX_DMA_Init() function get created.  The function is declared at the top and called in main(), but it is never defined.  This happens whether I set up DMA for ADC1 or for UART2 TX or for both of them at the same time.

This seems like a fairly fundamental problem to be having.  Has anyone else encountered this or know of a solution?  I am running the standalone STM32CubeMX 4.6.0 with STM32F4 package version 1.4.0.  I am running this on Linux and generating source for TrueStudio 4.3.1.  (I am building on Eclipse with the GNU ARM Eclipse plugin.)

#stm32cubemx-hal-mx_dma_init

[stm32cube-t]

Posted on March 10, 2015 at 14:21

Hello,

We don't reproduce your issue (MX_DMA_Init declared and defined in main.c as soon as a DMA channel is configured). Please see MX configuration file .ioc attached and confirm it is working for you.

________________

Attachments :

F411RE_nucleo_test.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzOn&d=%2Fa%2F0X0000000bLF%2FClXfTBdEmbic0R1la2X3VqkaIaDQ0w0C5tPnXShklKE&asPdf=false

[Rob.Riggs]

Posted on March 12, 2015 at 02:35

This fails to generate properly on Linux.  The MX_DMA_Init() implementation is still missing from the generated code.

I tried this on OS X and it works fine.  The MX_DMA_Init() function implementation is generated properly.  This appears to only affect STMCubeMX on Linux.

I updated the JRE on Linux to match the version on OS X and the problem persists.  I verified the installations against each other.  The SHA checksums for the files match.

[Rob.Riggs]

Posted on March 13, 2015 at 20:51

I took it upon myself to look at this in more detail.

This appears to be a defect in STM32CubeMX.  It appears STM32CubeMX assumes that the target filesystem is case insensitive.  I see numerous places in the ''strace'' output when generating code where a file is opened as ''DMA.tmp'' and later as ''dma.tmp''.  This is the same file on Windows and OS X, but different files on Linux.

Adding to the evidence that this is the case, creating a loopback VFAT filesystem and generating code into that case-insensitive file system results in correct code on the same machine using the same .ioc file.  The only material difference is that it fails when the target filesystem is case sensitive and succeeds when the target is a case-insensitive filesystem.

Please test STM32CubeMX on a case-sensitive filesystem.

[stm32cube-t]

Posted on March 18, 2015 at 11:15

Thank you for this report. Issue will be escalated to our development team.