We are building a Bluetooth analog sensor module using the STM32 and decided to migrate from the F-series to the G-series to take advantage of the reduced power consumption. However, things that were easily working on the F-series are not on the G-series, mainly the SysTick exception which we would like to use to wake up from sleep mode. The attached code, which has been abbreviated from our original code for simplicity, fails to pulse PA3 (it stays low). However, if we comment out the line "LL_SYSTICK_EnableIT();", we get a nice 10Hz pulse on PA3. Clearly this means that SysTick by itself is working, and additionally, the overall project runs fine and just the same as on the F-series without sleep mode as long as this line is commented (with some caveats, below).
In the template file "startup_stm32g030xx.s", which we were not allowed to attach to this message, we have commented out line 149 which is the "B ." infinite loop within the SysTick_Handler procedure. There is no other reference to a SysTick_Handler in our project, which also includes an unmodified file named "system_stm32g0xx.c" and some of the LL driver source files. Commenting out this line was required on the F-series to prevent it from hanging upon waking from sleep mode, but it seems to carry no benefit on the G-series. We have been through both of the datasheets for the two chips, the migration document AN5145, the errata, and all of the code. We cannot find anything that would cause a problem; the stack seems to be getting set, the vector table is located properly, and the vector table entries seem to be correct. Our development environment (Keil uVision) was just freshly installed yesterday and the template files should be fully up-to-date.
There are also some other issues that we noticed, but can work around:
1. HSI16 is not functional as an input source to the ADC. SYSCLK works fine so we use it instead.
2. The migration document AN5145 does not mention having to enable the new voltage regulator for the ADC. However, enabling it separately seems to make no difference anyway.
3. The ADC has to be ForceReset after a programming operation (without a physical/power reset) in order to get calibration to succeed. In general, operation on the G-series seems to be unusual after programming using "st-flash" with our ST-LINK V2, and the chip does not seem to get fully reset. We did not notice any issues with the F-series relating to this.
4. On both the F-series and the G-series, we have to include the line "LL_SPI_SetNSSMode(SPI1, LL_SPI_NSS_HARD_OUTPUT);" or SPI will not work. We do not use any SPI slave-select pins, but instead have free-standing GPIOs designated for REQN/RDYN to talk to an nRF8001.
5. Signing up for this website was difficult and gave errors, but we are not sure where to report this.
Any light that can be shone on these problems would be appreciated. Thanks!
- Arthur
