Kill break warnings

[Bob-the-Kuhn]

"(void)(tmpreg);" is causing a lot of compiler warnings which is making it hard to see if there are any real problems.

warning: conversion to void will not access object of type 'volatile uint32_t {aka volatile long unsigned int}'

As best I can tell there is not a functional need for this variable.

---

I am using PlatformIO to compile. The GCC library JSON says:

{
    "description": "gcc-arm-embedded",
    "name": "toolchain-gccarmnoneeabi",
    "system": [
        "windows",
        "windows_amd64",
        "windows_x86"
    ],
    "url": "https://launchpad.net/gcc-arm-embedded",
    "version": "1.70201.0"
} 

[fpistm]

Hi @Bob-the-Kuhn
We avoid as far as possible to modify the HAL and CMSIS codes else it is hard to maintain those changes across update. There is some patches to fix real errors but unfortunately like your PR is only for a warning I will not merge it.
I understand it is really annoying.

The best way is to open an issue to all impacted repo in the STMicroelectronics GitHub organization:
https://github.com/STMicroelectronics

Like this this will be fixed properly and we benefits here also.

For CMSIS files:
https://github.com/STMicroelectronics/cmsis_device_f1
https://github.com/STMicroelectronics/cmsis_device_l1

For HAL/LL Drivers:
https://github.com/STMicroelectronics/stm32f0xx_hal_driver
https://github.com/STMicroelectronics/stm32f1xx_hal_driver
https://github.com/STMicroelectronics/stm32f2xx_hal_driver
https://github.com/STMicroelectronics/stm32f3xx_hal_driver
https://github.com/STMicroelectronics/stm32f4xx_hal_driver

Or in the STM32Cube which include both:
https://github.com/STMicroelectronics/STM32CubeF0
https://github.com/STMicroelectronics/STM32CubeF1
https://github.com/STMicroelectronics/STM32CubeF2
https://github.com/STMicroelectronics/STM32CubeF3
https://github.com/STMicroelectronics/STM32CubeF4
https://github.com/STMicroelectronics/STM32CubeL1

[ABOSTM]

Hi @Bob-the-Kuhn ,
As per reference manual,

Bit 12 BKE: Break enable
This bit enables the complete break protection (including all sources connected to bk_acth
and BKIN sources, as per Figure 196: Break and Break2 circuitry overview).
0: Break function disabled
1: Break function enabled
Note: This bit cannot be modified when LOCK level 1 has been programmed (LOCK bits in
TIMx_BDTR register).
Note: Any write operation to this bit takes a delay of 1 APB clock cycle to become effective.

To guaranty the APB clock cycle, driver perform a Read operation READ_REG. With the code you proposed, the result of read is not used, and the compiler may optimize it by removing associated the code. This is the reason why it is needed to put the result in volatile variable (__IO means volatile) and make a fake use of this result, to prevent compiler optimization.

  __IO uint32_t tmpreg;	
  SET_BIT(TIMx->BDTR, TIM_BDTR_BKE);
  /* Note: Any write operation to this bit takes a delay of 1 APB clock cycle to become effective. */
  tmpreg = READ_REG(TIMx->BDTR);
  (void)(tmpreg);

[fpistm]

Thanks @ABOSTM for this explanation. I was not aware of this.

[Bob-the-Kuhn]

I knew there had to be a good reason for the __IO and tmpreg. Keeping the needed read operation from being optimized out did not occur to me.

---

I'm wondering if there are alternatives to guarantee the delay. How about:
REPLACE
tmpreg = READ_REG(TIMx->BDTR);
WITH
((uint32_t volatile)READ_REG(TIMx->BDTR)); // volatile guarantees this read is not optimized out

[uzi18]

You should report it one level higher like @fpistm mention, in other way one need to fight with it every stm libs update.

[Bob-the-Kuhn]

I'm uncertain as to how to proceed.

From the text above it sounds like I should go through all the listed repositories and open an issue in each of them. Do NOT open a PR.

But ... it appears that there have been almost zero issues or PRs opened against the listed repositories. To me that implies that requests for changes from the user community usually go through a different channel. What is the preferred method of asking for code changes?

[fpistm]

You could file an issue this will be take in account.
As said you can file it in one of the STM32Cube repo.

https://github.com/STMicroelectronics/STM32CubeF0
https://github.com/STMicroelectronics/STM32CubeF1
https://github.com/STMicroelectronics/STM32CubeF2
https://github.com/STMicroelectronics/STM32CubeF3
https://github.com/STMicroelectronics/STM32CubeF4
https://github.com/STMicroelectronics/STM32CubeL1

and mention it is the same in other STM32Cube.
The fact some of the repo has no issue doesn't means it will not be handled.