Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem

[russian]

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

[Giovanni]

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

[psyco]

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.

[KarlK90]

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.

[Tabulous]

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 ?

[KarlK90]

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.

[Tabulous]

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

[Tabulous]

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