Design Resource for development

[KGili.2156]

Hi STM32 Community,

I'm new to the STM32 MCU world, I have experience with other MCU's like, TI, Microchip, Cypress.

My main question is:

Where do I find all the necessary information for the development of a project with a typical nucleo board?

I designed a simple PWM test project and had to:

• search in UM1956 STM32 Nucleo-32 boards (MB1180) user manual for the pin mapping
• search in the STM32L432KC datasheet for a very poor description of the hardware Timers
• search in UM1884 Description of STM32L4/L4+ HAL and low-layer drivers how to use the hardware without a clear flow chart of init sequence ....
• search the RM0394 Reference manual to figure out the registers to adjust the PWM duty cycle, As the ST HAL does not provide a simple duty cycle adjust function

Am I missing something? is there a document which combines these as one clear reference manual?

So now I'm confused:

I started the PWM via the ST HAL

  MX_TIM15_Init();
  HAL_TIM_PWM_Init(&htim15);
  HAL_TIM_PWM_Start(&htim15, TIM_CHANNEL_2);

The I adjust the duty cycle via the register CCR2:

 if( ( htim15.Instance->CCR2 + PWMINC) > PWMPERIOD )
		  htim15.Instance->CCR2 = 0;
else
		  htim15.Instance->CCR2 += PWMINC;

any thoughts ?

[waclawek.jan]

> Am I missing something? is there a document which combines these as one clear reference manual?

You are talking about several different things - the mcu itself, a particular board embedding this mcu, and a particular "library" implementing a selected set of features of the mcu - which I don't quite understand why would be combined into one manual.

The splitting of mcu's documentation into DS and RM (and there's more, if you are really into it, the PM for the core and the related ARM documentation) has both historical and logistics reasons, following the common-to-specific hierarchical model - PMs describe the core common to several families, RM describe the programming details of peripherals within a family (or subfamily), DS decribe the specifics of individual models within the (sub)family (while only sketching out the peripherals' capabilities, as you've noted). Certainly, much of this material can be improved - and it ought to be augmented by an extensive set of ANs and clean examples, which is sort of neglected at the moment, as . However, these are the basic documents one who wants to seriously develop for these mcus should get familiar with.

The "libraries" such as Cube/LL (which is really a different thing from Cube/HAL) and the older SPL provide mostly just a rename of the native registers. Advanced "libraries" such as Cube/HAL inevitably implement only a subset of the many possible modes of usage of the hardware, the "most often used" features (that's the definition of HAL). You are supposed to click in CubeMX and/or CubeIDE, and look at the examples which come with the particular family's Cube (which are mostly not generated by CubeMX so you can't "import" them, there are some exceptions mostly with newer famiilies, and ST is working on this). "Libraries" come with their own documentation, most of it being the usual doxygen autovomit.

You can get Cube-centric tutorials as videos - search on youtube, ST's own or third-party - or you can get also books e.g. https://leanpub.com/mastering-stm32

If you desire more Arduino-like experience, you should perhaps look at mbed, or stm32duino.

As far as your particular problem goes, to change duty cycle of timer in PWM mode, you are probably supposed to use the __HAL_TIM_SET_COMPARE() macro, as witnessed also by examples like [CubeL4]\Projects\STM32L432KC-Nucleo\Examples\TIM\TIM_OCToggle (which if you asked me is more confusing than enlightening).

As you may've guessed by this time, I don't Cube.

JW

[Piranha]

For timers also look at AN4013 and AN4776.

> Am I missing something?

The fact that all firmware code - HAL, LL, SPL, CubeMX generated code and examples - are written by dumb code monkeys. Therefore it's full of bugs, bloated, inflexible and will never work reliably. Here is an example case of Ethernet. I started learning Ethernet and lwIP in year 2017, but ST hasn't been able to get it working since the launch of STM32F107 in year 2007! And with faster MCUs, especially Cortex-M7 based ones, it is getting worse. Even more - their developers are so incompetent, that they ar not even able to understand such non-trivial bug reports! But they will not fire them, because of western Idiocracy tolerance...

[RMcCa]

Part of the problem is that the chips are pretty complicated and (at least on my experience) pretty overwhelming at first. Despite all the bugs, i found cube quite useful for creating the initial eclipse project structure which made getting started a bit easier, especially the clock configuration.

​i also found as i spent more time with f7s and the RM data sheet that it's really not that different from the avr mega328 that i was used to, just more complicated. It's still just about setting/clearing the correct register bits.

Cube/hal can get you started, but i don't think there is anyway to avoid digging thru the RM and using the debugger to check register states.​