EFM32 Family Support

[perigoso]

Describe the PR
Addition of Silabs config options
Addition of EFM32GG12 cmsis
Implementation of the EFM32 DCD driver.
EFM32GG12 Dev Board Support

Additional context
While trying to port this family, thinking it would be completely new, I noticed something very peculiar while looking at the other drivers for help.
I noticed the USB peripheral Silabs uses on their mcus is very close to the one use in the ESP32S2 from espressif, very little difference between them, my guess is that espressif bought the IP from Silabs, or both Silabs and Espressif got it from the same place.
That said, seeing that the peripherals were very close, I decided to stop making the driver from scratch and essentially copied the one from the ESP32S2 (along with everything that could possibly be wrong with it).

This is yet to be tested, I have a custom made board i plan to test on soon, I started the port for a standard dev board, the sltb009a, but I don't have one, not yet at least, so its just a skeleton.

EFM32GG12 Datasheet
EFM32GG12 Reference Manual usb at page 1435

[hathach]

that is great to hear EFM32 also use synopsys as their USB-IP. There is a pending issue #382 to generalize the ip driver much like ehci/ohci. If you could get it running on EFM32, then I guess it would help a lot in the generalization later on. Good news, that I also have an EFM M3 Giant Gecko (EFM32GG-STK3700) sitting on my storage for more than 5 years. Would be great to revive it :D .

[perigoso]

Oh, right, I didn't look closely at the synopsys driver, fascinating.

[perigoso]

So I didn't have time to test this until now, I'm only now trying.

I'm having a weird, unexpected issue, my device is hitting a HardFault on tusb_init I debugged the project and it seems to be failing at:

  // Init class drivers
  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }

because it tries to jump to init() on iteration i=1 but init() points to an invalid address at 0x20030000 the stack at that moment has:

driver: 0x0 <__Vectors>
driver.init: 0x20030000
driver.reset: 0x131 <Reset_Handler>
driver.open: 0x15d <WTIMER1_IRQHandler>
driver.control_xfer_cb: 0x106d <HardFault_Handler>
driver.xfer_cb: 0x1071 <MemManage_Handler>
driver.sof: 0x1075 <BusFault_Handler>
i: 1 '\001'

Its pointing to the vector table.

The call stack:

HardFault_Handler@0x0000106c (/home/perigoso/Development/tinyusb/hw/bsp/sltb009a/sltb009a.c:720)
<signal handler called>@0xffffffe9 (Unknown Source:0)
??@0x20030000 (Unknown Source:0)
tud_init@0x000014d4 (/home/perigoso/Development/tinyusb/src/device/usbd.c:396)
tusb_init@0x000014d4 (/home/perigoso/Development/tinyusb/src/tusb.c:50)
main@0x000014d4 (/home/perigoso/Development/tinyusb/examples/device/hid_generic_inout/src/main.c:79)

I will follow further.

[perigoso]

Ok, I was unable to figure out why this looped more than once,

// Init class drivers
  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }

but i forced it to loop once (i < 1) and after chasing some gremlins with clocks the device enumerated successfully!

I have ordered a sltb009a efm32gg12 dev board from mouser which i will port and then i think we can merge this :) I can try to write support for the dev board you have @hathach , but I dont have one and its too expensive to justify buying so itll have to be blind

[hathach]

thank you, it is great to hear to get it working. If you could make an bsp for the board I have, that would be great, otherwise no problems at all, I found EFM32 dev board is rather expensive as well ( got it as freebie from energy micro a long time ago). I have also ordered sltb009a as well since that is probably most people will buy anyway. Looking forward to your PR.

[perigoso]

Do you have any input into the // Init class drivers issue? I didn't figure it out I just overwrote it

[hathach]

Do you have any input into the // Init class drivers issue? I didn't figure it out I just overwrote it

hmm, can you log print the value of TOTAL_DRIVER_COUNT, it shouldn't have any issues, maybe there is some buffer overflow

[perigoso]

It apparently resolves to 92

[perigoso]

_app_driver_count is 91

[perigoso]

hm, i think this is an initialization/startup issue, that variable is not cleared as it should, i tried to use silabs startup, gotta look at it

[perigoso]

figured it out, by default silabs startup doesnt clear bss, i had to define __STARTUP_CLEAR_BSS, now _app_driver_count is 0, like it should.

[perigoso]

I imagine this was causing issues in other places as well

[hathach]

figured it out, by default silabs startup doesnt clear bss, i had to define __STARTUP_CLEAR_BSS, now _app_driver_count is 0, like it should.

Yeah, I am glad we could figure it out, this probably causes lots of headache across the stack for sure.

[perigoso]

Ok I have now tested a couple different examples, all without issues after enumeration, but there is one common issue, every time after initialization the devices times out

[ 5845.144641] usb 3-4.3: USB disconnect, device number 25
[ 5889.104950] usb 3-4.3: new full-speed USB device number 26 using xhci_hcd

[ 5904.562516] usb 3-4.3: device descriptor read/64, error -110

[ 5904.767196] usb 3-4.3: New USB device found, idVendor=cafe, idProduct=4004, bcdDevice= 1.00
[ 5904.767203] usb 3-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5904.767206] usb 3-4.3: Product: TinyUSB Device
[ 5904.767210] usb 3-4.3: Manufacturer: TinyUSB
[ 5904.767213] usb 3-4.3: SerialNumber: 123456

this happens every time after reset, but after the first enumeration, the device re-enumerates fine, as in, unplugging and plugging back in, it's immediate (device is self powered for testing)

not quite sure how to debug this, I dont have a capable enough logic analyzer, I've looked at wireshark but no packets show up before the timeout, everything afterwards looks normal.

[hathach]

please add the following line, that will help to fix the CI. I have tried may the build to fetch needed submodules (if not already) without user have to do it manually or init it all.

DEPS_SUBMODULES += hw/mcu/silabs/cmsis-dfp-efm32gg12b

[hathach]

Superb !! That is really great to hear Don't worry if you couldn't fix it for now. I think it is already more than enough to wrap up this PR. I am still waiting for the sltb009a to delivery (probably in 2,3 weeks since I am so back ordering other boards as well). I could help to troubleshoot it afterwards with follow-up PR ( just make sure we have an issue for it so that we don't forget). I am actually quite familiar with these kinds of problems with enumeration.

[perigoso]

did some minor cleanups, and removed the code for the board support, will create a seperate PR with it

[hathach]

It looks perfect now. I could merge it unless you want to add/update the PR more.

[perigoso]

You can merge

[hathach]

superb ! merged now, thank you very much.