profile
viewpoint
Ali LABBENE ALABSTM STMicroelectronics Tunis https://www.st.com

STMicroelectronics/cmsis_device_f4 8

Provides the STM32Cube MCU Component "cmsis_device_f4" of the STM32F4 series.

STMicroelectronics/cmsis_core 6

CMSIS Core module, fully aligned with ARM versions.

STMicroelectronics/cmsis_device_f7 4

Provides the STM32Cube MCU Component "cmsis_device_f7" of the STM32F7 series.

STMicroelectronics/cmsis_device_h7 3

Provides the STM32Cube MCU Component "cmsis_device_h7" of the STM32H7 series.

STMicroelectronics/cmsis_device_g0 2

Provides the STM32Cube MCU Component "cmsis_device_g0" of the STM32G0 series.

STMicroelectronics/cmsis_device_g4 2

Provides the STM32Cube MCU Component "cmsis_device_g4" of the STM32G4 series.

STMicroelectronics/cmsis_device_l0 1

Provides the STM32Cube MCU Component "cmsis_device_l0" of the STM32L0 series.

STMicroelectronics/cmsis_device_l4 1

Provides the STM32Cube MCU Component "cmsis_device_l4" of the STM32L4 series.

STMicroelectronics/cmsis_device_l5 1

Provides the STM32Cube MCU Component "cmsis_device_l5" of the STM32L5 series.

STMicroelectronics/common 1

Provides the COMMON driver, part of the STM32Cube BSP Component for all STM32xx series.

issue openedSTMicroelectronics/STM32CubeL4

Add .IOC file

These example are very helpful, but all the .ioc files are missing. Is it possibile to have them?

Thank you!

created time in 3 hours

issue commentSTMicroelectronics/STM32CubeH7

Calling xQueueReceiveFromISR() from within Interrupt results in ASSERET trigger

Hello @ASELSTM ,

I observe concerns with FreeRTOS file GCC\ARM_CM4\port.c available with it. I am observing two ASSERTS / concerns in the file (triggered as a result of Reading from or Writing to a Queue from ISR):

It is observed that pxCurrentTCB->pcTaskName == "IDLE" for both the (software interrupt execution) cases:

First Issue: Is observed for configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); when variable uwTickPrio = TICK_INT_PRIORITY (either assigned directly or with help of variable TickPriority), where macro TICK_INT_PRIORITY is assigned a value of 0.

If I do not use a software interrupt to process the Queue, then because of uwTickPrio value (i.e. 0) being used as priority for FreeRTOS Timer (i.e. Timer 2), the ASSERT gets raised.

If I use the software interrupt, then I observe the second issue stated below

Second issue: Is observed for configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue ); especially when triggered software interrupts are being handled. The software interrupt is triggered by updating the related interrupt number NVIC->STIR

Additional observations and concerns:

  1. May you please help me understand whether TICK_INT_PRIORITY value is user changeable?
  2. Also should the NVIC_SetPriorityGrouping(4) or NVIC_SetPriorityGrouping(0) to be used? It is observed that HAL_Init() calls HAL_NVIC_SetPriorityGrouping(4), hence if the Priority Group is to be set to 0 then should NVIC_SetPriorityGrouping(0) called just after calling HAL_Init()?

Flow: SW_FroTimer_IRQHandler() triggered -> SW_FroTimer_IRQHandler() serviced -> calls third party library function -> Third part library calls function rvAddEventToInterruptEvents() which I've coded -> rvAddEventToInterruptEvents() triggers another software interrupt -> SW_IRQHandler() executes for good number of times and then suddenly the issue 2 occurs. Observation: pxCurrentTCB->pcTaskName == "IDLE"

My code has: // USART2 IRQ being used for software interrupt and is triggered from a third party library on which my code does not have any control. This execution is the result of execution of SW_FroTimer_IRQHandler() when reviewed in Call Stack. #define SW_Int_IRQn USART2_IRQn #define SW_IRQHandler USART2_IRQHandler

// This software interrupt is triggered from Timer 2 (which is used as the default FreeRTOS timer) #define SW_FroTimer_Int_IRQn SPI4_IRQn #define SW_FroTimer_IRQHandler SPI4_IRQHandler

below added to main() function:

			HAL_NVIC_EnableIRQ(SW_Int_IRQn);

			HAL_NVIC_SetPriority(SW_FroTimer_Int_IRQn, 6, 0);
			HAL_NVIC_EnableIRQ(SW_FroTimer_Int_IRQn);```

Inside `HAL_TIM_PeriodElapsedCallback()` below code is added:
```		if((htim->Instance == TIM2) && (nRTOSTimerAndFMCInit == nRTOSTimerAndFMCInitStatus))
		{
			CucHighMinusLowSystemTicks++;
			NVIC->STIR = SW_FroniusTimer_Int_IRQn;
		}```

The other piece of code that triggers the software interrupt is:
```void									rvAddEventToInterruptEvents
	(
		toTaskEventHandler	*		poTaskEventHandler
	)
{
	uint32_t u32IRQMasked;
	MvTraceTime;
	dvDisableInterrupts;
	{
		if (osOK != osMessageQueuePut(Q_EventHandlerHandle, &poTaskEventHandler, dDummyMessagePriority, 0 /* Do not use osWaitForever as IRQ is disabled */))
		{
 			// #DRA: #ToDo: add error handling here
			++u32EventHandlerErrorCounts;
			assert_failed((uint8_t*)__FILE__, __LINE__);
		}
		else
		{
			NVIC->STIR = SW_Int_IRQn; 
		}
	}
	dvEnableInterrupts;
	return;
}```

Is it possible for you to suggest some pointers on how to fix the issues.

Thanks
@rxa1031 
rxa1031

comment created time in 13 hours

IssuesEvent

issue closedSTMicroelectronics/STM32CubeL4

Question about emmc speed in stm32l4p5g-dk

Hello!

I'm bought new DK board that name STM32L4P5G-DK for testing Fatfs-eMMC example. ( https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Projects/32L4P5GDISCOVERY/Applications/FatFs/FatFs_eMMC_Standalone )

It works fine, but not the speed I expected. Almost datasheet saying that eMMC speed is more than 50MB/s. But real speed is 1MB/s in this example .... :(

I would like to know if there are other ways to improve the speed.

i check up this write/read time

for (counter = 0; counter< N_SIZES; counter++)
{
  if(f_open(&MyFile, "TEST_ACCESS_TIME.TXT", FA_CREATE_ALWAYS | FA_WRITE) == FR_OK)
  {

    /* Start timer counter */
    HAL_TIM_Base_Start(&htim);
    /* Write data to the text file */
     res = f_write(&MyFile, copy_start, data_sizes[counter], (void *)&byteswritten);
    /* Stop timer counter */
    HAL_TIM_Base_Stop(&htim);
    Access_time_us = __HAL_TIM_GET_COUNTER(&htim);
    print_spend_time_clock_write = Access_time_us /= SystemClock;
    read_bytes = byteswritten;
    __HAL_TIM_SET_COUNTER(&htim, 0x0);

    if((byteswritten > 0) && (res == FR_OK))
    {
      /* Close the open text file */
      f_close(&MyFile);

      /* Open the text file object with read access */
      if(f_open(&MyFile, "TEST_ACCESS_TIME.TXT", FA_READ) == FR_OK)
      {
        /* Start timer counter */
        HAL_TIM_Base_Start(&htim);
        /* Read data from the text file */
        res = f_read(&MyFile, copy_start, data_sizes[counter], (void *)&bytesread);
        /* Stop timer counter */
        HAL_TIM_Base_Stop(&htim);
        Access_time_us = __HAL_TIM_GET_COUNTER(&htim);
        print_spend_time_clock_read = Access_time_us /= SystemClock;
        read_bytes = byteswritten;
        __HAL_TIM_SET_COUNTER(&htim, 0x0);

        if((bytesread > 0) && (res == FR_OK))
        {
          /* Close the open text file */
          f_close(&MyFile);

          /* Compare read data with the expected data */
          if((bytesread != byteswritten))
          {
            Error_Handler();
          }
        }
      }
    }
  }

closed time in 2 days

fito-jaeuklee

issue commentSTMicroelectronics/STM32CubeL4

Question about emmc speed in stm32l4p5g-dk

This capture is Stm32l4p5g-dk built-in chip emmc data speed from datasheet. 스크린샷 2020-11-24 오전 9 42 03

fito-jaeuklee

comment created time in 2 days

issue openedSTMicroelectronics/STM32CubeL4

Question about emmc speed in stm32l4p5g-dk

Hello!

I'm bought new DK board that name STM32L4P5G-DK for testing Fatfs-eMMC example. ( https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Projects/32L4P5GDISCOVERY/Applications/FatFs/FatFs_eMMC_Standalone )

It works fine, but not the speed I expected. Almost datasheet saying that eMMC speed is more than 50MB/s. But real speed is 1MB/s in this example .... :(

I would like to know if there are other ways to improve the speed.

i check up this write/read time

`copy_start = (uint32_t )0x20002000; / Create and Open test files object with write access to measure eMMC read/write accesses */ for (counter = 0; counter< N_SIZES; counter++) { if(f_open(&MyFile, "TEST_ACCESS_TIME.TXT", FA_CREATE_ALWAYS | FA_WRITE) == FR_OK) {

    /* Start timer counter */
    HAL_TIM_Base_Start(&htim);
    /* Write data to the text file */
     res = f_write(&MyFile, copy_start, data_sizes[counter], (void *)&byteswritten);
    /* Stop timer counter */
    HAL_TIM_Base_Stop(&htim);
    Access_time_us = __HAL_TIM_GET_COUNTER(&htim);
    print_spend_time_clock_write = Access_time_us /= SystemClock;
    read_bytes = byteswritten;
    __HAL_TIM_SET_COUNTER(&htim, 0x0);

// printf("%ld\t%s\t%ld\t%s\n", Access_time_us,"us to write",byteswritten,"bytes");

    if((byteswritten > 0) && (res == FR_OK))
    {
      /* Close the open text file */
      f_close(&MyFile);

      /* Open the text file object with read access */
      if(f_open(&MyFile, "TEST_ACCESS_TIME.TXT", FA_READ) == FR_OK)
      {
        /* Start timer counter */
        HAL_TIM_Base_Start(&htim);
        /* Read data from the text file */
        res = f_read(&MyFile, copy_start, data_sizes[counter], (void *)&bytesread);
        /* Stop timer counter */
        HAL_TIM_Base_Stop(&htim);
        Access_time_us = __HAL_TIM_GET_COUNTER(&htim);
        print_spend_time_clock_read = Access_time_us /= SystemClock;
        read_bytes = byteswritten;
        __HAL_TIM_SET_COUNTER(&htim, 0x0);

// printf("%ld\t%s\t%ld\t%s\n\n", Access_time_us,"us to read",byteswritten,"bytes");

        if((bytesread > 0) && (res == FR_OK))
        {
          /* Close the open text file */
          f_close(&MyFile);

          /* Compare read data with the expected data */
          if((bytesread != byteswritten))
          {
            Error_Handler();
          }
        }
      }
    }
  }`

created time in 2 days

issue closedSTMicroelectronics/STM32CubeL4

const as much as possible

const should us as much as possible.

example 1: HAL_StatusTypeDef IRDA_SetConfig(IRDA_HandleTypeDef *hirda) could be modified to HAL_StatusTypeDef IRDA_SetConfig(IRDA_HandleTypeDef * const hirda)

this protect hirda to be modified inside the function.

example 2: uint32_t HAL_COMP_GetOutputLevel(COMP_HandleTypeDef *hcomp) could be modified to uint32_t HAL_COMP_GetOutputLevel(COMP_HandleTypeDef const * const hcomp)

this protect hcomp and the destination of hcomp to be modified inside the function.

example 3: HAL_StatusTypeDef HAL_DAC_SetValue(DAC_HandleTypeDef *hdac, uint32_t Channel, uint32_t Alignment, uint32_t Data); could be modified to HAL_StatusTypeDef HAL_DAC_SetValue(DAC_HandleTypeDef * const hdac, uint32_t const Channel, uint32_t const Alignment, uint32_t const Data);

please improve the library

closed time in 2 days

CanastraRF

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

Hi all,

We have reported your feedback to our technical committee and after discussion an update will be started soon to add the use of the const qualifier. We still cannot share a date for the moment due to the huge effort required for the different components. We will keep you informed.

All duplicated issues will remain closed. This one will be kept open to track the point.

With regards,

jrahlf

comment created time in 2 days

issue openedSTMicroelectronics/STM32CubeH7

STM32H7: Ethernet TX callback complete not called intermittently

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum

Describe the set-up

  • STM32H747I DISCO
  • gcc version 9.2.0 (zephyr-crosstool-NG 1.24.0.4)
  • This HAL version 1.8.0

Describe the bug Please refer to https://github.com/zephyrproject-rtos/zephyr/issues/29915 and https://github.com/zephyrproject-rtos/zephyr/pull/29944 To summarize, TxCpltCallback is not called all the time, and it appears to be related to some incomplete memory transactions. A fix is described in provided links: adding __DSB() to a certain line in this HAL and before/after the HAL_ETH_Transmit_IT resolves it, depending on compiler optimization level. However, adding the line in this HAL works in all cases.

How To Reproduce

  1. Zephyr ethernet driver waits for a semaphore from TxCpltCallback, but it never comes as the callback is never called. So it times out.

  2. Ethernet driver for stm32h7xx (stm32h7xx_hal_eth.c)

  3. Just transmit an ethernet package

  4. Follow the scenario in the provided links.

Additional context If you have a first analysis or patch correction, thank you to share your proposal.

Screenshots If applicable, add screenshots to help explain your problem.

created time in 2 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

It might break user code that uses function pointers against the API, but still that's not a reason not to make it const-correct.

I honestly I didn't see this one. Good point. Anyway as the API changes the major release is justified. Even if it takes a year until next major the ticket shouldn't be closed.

jrahlf

comment created time in 3 days

issue commentSTMicroelectronics/STM32CubeH7

The __STM32H7xx_CMSIS_DEVICE_VERSION macro in stm32h7xx.h is wrong

Already others have commented, I did not notice, sorry.

RobertoBenjami

comment created time in 3 days

issue closedSTMicroelectronics/STM32CubeH7

The __STM32H7xx_CMSIS_DEVICE_VERSION macro in stm32h7xx.h is wrong

Hello!

stm32h7xx.h line 106. #define __STM32H7xx_CMSIS_DEVICE_VERSION_MAIN (0x01) /*!< [31:24] main version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_SUB1 (0x09) /!< [23:16] sub1 version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_SUB2 (0x00) /!< [15:8] sub2 version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_RC (0x00) /!< [7:0] release candidate */ #define __STM32H7xx_CMSIS_DEVICE_VERSION ((__CMSIS_DEVICE_VERSION_MAIN << 24)
|(__CMSIS_DEVICE_HAL_VERSION_SUB1 << 16)
|(__CMSIS_DEVICE_HAL_VERSION_SUB2 << 8 )
|(__CMSIS_DEVICE_HAL_VERSION_RC))

The result of this macro will always be 0

Here is the correct version: #define __STM32H7xx_CMSIS_DEVICE_VERSION ((__STM32H7xx_CMSIS_DEVICE_VERSION_MAIN << 24)
|(__STM32H7xx_CMSIS_DEVICE_VERSION_SUB1 << 16)
|(__STM32H7xx_CMSIS_DEVICE_VERSION_SUB2 << 8 )
|(__STM32H7xx_CMSIS_DEVICE_VERSION_RC))

closed time in 3 days

RobertoBenjami

issue openedSTMicroelectronics/STM32CubeH7

The __STM32H7xx_CMSIS_DEVICE_VERSION macro in stm32h7xx.h is wrong

Hello!

stm32h7xx.h line 106. #define __STM32H7xx_CMSIS_DEVICE_VERSION_MAIN (0x01) /*!< [31:24] main version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_SUB1 (0x09) /!< [23:16] sub1 version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_SUB2 (0x00) /!< [15:8] sub2 version / #define __STM32H7xx_CMSIS_DEVICE_VERSION_RC (0x00) /!< [7:0] release candidate */ #define __STM32H7xx_CMSIS_DEVICE_VERSION ((__CMSIS_DEVICE_VERSION_MAIN << 24)
|(__CMSIS_DEVICE_HAL_VERSION_SUB1 << 16)
|(__CMSIS_DEVICE_HAL_VERSION_SUB2 << 8 )
|(__CMSIS_DEVICE_HAL_VERSION_RC))

The result of this macro will always be 0

Here is the correct version: #define __STM32H7xx_CMSIS_DEVICE_VERSION ((__STM32H7xx_CMSIS_DEVICE_VERSION_MAIN << 24)
|(__STM32H7xx_CMSIS_DEVICE_VERSION_SUB1 << 16)
|(__STM32H7xx_CMSIS_DEVICE_VERSION_SUB2 << 8 )
|(__STM32H7xx_CMSIS_DEVICE_VERSION_RC))

created time in 3 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

Hi @RKOUSTM,

As said by @atsju, adding const to function parameters does not break any API. It merely informs the caller that the function will not / cannot modify the callers' parameters.

It might break user code that uses function pointers against the API, but still that's not a reason not to make it const-correct.

@RKOUSTM , if you are worried about breaking user code, introduce a new major version of the API and encourage users to move to it, as I have previously stated. But please, do not close this issue. That would be a irresponsible move from your side.

jrahlf

comment created time in 3 days

issue openedSTMicroelectronics/STM32CubeF1

error LL_GPIO_SetPinPull() function behavior in LL_GPIO_Init()

hello!

I have used STM32CubeMX V6.1.0(STM32Cube FW_F1 V1.8.3) to generate STM32F103ZETx's gpio init code, and find that thegpio init function LL_GPIO_Init() will call LL_GPIO_SetPinPull(), even if when i set set pin as output mode.

That will cause a error set zero to GPIO->ODR, in such code:

LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_GPIOF);

LL_GPIO_SetOutputPin(GPIOF, LED0_Pin);

GPIO_InitStruct.Pin = LED0_Pin;
GPIO_InitStruct.Mode = LL_GPIO_MODE_OUTPUT;
GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_OPENDRAIN;
LL_GPIO_Init(GPIOF, &GPIO_InitStruct);

i think LL_GPIO_SetPinPull() shall be called only when the pin is setted to output mode.

created time in 3 days

issue commentSTMicroelectronics/STM32CubeL4

const as much as possible

Hi @Hish15 I think @CanastraRF refers to MISRA C++ Rule 7-1-1. From older thread I have seen it seems he requires to respect some safety standards and runs PC-lint. Having the code "good" from start requires less deviation documentation.

Hi @CanastraRF First let me say all agree of the the need for int16_t const * var. Second I suppose ST will follow same idea as CMSIS issue. This means respecting MISRA-C for C code and not writing any int16_t const var. You are referring to 2 different MISRA rules (without pointing them out) so this could be treated as 2 different issues.

Regards, atsju

CanastraRF

comment created time in 3 days

issue openedSTMicroelectronics/STM32CubeL4

cast pointer to a bigger data is danger

Dear Support In different functions you cast a uint8_t* to uint16_t* or uint32_t*. This can result in a hardfault.

Examples from stm32l4xx_hal_spi.c:

HAL_StatusTypeDef HAL_SPI_Transmit(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
…
      hspi->Instance->DR = *((uint16_t *)hspi->pTxBuffPtr);
…

pTxBuffPtr can point to an odd or even address. With a odd address a hardfault is generated. So please handle this correct.

created time in 4 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

@RKOUSTM Dear Support I add const to your API every time a new release is available. So I can share my modification if you like.

jrahlf

comment created time in 4 days

issue commentSTMicroelectronics/STM32CubeL4

const as much as possible

Dear Support

Const not always break the API. An argument can always convert to const but not back. void foo(int i); and void foo(const int i); result in the same code. This is also true for void foo(handle * h) and void foo(handle * const h) But the improvement with const is that h cannot modify by mistake.

void foo(handle * const h)
{
	h++;	//Compiler report an error
	(*h)++;	// is possible
}

So, most of pointer should not modified at all. There is a difference between void foo(handle * const h) and void foo(handle const * const h) A get function should not modify the object. With (handle const * const h) the compiler can protect this. A set function should modify the object. With (handle * const h) the compiler can check this. The improvement of (handle const * const h) is also that a literal can be assigned. Example HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout); Here an Object from flash cannot transmit directly. It must first copy to Ram. HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef * const huart, uint8_t const *pData, uint16_t Size, uint32_t Timeout); huart is no protected from modify by mistake. pData can now be in Flash. Most of time the arguments are copied to internal data in huart. So, the API can change to HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef * const huart, uint8_t const * const pData, uint16_t const Size, uint32_t const Timeout); Without any API break. So please add const to all pointer that should not modified at all. Also add const to object in transmit function to allow transmit object from flash. Thanks Reto Felix

CanastraRF

comment created time in 4 days

issue commentSTMicroelectronics/STM32CubeL4

const array inside functions should be static

Dear Support Thanks for your explanation.

If the constant will be the same every time the function is called, use static const.

All my sample are from this case. So please add static in this case.

So I hope this is fix in next release.

You can close this case.

With regards,

CanastraRF

comment created time in 4 days

issue commentSTMicroelectronics/STM32CubeL0

__HAL_RTC_TAMPER_GET_IT() fail

Thanks

CanastraRF

comment created time in 4 days

issue openedSTMicroelectronics/STM32CubeF1

Conflicting types in USBD_LL_Transmit and USBD_LL_PrepareReceive

Describe the set-up STM32F103C8T6 Microcontroller. Initialization code generated with STM32CubeMX. USB configured as Device CDC Class. When generating the code "add necessary files as reference" checked, that is cube does not copy the libraries into the project folder.

Describe the bug In usbd_conf_template.c declaration of functions USBD_LL_Transmit and USBD_LL_PrepareReceive does not match with definitions of these functions in stm32_mw_usb_device/Core/Inc/usbd_core.h. Last argument has type uint16_t size in declaration and uint32_t size in definition. Causes compilation error.

How To Reproduce

  1. Generate initialization code with STM32CubeMX enabling USB as Device CDC Class. Check "add necessary files as reference".
  2. Clone necessary libraries into your project
git init
git submodule add https://github.com/ARM-software/CMSIS_5 libraries/CMSIS_5
git submodule add https://github.com/STMicroelectronics/cmsis_device_f1.git libraries/cmsis_device_f1
git submodule add https://github.com/STMicroelectronics/stm32f1xx_hal_driver.git libraries/stm32f1xx_hal_driver
git submodule add https://github.com/STMicroelectronics/stm32_mw_usb_device.git libraries/stm32_mw_usb_device
  1. Compile project

Additional context I tried to reproduce the issue on STM32L412 everything went fine USBD_LL_Transmit and USBD_LL_PrepareReceive matched.

created time in 4 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

Hi @RKOUSTM,

As said by @atsju, adding const to function parameters does not break any API. It merely informs the caller that the function will not / cannot modify the callers' parameters.

Hence I find this decision outrageous, especially since it is very easy to implement from a technical point of view. Give any intern a few weeks and he will do it for you. It is almost impossible to screw it up because the compiler will tell you if do something wrong (unless you start using const casts).

I was really cheering for ST since they opened this public bug tracker and published the STM32Cube pack creator tool, which should boost the STM32 software ecosystem through continuous and transparent improvements. But this seems like a big step backwards..

Also, this has been in your pipeline for several years by now (as mentioned by @ALABSTM). This must be a joke. This issue should not be closed yet (but all the duplicates should be).

jrahlf

comment created time in 4 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

I totally agree with @atsju . API-breaking changes must not be avoided, but instead must be introduced in a new major version. You can still maintain your current API with minor revisions and bugfixes for some time e.g.: 18 months by releasing minor versions, while encouraging everyone to move eventually into the safer, const-correct API. This is mostly what most FOSS libraries out there do (see mbedtls or esp-idf as examples) in order to keep a good balance between new features, safety and backwards compatibility.

jrahlf

comment created time in 6 days

issue commentSTMicroelectronics/STM32CubeL4

const as much as possible

@RKOUSTM I answered there : https://github.com/STMicroelectronics/STM32CubeF4/issues/10

ST is quite new to open-sourcing the code on Github and you are doing well. I just wanted to give you a kind advice (take it or not): note that other projets close issues as soon as they are spotted to be duplicate. This permits to centralise discutions to original ticket and to see the importance of the issue. It also reduces your maintenance task when a decision is made about a ticket it is only one and not all your duplicates.

atsju

comment created time in 6 days

issue commentSTMicroelectronics/STM32CubeF4

Const correctness

Hi @RKOUSTM , I agree this is a big workload to make all changes. And yes the API of the HAL will change in that way that the function prototype is slightly different. BUT there is no need to change the examples neither the user code. Indeed adding this const only says that the function itself will no modify the data but the user buffer could be non const without any compilation warning or issue. The proposed changes would only make your code cleaner and has absolutely no impact for your customer (I am part of those customers who do not want the API to change). Best regards,

jrahlf

comment created time in 6 days

issue commentSTMicroelectronics/STM32CubeL4

const as much as possible

Hi @CanastraRF,

First, allow me to thank you for your contribution. The final decision of our technical committee is no plan to add a const inside the function. The reported point is already highlighted during the MISRA-C 2012 compliance rework (Rule-8.13). It has been decided, from the quality point of view, to derogate this rule as fixing it will break the compatibility with almost all HAL APIs and then update all examples and applications within the Cube deliverable and also on user application side.

Please, allow me to close this issue. Thank you for your comprehension.

With regards,

CanastraRF

comment created time in 6 days

issue closedSTMicroelectronics/STM32CubeH7

HAL_SDRAM_Init should take timing argument as const

Describe the set-up

STM32H747I-DISCO, using Zephyr RTOS.

Describe the bug

HAL_StatusTypeDef HAL_SDRAM_Init(SDRAM_HandleTypeDef *hsdram, FMC_SDRAM_TimingTypeDef *Timing)

Should ideally take Timing argument as const, i.e.

HAL_StatusTypeDef HAL_SDRAM_Init(SDRAM_HandleTypeDef *hsdram, const FMC_SDRAM_TimingTypeDef *Timing)

Ref. https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_sdram.c#L171

Note that the same should happen for the LL counterpart, https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_ll_fmc.c#L791

Other FMC functions can probably be adjusted.

How To Reproduce

Not causing any problem, just warnings if using a const structure.

Additional context

N/A

Screenshots

N/A

closed time in 6 days

gmarull

issue commentSTMicroelectronics/STM32CubeH7

HAL_SDRAM_Init should take timing argument as const

Hi @gmarull,

First, allow me to thank you for your contribution. The final decision of our technical committee is no plan to add a const inside the function. The reported point is already highlighted during the MISRA-C 2012 compliance rework (Rule-8.13). It has been decided, from the quality point of view, to derogate this rule as fixing it will break the compatibility with almost all HAL APIs and then update all examples and applications within the Cube deliverable and also on user application side.

Please, allow me to close this issue. Thank you for your comprehension.

With regards,

gmarull

comment created time in 6 days

issue closedSTMicroelectronics/STM32CubeL4

const as much as possible

https://github.com/STMicroelectronics/STM32CubeL4/blob/d023c0d560ace11509f9b761c8913a9e48fcf194/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_crc.c#L339

Should be : <code>uint32_t HAL_CRC_Calculate(CRC_HandleTypeDef *hcrc, <b>const</b> uint32_t pBuffer[], uint32_t BufferLength) </code> This tells the user and the compiler that function will not modify the content of buffer. There are other occurrence in the HAL. Please check them all. This remark is also true for other HAL, not L4 specific.

Note this is not the same as #17. Edit : it is indeed duplicate of #15

closed time in 6 days

atsju
more