DMA2 should be OK now.
Giovanni
Support for STM32G0B1 Topic is solved
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
-
- Posts: 6
- Joined: Fri Aug 27, 2021 7:43 am
- Has thanked: 1 time
- Been thanked: 3 times
Re: Support for STM32G0B1
Hi
Can confirm DMA2 issue appears to be fixed. No longer getting any issues when compiling. I will wait for any updates on USB driver, I have joined the discord server and am on discord more than here, feel free to ping me on there when you need something tested.
Thank you
Can confirm DMA2 issue appears to be fixed. No longer getting any issues when compiling. I will wait for any updates on USB driver, I have joined the discord server and am on discord more than here, feel free to ping me on there when you need something tested.
Thank you
Re: Support for STM32G0B1
Hi Giovanni,
Sorry for disappearing without posting the files I modified - I couldn't get it working properly and then had to switch to STMcube stuff before going on holiday.
I now downloaded the latest code and the latest openOCD to match (seems to flash properly now) and I still have a major problem: the G0B1 nucleo demo seems to run fine on the matching nucleo board, but after flashing it I can only reconnect to the MCU under hardware reset, which means: no debugging. This is the same behavior I had before with my patches and I thought I had messed up some init code, misconfiguring the SWD pins or something. Any idea why this is?
Best regards,
Thomas
PS: during this holiday I biked the length of Italy and also came through Salerno, but I missed the chance to buy you a beer
Sorry for disappearing without posting the files I modified - I couldn't get it working properly and then had to switch to STMcube stuff before going on holiday.
I now downloaded the latest code and the latest openOCD to match (seems to flash properly now) and I still have a major problem: the G0B1 nucleo demo seems to run fine on the matching nucleo board, but after flashing it I can only reconnect to the MCU under hardware reset, which means: no debugging. This is the same behavior I had before with my patches and I thought I had messed up some init code, misconfiguring the SWD pins or something. Any idea why this is?
Best regards,
Thomas
PS: during this holiday I biked the length of Italy and also came through Salerno, but I missed the chance to buy you a beer
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Support for STM32G0B1
fractal wrote:PS: during this holiday I biked the length of Italy and also came through Salerno, but I missed the chance to buy you a beer
I hope you biked through the "Costiera Amalfinata" from Positano to Salerno, it is my preferred biking route, great scenery
About the problem with B1, it could be a problem in board.h setup, it could block the SWD pins, I need to check that, need to find a board too...
Giovanni
Re: Support for STM32G0B1
I did bike there, very nice landscape
The board.h was the first thing I checked, both two months ago with my own "port" and now, cant find a mistake, or any difference in SWD from the other G0s. I also replicated it on another computer with another nucleo, because I felt it might be something with my setup or something I caused by playing with the option bytes. I also manually set the SWDIO and SWDCLK (A13 and A14) to alternate 0 after the initialization, no effect.
One issue I found with the G0 port:
TIMv1/stm32_tim3_4.inc: there are two different names for the same define: STM32_IRQ_TIM3_4_PRIORITY and STM32_IRQ_TIM3_TIM4_PRIORITY
The board.h was the first thing I checked, both two months ago with my own "port" and now, cant find a mistake, or any difference in SWD from the other G0s. I also replicated it on another computer with another nucleo, because I felt it might be something with my setup or something I caused by playing with the option bytes. I also manually set the SWDIO and SWDCLK (A13 and A14) to alternate 0 after the initialization, no effect.
One issue I found with the G0 port:
TIMv1/stm32_tim3_4.inc: there are two different names for the same define: STM32_IRQ_TIM3_4_PRIORITY and STM32_IRQ_TIM3_TIM4_PRIORITY
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Support for STM32G0B1
Hi,
About the STM32G0B1 issue.
- The bit PVMENUSB in PRW_CR2 is documented to be at zero after reset. It is at 1.
- HAL initializes that registers with PVMENUSB=0 as documented, this causes the debugger to malfunction...
- There is not an errata about this.
Will look into a SW workaround, keeping that bit at 1 makes everything work.
Don't ask me why a "USB supply voltage monitoring enable" bit makes the debug malfunction if disabled...
Giovanni
About the STM32G0B1 issue.
- The bit PVMENUSB in PRW_CR2 is documented to be at zero after reset. It is at 1.
- HAL initializes that registers with PVMENUSB=0 as documented, this causes the debugger to malfunction...
- There is not an errata about this.
Will look into a SW workaround, keeping that bit at 1 makes everything work.
Don't ask me why a "USB supply voltage monitoring enable" bit makes the debug malfunction if disabled...
Giovanni
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Support for STM32G0B1
Great, thank you. How the hell did you figure that out?
Two more things for the port I noticed when changing the systick timer:
- the debug register name has changed, DBG instead of DBGMCU
- for SYSTICKv1/hal_st_lld.c, this requires an additional elif
#elif defined(STM32G0XX)
#define ST_ENABLE_STOP() DBG->APBFZ1 |= DBG_APB_FZ1_DBG_TIM4_STOP
- TIM4 is missing from STM32G0xx/stm32_rcc.h
I also tried to set up serial via USB and it fails to enumerate - windows says device descriptor request failed and the USB driver says EP0 is in an error state. Is this likely to be related to the G0 USB hardware or is my config for the serial connection wrong? I looked at several examples for the latter, but none of them worked for me. Any hints where to look for the problem?
Two more things for the port I noticed when changing the systick timer:
- the debug register name has changed, DBG instead of DBGMCU
- for SYSTICKv1/hal_st_lld.c, this requires an additional elif
#elif defined(STM32G0XX)
#define ST_ENABLE_STOP() DBG->APBFZ1 |= DBG_APB_FZ1_DBG_TIM4_STOP
- TIM4 is missing from STM32G0xx/stm32_rcc.h
I also tried to set up serial via USB and it fails to enumerate - windows says device descriptor request failed and the USB driver says EP0 is in an error state. Is this likely to be related to the G0 USB hardware or is my config for the serial connection wrong? I looked at several examples for the latter, but none of them worked for me. Any hints where to look for the problem?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Support for STM32G0B1
Hi,
By placing infinite loops in the initialization sequence like this:
asm volatile (".xxx: b .xxx");
This prevents the compiler from removing the following lines, a "while(1);" would do that. Then with the debugger skip all loops until I found the line that broke the debugger.
About USB, on G0 it is different, it will require a new USBv2 driver, it is one of the next things in the todo list. The peripheral changed significantly because they added support for host mode.
Giovanni
By placing infinite loops in the initialization sequence like this:
asm volatile (".xxx: b .xxx");
This prevents the compiler from removing the following lines, a "while(1);" would do that. Then with the debugger skip all loops until I found the line that broke the debugger.
About USB, on G0 it is different, it will require a new USBv2 driver, it is one of the next things in the todo list. The peripheral changed significantly because they added support for host mode.
Giovanni
Who is online
Users browsing this forum: No registered users and 9 guests