Hi, I'm curious if there is support planned for STM32G0B1xx devices? For example the STM32G0B1RE that is found on NUCLEO-G0B1RE.
EDIT: Reason why I'm asking: I have a tray of 200pcs STM32G0B1KE.
Best regards from California,
Windsor
Support for STM32G0B1 Topic is solved
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for STM32G0B1
I was just about to create a post with the same title, allow me to hijack this one. I have some STM32G0B1KC and NUCLEO-G0B1R and am torn between getting used to STM32cube-things and freeRTOS or getting the B1 subfamily working with chibios/chibistudio.
I have already started adapting the existing G0 port to cover the B1/C1 family, but there are actually a lot of differences compared to the 51/71 and one or two things appear to be unique to these new devices.
Could someone help me get an overview what needs to be done get get these devices and standard peripherals (e.g. I need USB, not USB PD) working?
Differences I see
1) more flash (up to 512kB), more ram (144kB)
- one (128kB) or two banks (>128kB)
2) bigger packages, including port E
3) DMA2 with 5 channels
4) one more comparator (COMP3)
5) one more timer (TIM4)
6) one more I2C (I2C3)
7) two more USART (5 & 6), one of them advanced (USART1-3)
8) one more LPUART (LPUART2)
9) one more SPI (SPI3)
10) USB 2 FS
11) 2 FDCANs
Done so far
Port:
stm32_registry.h: adding new section
stm32_rcc: add DMA2 and USB
stm32_isr: add DMA2 and USB
hal_lld.h: add platform, CAN, CLK48, USB
platform.mk: add USB and CAN
RCCv1
stm32_hsi48.inc: the 48 MHz oscillator is present on G071, but not sure what for, anyway it wasnt in the code. The registers on this family seem to differ from the code, HSI48ON and HSI48RDY are in RCC->CR instead of RCC->CRRCR, so I added an #if check for STM32G0XX to enable and disable
USBv1
- stm32_usb.h: the USB memory seems to be located at USB_DRD_PMAADDR instead of USB1_PMAADDR or USB_PMAADDR, so I added that option
- hal_usb_lld.h: the USB has two restart bits (USB_CNTR_L1RES | USB_CNTR_L2RES) instead of one (USB_CNTR_RESUME), I didnt check the significance of L1/L2 and merely added a #if for STM32G0XX which sets both to the wakeup
- linker file: I created some for my devices with 256kB and 512kB, merely adding larger ram/flash values and a second flash bank (not used)
- openOCD: there is support in the latest builds, but I think there is something wrong, I got undefined exceptions with it, which I didnt have with ST tools, may be related to the two banks and unfinished support at openOCD
With these edits the G071 demo project compiles and loads to both my HW and the nucleo, but
1) with openOCD it will only end up with an unhandled exception.
2) with stm32cubeprogrammer it will run, but not allow debugging - with chibios running it connects only under HW reset. Something wrong with the hal init I suspect, the GPIO pins for SWD are configured correctly (as they were in the G071 demo) and I cant find an error with the new poert E.
I would be happy about any help in getting this running, finished and into chibios.
Thomas
I have already started adapting the existing G0 port to cover the B1/C1 family, but there are actually a lot of differences compared to the 51/71 and one or two things appear to be unique to these new devices.
Could someone help me get an overview what needs to be done get get these devices and standard peripherals (e.g. I need USB, not USB PD) working?
Differences I see
1) more flash (up to 512kB), more ram (144kB)
- one (128kB) or two banks (>128kB)
2) bigger packages, including port E
3) DMA2 with 5 channels
4) one more comparator (COMP3)
5) one more timer (TIM4)
6) one more I2C (I2C3)
7) two more USART (5 & 6), one of them advanced (USART1-3)
8) one more LPUART (LPUART2)
9) one more SPI (SPI3)
10) USB 2 FS
11) 2 FDCANs
Done so far
Port:
stm32_registry.h: adding new section
stm32_rcc: add DMA2 and USB
stm32_isr: add DMA2 and USB
hal_lld.h: add platform, CAN, CLK48, USB
platform.mk: add USB and CAN
RCCv1
stm32_hsi48.inc: the 48 MHz oscillator is present on G071, but not sure what for, anyway it wasnt in the code. The registers on this family seem to differ from the code, HSI48ON and HSI48RDY are in RCC->CR instead of RCC->CRRCR, so I added an #if check for STM32G0XX to enable and disable
USBv1
- stm32_usb.h: the USB memory seems to be located at USB_DRD_PMAADDR instead of USB1_PMAADDR or USB_PMAADDR, so I added that option
- hal_usb_lld.h: the USB has two restart bits (USB_CNTR_L1RES | USB_CNTR_L2RES) instead of one (USB_CNTR_RESUME), I didnt check the significance of L1/L2 and merely added a #if for STM32G0XX which sets both to the wakeup
- linker file: I created some for my devices with 256kB and 512kB, merely adding larger ram/flash values and a second flash bank (not used)
- openOCD: there is support in the latest builds, but I think there is something wrong, I got undefined exceptions with it, which I didnt have with ST tools, may be related to the two banks and unfinished support at openOCD
With these edits the G071 demo project compiles and loads to both my HW and the nucleo, but
1) with openOCD it will only end up with an unhandled exception.
2) with stm32cubeprogrammer it will run, but not allow debugging - with chibios running it connects only under HW reset. Something wrong with the hal init I suspect, the GPIO pins for SWD are configured correctly (as they were in the G071 demo) and I cant find an error with the new poert E.
I would be happy about any help in getting this running, finished and into chibios.
Thomas
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for STM32G0B1
Hi,
You did most of it, just mcuconf.h generator tool should be added. Probably you also need to add specific board files.
I will try to get one of those boards.
Giovanni
You did most of it, just mcuconf.h generator tool should be added. Probably you also need to add specific board files.
I will try to get one of those boards.
Giovanni
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for STM32G0B1
Hi,
Support and a demo added in trunk, there were some unexpected changes required because the G0B1 shares interrupts in new ways (and I did not mention that in my previous post). Now it should be fine but it was way more complex than I anticipated...
Please post your files because I have not yet added the RCC changes.
Giovanni
Support and a demo added in trunk, there were some unexpected changes required because the G0B1 shares interrupts in new ways (and I did not mention that in my previous post). Now it should be fine but it was way more complex than I anticipated...
Please post your files because I have not yet added the RCC changes.
Giovanni
-
- Posts: 6
- Joined: Fri Aug 27, 2021 7:43 am
- Has thanked: 1 time
- Been thanked: 3 times
Re: Support for STM32G0B1
Hi,
Firstly big thanks for adding support for the STM32G0B1 series, I got a few to play with them but noticed was not able to compile when trying to use USB and then it was pointed out to me there was no USB Driver in https://github.com/ChibiOS/ChibiOS/blob ... latform.mk
Is there any ETA on when USB support will be added for these ?
Thank you.
Firstly big thanks for adding support for the STM32G0B1 series, I got a few to play with them but noticed was not able to compile when trying to use USB and then it was pointed out to me there was no USB Driver in https://github.com/ChibiOS/ChibiOS/blob ... latform.mk
Is there any ETA on when USB support will be added for these ?
Thank you.
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for STM32G0B1
Hi,
The G0 has an improved USB peripheral, it supports also host mode but should be compatible with the previous one, there are few differences in headers that I need to address, I will commit some changes later today.
The USB driver would probably work as-is but I have no way to test it right now. Could you give it a try when it is done?
Giovanni
The G0 has an improved USB peripheral, it supports also host mode but should be compatible with the previous one, there are few differences in headers that I need to address, I will commit some changes later today.
The USB driver would probably work as-is but I have no way to test it right now. Could you give it a try when it is done?
Giovanni
Re: Support for STM32G0B1
Had to add USBv1 to the G0xx peripherals list in platform.mk.
For a start, needed to modify mcuconf.h:
The mcuconf updater injects wrong priority values w.r.t. the number of priority bits -- it only has 2 on G0xx.
Also needed these in stm32_isr.h:
Current issue -- looks similar to fractal's note above:
For a start, needed to modify mcuconf.h:
Code: Select all
#define STM32_USB_USE_USB1 TRUE
#define STM32_USB_USB1_HP_IRQ_PRIORITY 3
#define STM32_USB_USB1_LP_IRQ_PRIORITY 3
The mcuconf updater injects wrong priority values w.r.t. the number of priority bits -- it only has 2 on G0xx.
Also needed these in stm32_isr.h:
Code: Select all
#define STM32_USB1_HP_HANDLER Vector60
#define STM32_USB1_HP_NUMBER 8
#define STM32_USB1_LP_HANDLER Vector60
#define STM32_USB1_LP_NUMBER 8
Current issue -- looks similar to fractal's note above:
Code: Select all
lib/chibios/os/hal/src/hal_usb.c: In function 'usbWakeupHost':
./lib/chibios/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.h:476:24: error: 'USB_CNTR_RESUME' undeclared (first use in this function); did you mean 'USB_CNTR_RESETM'?
STM32_USB->CNTR |= USB_CNTR_RESUME; \
^~~~~~~~~~~~~~~
lib/chibios/os/hal/src/hal_usb.c:667:5: note: in expansion of macro 'usb_lld_wakeup_host'
usb_lld_wakeup_host(usbp);
^~~~~~~~~~~~~~~~~~~
./lib/chibios/os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.h:476:24: note: each undeclared identifier is reported only once for each function it appears in
STM32_USB->CNTR |= USB_CNTR_RESUME; \
^~~~~~~~~~~~~~~
lib/chibios/os/hal/src/hal_usb.c:667:5: note: in expansion of macro 'usb_lld_wakeup_host'
usb_lld_wakeup_host(usbp);
^~~~~~~~~~~~~~~~~~~
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Support for STM32G0B1
Hi,
I just committed on thunk those changes (and a lot more...), please give it a try.
Giovanni
I just committed on thunk those changes (and a lot more...), please give it a try.
Giovanni
-
- Posts: 6
- Joined: Fri Aug 27, 2021 7:43 am
- Has thanked: 1 time
- Been thanked: 3 times
Re: Support for STM32G0B1
Gave it a try this evening, either I configured something wrong or it's not working yet. I copied the demo mcuconf.h but changed STM32_HSI48_ENABLED & STM32_USB_USE_USB1 to TRUE.
It compiled fine, after flashing it windows doesn't detect anything when the device is plugged in or disconnected, it is completely unaware the device is plugged in. I can put it back into DFU mode and it gets detected straight away so I don't believe it is a hardware fault.
I also ran into another problem while enabling SPI to turn on some other features of the board to try make sure the MCU was booting up fine
I am out of time to test right now but will try have another look tomorrow.
It compiled fine, after flashing it windows doesn't detect anything when the device is plugged in or disconnected, it is completely unaware the device is plugged in. I can put it back into DFU mode and it gets detected straight away so I don't believe it is a hardware fault.
I also ran into another problem while enabling SPI to turn on some other features of the board to try make sure the MCU was booting up fine
Code: Select all
Compiling: lib/chibios/os/hal/ports/STM32/LLD/DMAv1/stm32_dma.c lib/chibios/os/hal/ports/STM32/LLD/DMAv1/stm32_dma.c: In function 'dmaStreamAllocI':
lib/chibios/os/hal/ports/STM32/LLD/DMAv1/stm32_dma.c:643:9: error: implicit declaration of function 'rccEnableDMA2'; did you mean 'rccEnableDMA1'? [-Werror=implicit-function-declaration]
643 | rccEnableDMA2(true);
| ^~~~~~~~~~~~~
| rccEnableDMA1
lib/chibios/os/hal/ports/STM32/LLD/DMAv1/stm32_dma.c: In function 'dmaStreamFreeI':
lib/chibios/os/hal/ports/STM32/LLD/DMAv1/stm32_dma.c:747:5: error: implicit declaration of function 'rccDisableDMA2'; did you mean 'rccDisableDMA1'? [-Werror=implicit-function-declaration]
747 | rccDisableDMA2();
| ^~~~~~~~~~~~~~
| rccDisableDMA1
I am out of time to test right now but will try have another look tomorrow.
Who is online
Users browsing this forum: No registered users and 28 guests