BASEPRI setting after reset

[heveskar]

Board: Riverdi display with STM32H757XIH6 MCU; using TouchGFX and FreeRTOS

I think I know how BASEPRI register works and how it is used in FreeRTOS. What I do not know is where is the value of BASEPRI register set at the beginning of the program. I noticed that before the start of FreeRTOS scheduler, it is at the value configMAX_SYSCALL_INTERRUPT_PRIORITY. Right after reset, it is at zero as I would expect. In the call to the main() function it as already at the configMAX_SYSCALL_INTERRUPT_PRIORITY value. I stepped the startup assembly code and before call to the 

__libc_init_array

function it is 0, after this call it is at that higher value. This function should not change this register, right? I think it does some library initialization and I cannot step its code.

I think that this behavior may have changed with the latest HAL, as on our other board with STM32H723 and older HAL, it was zero always from the reset on.

My main question is if it is okay to just call 

vPortSetBASEPRI(0);

function after system initialization and before FreeRTOS scheduler start. I need to do this since I am loading some SPI configuration from EEPROM and I need this done before FreeRTOS starts.

Thanks.

[Pavel A.]

Yes, it would be strange if C library initializers tamper with BASEPRI. But they can allocate memory, thus call the newlib locking hooks. Do you use any multi-threading/reentrancy additions for FreeRTOS or something from Mr. Nadler? Any CMSIS-RTOS wrapper?

Usually raising BASEPRI early before enabling device interrupts and before the RTOS starts is right what you want. This blocks (lower-priority) interrupts that call RTOS services which are not ready yet.

[heveskar]

I am not using any Nadler's code, only thing is that I use the configUSE_NEWLIB_REENTRANT define. In the CubeMX I have selected CMSIS_V2 interface.

I agree with your second point but it still puzzled me as I was used to the default value.

Okay so maybe the answer is that some locking hooks from newlib are called as you say.

[Bob S]

Since this is C++ code, are there any global class instances that use FreeRTOS mutex/semaphore/queue?  If so, their constructors will be called during the init code (don't know if from libc_init_array or a separate c++ specific array of init functions).  And creating any of those FreeRTOS entities will muck with BASEPRI because that is how FreeRTOS disables interrupts during critical sections.  And when those critical sections are run BEFORE osKernelStart, they end up leaving BASEPRI with that value.

[heveskar]

I did not create any global class instances that use those FreeRTOS entities but it is maybe possible that TouchGFX did.

[Daniel Hassanian]

I stumbled upon the exact same problem in Arduino IDE for stm32. as it turns out declaring a Global Class variable does this and in my case a call to realloc is causing this.

https://github.com/orgs/stm32duino/discussions/2178