Blogs

Finally got the LED to light up.  There was a lot of printing every register read & write to compare with the kernel driver.  The mane differences were because this board was being reset by every microcontroller reset, while reloading the kernel module didn't reset its board.

After trying many random things, a further problem with the stm32 USB stack was revealed.  The board wasn't taking up all the register writes with CTRL_STATUS_IN bypassed.  The only workaround that worked, after many random ideas, was reading back every write.  It's slow, but better than nothing.

As predicted, the STM32 USB driver continued to give problems. There's a sequence in USBH_HandleControl when sending data to the device on the config endpoint:

CTRL_SETUP -> CTRL_SETUP_WAIT -> CTRL_DATA_OUT -> CTRL_DATA_OUT_WAIT ->
CTRL_STATUS_IN -> CTRL_STATUS_IN_WAIT

which locks up in CTRL_STATUS_IN_WAIT.  Another 2 days yielded a workaround in skipping CTRL_STATUS_IN -> CTRL_STATUS_IN_WAIT & it works well enough.

Starting a new platform is always long & hard.  Compiled sections of the rtl8192cu driver both by porting it to Marcy 2 & by porting a fake Linux back end to Marcy 2.  That showed it was much easier to make a fake Linux back end.  You can make a subset of the Linux headers & keep the driver mostly intact.  

This makes it easier to change drivers.  Porting the driver itself is a huge effort directed at just 1 piece of hardware.  The version changes between kernels are a lot smaller than porting new drivers.

  So the driver came to 177kb, that would take an eternity to upload on JTAG, & the flash needed wear leveling, so a bootloader was required.  The increasing complexity brought up the idea of Arduino for ARM again, but we all know how long democratic software projects take to finish & it still remains vaporware.  It would be quite a big step to write our own Arduino front end for ARM.

  The battle of the bootloader led to a painful weight concession.  To be any use for consumers, the bootloader needed to be on different pins than JTAG, so the hardware was analogous to Arduino.  Arduino was moving towards a USB debugger on different pins than JTAG.

That meant still another header was needed for a UART to debug the bootloader on the USB, so what was the point of having USB on the microcontroller for debugging?  The idea of having the debugging output go through a USB serial port running on the same microcontroller also meant it disconnected every time the microcontroller rebooted.

The whole idea of a USB debugger sounded more like a selling point than something anyone would use.    You need a UART that's always connected when the microcontroller reboots & which can debug the microcontroller's bootloader, which only a separate FDTI chip or dongle can do.  You can't really work on a microcontroller with just a USB cable.

  That led this evolution to just a UART in addition to the JTAG, & no USB bootloader.  As for the reset pins, apparently Arduinos require the user to manually reset or connect an extra pin to the FTDI DTR pin.  We'd still need the user to touch the JTAG reset pin for that.