Support for STM32G0B1 Topic is solved

[fractal]

Hi Giovanni,

I had a look at the register differences between G0 and old usb (e.g. F3), and while I don't really understand all the code, I tried making the obvious name changes that were partially already done in the new USBv2 files. I didnt understand the changes to the buffer, so I left that alone. Maybe it helps, I have attached my hal_usb_lld.c to this post.

[Giovanni]

Hi,

Thanks, will review and merge it.

Giovanni

[Giovanni]

Small update, the driver now compiles but it does not work yet, it gets interrupts so it is "active".

Added a STM32G0B1 target to the USB-CDC demo.

Giovanni

[Giovanni]

It appears to work now but there are parts not yet finalized (fast option, isochronous support).

Giovanni

[fractal]

Confirmed working (with my hardware and windows). Thank you!

[charlesrwest]

I'm trying to get up and running with Chibios on a STM32G0B1VET6. Currently I'm trying to port the RT-STM32G0B1RE-NUCLEO64 demo so that it can run on the STM32G0B1VET6/my board. I'm using a 8 MHz osc (just like the dev board), so no issues there.

I ask ChatGPT what I need to do and it gave the following:

► Show Spoiler

The STM32G0B1RE is quite close to the STM32G0B1VE, with the major difference being the package (RE comes in LQFP64, while VE comes in LQFP100) and some additional features/peripherals for VE. Adapting a ChibiOS project from one to the other involves some steps.

1. **Board Configuration**:
- Update the board files (`board.h`, `board.c`) to match your custom board's configuration, including GPIO assignments, peripherals, and any other hardware features that are specific to your board.
- If there are any extra peripherals or pins on the VE version that you want to utilize, ensure they are defined and initialized properly.

2. **MCU Configuration**:
- Change the MCU definition in the project's makefile (or equivalent) from STM32G0B1RE to STM32G0B1VE.
- Check the ChibiOS configuration files (`mcuconf.h`, `halconf.h`) for any MCU-specific settings. The memory sizes (RAM and Flash) might be the same, but double-check to be sure. Adjust any other peripheral-specific settings as needed.

3. **Clock Configuration**:
- Ensure the clock settings (`hal_lld.c` if it's available) match your hardware. For instance, if you're using an external oscillator on your custom board, ensure that the clock initialization reflects that.

4. **Linker Script**:
- Ensure that the linker script matches the memory layout for the STM32G0B1VE. It's possible that the RE and VE have the same memory layout, but you should double-check. This script defines how your code and data are placed in Flash and RAM.

5. **Peripheral Availability**:
- Some peripherals or pins might be available on VE and not on RE. If you wish to use those peripherals, make sure to configure and initialize them. Similarly, disable or adjust configurations for any peripherals you don’t plan to use.

6. **Driver Configuration**:
- If there are peripherals on the VE variant not present on the RE variant, and ChibiOS has drivers for them, remember to enable and configure these drivers in `halconf.h` and `mcuconf.h`.

7. **Testing**:
- Since you're moving to a new MCU and a custom board, rigorous testing is necessary. Ensure all peripherals are working as expected. Start with basic GPIO testing and move on to more complex peripherals.
- It might also be beneficial to set up debugging capabilities (like SWD) on your custom board to assist in the development and testing process.

8. **Documentation**:
- Refer to the STM32G0B1VE datasheet and reference manual to understand any differences or additional features compared to the RE variant. It will guide your configuration and ensure you utilize the MCU to its fullest potential.

Remember, while the demo is a great starting point, your custom board might have its unique quirks and features. Always consult the hardware design, MCU datasheet, and reference manual to ensure proper configuration.

If I may ask, does the suggestions seem accurate? If not, what's off? Also, is there a easier way to get it up and running? Thanks!

Edit:
Upon searching through the code, everything seems fairly generic with regards to the package variant/pin count. Is there actually anything I need to change besides the follow board specific pin assignments to get the demo running?

► Show Spoiler

#define LINE_STLK_RX PAL_LINE(GPIOA, 2U)
#define LINE_STLK_TX PAL_LINE(GPIOA, 3U)
#define LINE_LED_GREEN PAL_LINE(GPIOA, 5U)
#define LINE_SWDIO PAL_LINE(GPIOA, 13U)
#define LINE_SWCLK PAL_LINE(GPIOA, 14U)
#define LINE_BUTTON PAL_LINE(GPIOC, 13U)
#define LINE_OSC32_IN PAL_LINE(GPIOC, 14U)
#define LINE_OSC32_OUT PAL_LINE(GPIOC, 15U)
#define LINE_OSC_IN PAL_LINE(GPIOF, 0U)
#define LINE_OSC_OUT PAL_LINE(GPIOF, 1U)

[Giovanni]

Hi,

It is only partly correct, there are some errors.

Please visit http://www.playembedded.org guides there should cover most of those points.

Note that board files are not meant to be edited manually, there is a code generator in ChibiStudio, edit the XML file instead (board.chcfg).

Giovanni

[charlesrwest]

I'm running into some errors that seem like they might be bugs.

If you take the RT-STM32G0B1RE-NUCLEO64 demo and enable PWM (HAL_USE_PWM -> TRUE, STM32_PWM_USE_TIM1 -> TRUE, STM32_PWM_USE_TIM3 -> TRUE, STM32_PWM_USE_TIM4 -> TRUE), then you get the following error:

► Show Spoiler

In file included from ../../../os/hal/ports/STM32/STM32G0xx/stm32_isr.c:87:
../../../os/hal/ports/STM32/LLD/TIMv1/stm32_tim3_4.inc: In function 'tim3_tim4_irq_init':
../../../os/hal/ports/STM32/LLD/TIMv1/stm32_tim3_4.inc:108:20: error: 'STM32_IRQ_TIM3_TIM4_PRIORITY' undeclared (first use in this function); did you mean 'STM32_IRQ_TIM3_4_PRIORITY'?
108 | STM32_IRQ_TIM3_TIM4_PRIORITY);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| STM32_IRQ_TIM3_4_PRIORITY
../../../os/hal/ports/STM32/LLD/TIMv1/stm32_tim3_4.inc:108:20: note: each undeclared identifier is reported only once for each function it appears in
make: *** [../../../os/common/startup/ARMCMx/compilers/GCC/mk/rules.mk:190: build/obj/stm32_isr.o] Error 1

If you patch that so that STM32_IRQ_TIM3_TIM4_PRIORITY = 1, you get the following warning:

► Show Spoiler

Compiling hal_pwm_lld.c
../../../os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c: In function 'pwm_lld_start':
../../../os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c:656:7: warning: implicit declaration of function 'rccEnableTIM4'; did you mean 'rccEnableTIM3'? [-Wimplicit-function-declaration]
656 | rccEnableTIM4(true);
| ^~~~~~~~~~~~~
| rccEnableTIM3
../../../os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c:657:7: warning: implicit declaration of function 'rccResetTIM4'; did you mean 'rccResetTIM14'? [-Wimplicit-function-declaration]
657 | rccResetTIM4();
| ^~~~~~~~~~~~
| rccResetTIM14
../../../os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c: In function 'pwm_lld_stop':
../../../os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c:1029:7: warning: implicit declaration of function 'rccDisableTIM4'; did you mean 'rccDisableTIM14'? [-Wimplicit-function-declaration]
1029 | rccDisableTIM4();
| ^~~~~~~~~~~~~~
| rccDisableTIM14

and in my actual project where I am trying to do PWM with those timers, I get the following linker errors:

► Show Spoiler

/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /tmp/ccyvg3d7.ltrans0.ltrans.o: in function `GoodBot::PWMController::PWMController(GoodBot::Timer, unsigned long) [clone .constprop.0] [clone .isra.0]':
/home/charlesrwest/cpp/libraries/ChibiOS_21.11.3/os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c:656:(.text._ZN7GoodBot13PWMControllerC2ENS_5TimerEm.constprop.0.isra.0+0x248): undefined reference to `rccEnableTIM4'
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /tmp/ccyvg3d7.ltrans0.ltrans.o:/home/charlesrwest/cpp/libraries/ChibiOS_21.11.3/os/hal/ports/STM32/LLD/TIMv1/hal_pwm_lld.c:657:(.text._ZN7GoodBot13PWMControllerC2ENS_5TimerEm.constprop.0.isra.0+0x24c): undefined reference to `rccResetTIM4'

If I may ask, is this simply bad configuration on my end or is there a bug here? I built both without the IDE, but I can go back and reinstall the linux IDE so I can try it there if need be. Thanks.

[Giovanni]

Hi,

It is most likely a bug, repening this ticket, will be fixed in next release.

Giovanni

[charlesrwest]

If I may ask, is the RT-STM32G0B1RE-NUCLEO64 demo expected to work? I just tried it with the NUCLEO-G0B1RE and the light stopped flashing once the install occurred.

ChibiOS:
ChibiOS_21.11.3

Project:
RT-STM32G0B1RE-NUCLEO64

GCC:
gcc-arm-none-eabi-bin (Arch package)

Flash command:
st-flash --reset erase
st-flash --reset write ./build/ch.bin 0x08000000

Any help would be appreciated. Also, would it be possible to put a bounty on bug fixes for this chipset prior to the next release ($500?)?