FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE workflow and issues

Dave Nadler
Lead

‎2020-01-10 09:32 AM

For a customer, I needed to write up our workflow for using STM32CubeIDE, especially all the steps required to work around assorted issues in CubeMX, HAL, LL, and CubeMX-generated glue code. I'd appreciate any comments, especially if I missed anything. Perhaps others will find this useful!

Thanks in advance for any (constructive) comments,

Best Regards, Dave

http://www.nadler.com/backups/20200111_draft2_STM_Cube_Issues_and_Workflow.html

2 REPLIES 2
berendi
Principal

‎2020-01-10 01:11 PM

The best workaround is not using them at all.

As soon as HAL doesn't do what you want, stop using it. Saves countless hours of debugging efforts. Rewrite everything as soon as you can using the register interface.

  • The register interface is documented, HAL isn't. The one liner function descriptions are a joke.
  • The register interface has less bugs, and changes less often than HAL. It's set in silicon after all.

Maintainability

  • Lacking proper documentation, finding out what a HAL function call does involves digging through multiple layers of code, following defines to arrive at the CMSIS definitions, which are searchable in the reference manual.

Random collection of bugs I've encountered recently:

  • DMA not working in generated code, crops up almost daily on the forum.
  • Some clocks are not enabled, or the frequency is off by 10%. No link, happened at work on a H743. Leave the MCO pin(s) free and accessible with a scope probe.
  • Timer trigger input pin set as output. Can be dangerous.
  • Hardcoded delays all over the place, ETH and USB being the worst offenders.
0 Kudos
Dave Nadler
Lead

‎2020-01-10 01:26 PM

I wrote drivers for DMA, SPI, some timer stuff because HAL/LL stuff was unworkable.

Really, prefer not to write a USB stack or Ethernet drivers - this stuff really should work!

To add to your list:

  • F4 USB driver calls malloc within ISR
  • F4 USB drops sometimes drops 64-byte packets (transmit )
  • F4 USB has multiple redundant structures with pointers back and forth, and non-performant code with multiple unneeded layers
  • F4 USB improperly integrated with OS (FreeRTOS or anything using CMSIS interface)

LwIP integration has also been a bit fraught; STM http stuff doesn't seem to work so I redid it.

Aaarrrgggg....

0 Kudos
Top