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

This forum is about you. Feel free to discuss anything is related to embedded and electronics, your awesome projects, your ideas, your announcements, not necessarily related to ChibiOS but to embedded in general. This forum is NOT for support.
User avatar
russian
Posts: 364
Joined: Mon Oct 29, 2012 3:17 am
Location: Jersey City, USA
Has thanked: 16 times
Been thanked: 14 times

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

Postby russian » Sun Nov 07, 2021 6:42 pm

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 :)
http://rusefi.com/ - electronic fuel injection

User avatar
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: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem

Postby Giovanni » Sun Nov 07, 2021 6:59 pm

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
Posts: 21
Joined: Fri May 22, 2020 1:40 am
Been thanked: 11 times

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

Postby psyco » Sun Nov 07, 2021 7:11 pm

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.

KarlK90
Posts: 7
Joined: Fri Feb 05, 2021 10:53 am
Been thanked: 3 times

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

Postby KarlK90 » Sun Nov 07, 2021 7:27 pm

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
Posts: 509
Joined: Fri May 03, 2013 12:02 pm
Has thanked: 7 times
Been thanked: 17 times

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

Postby Tabulous » Wed Feb 02, 2022 10:33 am

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 ?

KarlK90
Posts: 7
Joined: Fri Feb 05, 2021 10:53 am
Been thanked: 3 times

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

Postby KarlK90 » Wed Feb 02, 2022 11:36 am

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
Posts: 509
Joined: Fri May 03, 2013 12:02 pm
Has thanked: 7 times
Been thanked: 17 times

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

Postby Tabulous » Wed Feb 02, 2022 12:06 pm

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
Posts: 509
Joined: Fri May 03, 2013 12:02 pm
Has thanked: 7 times
Been thanked: 17 times

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

Postby Tabulous » Wed Feb 02, 2022 12:42 pm

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


Return to “User Projects”

Who is online

Users browsing this forum: No registered users and 8 guests