Closed vortex314 closed 2 years ago
Changing this line : #define TICK_INT_PRIORITY 0x00U /!< tick interrupt priority was 0FU / Prevented the stalling.
Thanks for your input. Would you like to make a pull request so i can review?
The strange thing is that the file that I need to change is not part of your repository. It's located in ~/.platformio/packages/framework-stm32cubef1/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_hal_conf.h while there is an equivalent stm32f1xx_hal_conf.h in your repo, which is not taken into account during compilation with platformio. Your file looks correct on this priority setting, I don't understand yet why your file is being ignored.
Platformio has its own library files as far as I know.
From the verbose option in platformio , it looks like the Inc directory of your repo is taken first. So I tried to rename the stm32f1xx_hal_conf.h in platformio libraries, the strange thing is that PIO recreates the file during build from stm32f1xx_hal_conf_template.h. The verbose PIO command ;
arm-none-eabi-gcc -o .pio/build/VARIANT_DEBUG/FrameworkHALDriver/Src/stm32f1xx_hal.o -c -T./STM32F103C8Tx_FLASH.ld -g -ggdb -Os -ffunction-sections -fdata-sections -Wall -mthumb -mcpu=cortex-m3 -nostdlib -DPLATFORMIO=50202 -DSTM32F103xB -DSTM32F1 -DUSE_HAL_DRIVER -DSTM32F103xB -DVARIANT_DEBUG -DUSE_HAL_DRIVER -DF_CPU=72000000L -ISrc -IInc -I/home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/CMSIS/DSP/Include -I/home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/CMSIS/Include -I/home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I/home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/STM32F1xx_HAL_Driver/Inc -I/home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/STM32F1xx_HAL_Driver/Src /home/lieven/.platformio/packages/framework-stm32cubef1/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.c
Mysterious...
I guess this is a quirk of platformio and STM32 Cube Drivers, not related to your repo. Thanks again for your swift responses.
The read from I2C never times out when there is an issue. Looks like a known bug for STM32 https://community.st.com/s/question/0D53W000007Wj9wSAC/hali2c-hangs-when-it-enters-i2cwaitonflaguntiltimeout-function The Systick priority is lower than the USART interrupt and the clock doesn't advance to create the timeout.
The above code in stm32f1xx_hal_i2c.c never times out I tried to increase the priority of the systick handler. No result so far.