is this thread really the only mention of GD32 on this ChibiOS forum or is that me failing to use search?
Anyway a bit confused about https://github.com/psycowithespn/ChibiO ... V/issues/1 but interested to leverage the progress done here
Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
- Giovanni
- Site Admin
- Posts: 14461
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
Hi,
There is a GD32 port in the community repository, not sure how mature it is but most things should be very similar to STM32.
Giovanni
There is a GD32 port in the community repository, not sure how mature it is but most things should be very similar to STM32.
Giovanni
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
russian wrote:is this thread really the only mention of GD32 on this ChibiOS forum or is that me failing to use search?
Anyway a bit confused about https://github.com/psycowithespn/ChibiO ... V/issues/1 but interested to leverage the progress done here
Replied to the issue. Do note that the GD32 stuff on the community repo is RISC-V specific (GD32V*). Others should be compatible with STM32 code.
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
The GD32VF103 port is stable and I use it daily in my keyboards https://karlk90.github.io/yaemk-split-kb/. The RV-ELIC IRQ handling and context switching code had some bugs but all of them have been fixed. So far I think this port is pretty much done, as the only novell thing was the RV core, periphreal wise this mcu is a f103/f105 clone.
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
KarlK90 wrote:The GD32VF103 port is stable and I use it daily in my keyboards https://karlk90.github.io/yaemk-split-kb/. The RV-ELIC IRQ handling and context switching code had some bugs but all of them have been fixed. So far I think this port is pretty much done, as the only novell thing was the RV core, periphreal wise this mcu is a f103/f105 clone.
Hi Karl,
i'm currently running into issues like yours. Porting Chibios (old version) running on STM32F4xx to GD32F4xx.
I have two issues
1. I2C bus locks up
2. USB CDC
First one is not a problem, worst case i'll bitbang the I2C and remove the Chibios I2C drvier.
The second one is causing the headache.......CDC looks to start enumerating, but locks...... The rest of the application looks to keep running as normal just no CDC.
You got any advice on tracking down this issue ?
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
Hi Tabulous,
the core problem with the USB lockups with this port weren't related to the USB driver code but to the handling of IRQ tail-chaining in the context switching. I hooked up Seggers SystemView to ChibiOS (bindings are in the contrib repo) and found the problem by noticing that pattern. But I wouldn't rely on that being the same issue here... Also the whole system just ran into a hardfault at worst or endless nonsense loop because the saved context of the pre-empted thread was overwritten with nonsense. That doesn't appear to be the case here.
Maybe you can crossreference the official GD32 USB driver for this device and see if there is anything drastically different.
If the I2C peripheral is the same as on the GD32VF103 you can have a look at this PR that fixed the I2C lookups for me https://github.com/ChibiOS/ChibiOS-Contrib/pull/273. The driver is based on the STM32 LLD I2Cv1.
the core problem with the USB lockups with this port weren't related to the USB driver code but to the handling of IRQ tail-chaining in the context switching. I hooked up Seggers SystemView to ChibiOS (bindings are in the contrib repo) and found the problem by noticing that pattern. But I wouldn't rely on that being the same issue here... Also the whole system just ran into a hardfault at worst or endless nonsense loop because the saved context of the pre-empted thread was overwritten with nonsense. That doesn't appear to be the case here.
Maybe you can crossreference the official GD32 USB driver for this device and see if there is anything drastically different.
If the I2C peripheral is the same as on the GD32VF103 you can have a look at this PR that fixed the I2C lookups for me https://github.com/ChibiOS/ChibiOS-Contrib/pull/273. The driver is based on the STM32 LLD I2Cv1.
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
Hi Karl,
thanks for your response.
have just found this, in
void usb_lld_start(USBDriver *usbp)
if i set break point on where is sets the otg interrupt masks,
otgp->GINTMSK = GINTMSK_ENUMDNEM | GINTMSK_USBRSTM | GINTMSK_USBSUSPM |
GINTMSK_ESUSPM | GINTMSK_SRQM | GINTMSK_WKUM |
GINTMSK_IISOIXFRM | GINTMSK_IISOOXFRM |
GINTMSK_SOFM;
this must add enough delay for it to throw this
osalDbgAssert(!usbGetReceiveStatusI(usbp, ep), "already receiving");
If i dont break and just let it run as normal, it does not throw the assert.....mmmmm
thanks for your response.
have just found this, in
void usb_lld_start(USBDriver *usbp)
if i set break point on where is sets the otg interrupt masks,
otgp->GINTMSK = GINTMSK_ENUMDNEM | GINTMSK_USBRSTM | GINTMSK_USBSUSPM |
GINTMSK_ESUSPM | GINTMSK_SRQM | GINTMSK_WKUM |
GINTMSK_IISOIXFRM | GINTMSK_IISOOXFRM |
GINTMSK_SOFM;
this must add enough delay for it to throw this
osalDbgAssert(!usbGetReceiveStatusI(usbp, ep), "already receiving");
If i dont break and just let it run as normal, it does not throw the assert.....mmmmm
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
Tabulous wrote:Hi Karl,
thanks for your response.
have just found this, in
void usb_lld_start(USBDriver *usbp)
if i set break point on where is sets the otg interrupt masks,
otgp->GINTMSK = GINTMSK_ENUMDNEM | GINTMSK_USBRSTM | GINTMSK_USBSUSPM |
GINTMSK_ESUSPM | GINTMSK_SRQM | GINTMSK_WKUM |
GINTMSK_IISOIXFRM | GINTMSK_IISOOXFRM |
GINTMSK_SOFM;
this must add enough delay for it to throw this
osalDbgAssert(!usbGetReceiveStatusI(usbp, ep), "already receiving");
If i dont break and just let it run as normal, it does not throw the assert.....mmmmm
So gets more interesting.......
if i comment out these two asserts
osalDbgAssert(!usbGetReceiveStatusI(usbp, ep), "already receiving");
osalDbgAssert(!usbGetTransmitStatusI(usbp, ep), "already transmitting");
and put a delay before the otg interrupt masks are setup, it now works.......but once running if you un-plug the usb and re-plug it in, it will fail like before....
I do believe this is some timing / interrupt issue
Who is online
Users browsing this forum: No registered users and 4 guests