Is there a way to disable DMA related code with HAL_DMA_MODULE_ENABLED

[StevenG]

I have a project using the STM32L031.  It's fairly simple and doesn't require DMA, probably doesn't even need interrupt processing (polling should be fine for what little UART traffic is planned).

Is there a way to configure the project in STM32CubeIDE / CubeMX to not have HAL_DMA_MODULE_ENABLED active in the stm32l0xx_hal_conf.h file?  Just commenting it out causes a lot of breakage in the rest of the HAL libraries. 

I am using UART, SPI, and I2C interfaces.  I would rather use the Flash space for text-based error messages than DMA code I will never call but I don't want to hack up the HAL library if there is a "proper" way to disable the DMA related code.

I currently have 22kB of the 32kB in the part used but the HAL library is probably about 16kB of that.  I am not using a real-time supervisor (no FreeRTOS or ThreadX), just bare metal but with the HAL library.

[AScha.3]

What optimizer setting you use ?   (try -O2)

And if you dont use the dma, its away after optimizer...so dont worry about it.

[LCE]

I recently had the same problem with the same STM32.

HAL is too much for 32 kB flash...

I reduced "initial" code size by switching from HAL to LL in CubeMX (which I only use for basic setup), which you do in: 

Project Manager / Advanced Settings

Then also, as AScha.3 said, optimize for size.

You can check flash size of functions in the IDE in "Memory Details" (right besides "Memory Regions" in "Build Analyser", usually bottom right in IDE).

There you'll find that some ARM math functions take also a lot of space, so if possible stay away from divisions and multiplications.

[StevenG]

I have the files in Drivers\STM32L0xx_HAL_Driver\Src marked as "Exclude from build".  I have a pre-build step setup to compile all those files into a stm32lib.a library archive with the -Os optimization and the link step of the project includes this library.  My code has -O0 optimization to make it easier to step through during debug.

What I have noticed is that the list file created by objdump -S shows all the DMA related code is in the .ELF (and therefore .HEX) file. 

I do have the "-ffunction-sections -fdata-sections" options in the C compiler settings and the linking options have "-Wl,--gc-sections".

My hope was that the linker would only pull in the code actually referenced from the .a library as opposed to just including everything in the .o object files.

[StevenG]

So the code is finished but not yet debugged -- I'm waiting for the boards to arrive.  Here's some interesting info about the optimization settings:

	App code -O0	App code -Os
HAL Library -O0	Flash overflow by 3936 bytes	Flash overflow by 1056 bytes
HAL Library -Os	26 kB used	23.2 kB used

I wasn't expecting to run out of Flash on a 32 kB part but that is the risk when using the HAL library.  This application could have just as easily used a PIC or an 8-bit AVR but I am just more comfortable with the STM32 these days (having used them in different forms for the last 15+ years) and the tool set is a bit easier to acquire and use.

Primary takeaway:  Do not plan on using the HAL library in parts with less than 32 kB of Flash.  The LL library may be a viable alternative but the software effort is much higher without the HAL library.

[Pavel A. · Accepted solution]

>  Just commenting it out causes a lot of breakage in the rest of the HAL libraries. 

Correct. Other components that have DMA depend on the DMA include files. So DMA cannot be disabled in ...hal_conf.h.  But this won't pull in any DMA library functions unless the code actually uses them. No need to exclude anything from build.

For a 32 KB flash the HAL library is a bit (or rather few kilobytes) heavy, but DMA is not the culprit.

[AScha.3]

I dont agree with > Do not plan on using the HAL library in parts with less than 32 kB of Flash. <

The HAL needs some space , right, but just for the things you use.

Example : on a F030, 16KB flash, i made an "ambilight" for my TV, driving some (7m long) RGB light strips and reading the (average) picture color with an RGB-sensor over I2C.

Program is 7,2KB (-Os) and fits easily ; HAL here needs about 5,5KB , doing everything from RCC clock tree init to I2C functions. My "program" is just 1,5KB or so. (No floating point of course - that would be no good idea here.)

So if you want to know, what needs space, just look in:

-> details ->

...