STM32: Add STM32F4Discovery support

[hierophect]

This PR adds support to the STM32F4 Discovery board (a bit confusingly named, possibly because it was the first Discovery?). This board runs an STM32F407VG MCU with 1MB of flash and 192K of SRAM, and has a nearly identical pin layout to the STM32F411 Discovery board (this board adds the PB11 pin to replace an NC pin). Requires #2568 for some linker stuff.

Todos for this PR:

• Need valid VID/PID (@tannewt / @ladyada)
• USB not currently working

I'm not sure what the USB issue is - possibly a lack of Tusb support for the F407?

[hathach]

maybe we can call it STM32F407 Discovery although its official name is only STM32F4 Discovery . TinyUSB does support f407, in fact this is one of the first board I used to tested with STM32 port, here is its BSP
https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32f407disco

However, F407 USB FS only has 4 pairs of endpoints, including control endpoints. Which means we can only have CDC ( 2 IN + 1 OUT) and MSC ( 1 IN + 1 OUT) only. Could you skip the hid, midi to see if that work. Else I will try to help troubleshoot this issue on Monday,

[hierophect]

@hathach Thanks for the info - this build is already only using CDC and MSC as per mpconfigboard.mk, so I don't believe that's it.

One of the lines returned by the debugger is this:
tud_cdc_n_connected (itf=itf@entry=0 '\000') at ../../lib/tinyusb/src/device/usbd.h:62. Wondering if that 0 parameter is problematic?

[tannewt]

Here are IDs:

STM32F407 Discovery VID 0x239A    PID 0x0089  # bootloader
                                  PID 0x8089  # arduino
                                  PID 0x808A  # circuitpython

[tannewt]

maybe we can call it STM32F407 Discovery although its official name is only STM32F4 Discovery . TinyUSB does support f407, in fact this is one of the first board I used to tested with STM32 port, here is its BSP
https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32f407disco

My preference is to follow the official name even though it is ambiguous.

@hierophect Please add the new board to the board list to fix the test.

[hierophect]

@hathach the _usbd_dev object is empty - where should I poke around to try and find the root cause of that?

p _usbd_dev
$2 = {{connected = 0 '\000', configured = 0 '\000', suspended = 0 '\000', remote_wakeup_en = 0 '\000', remote_wakeup_support = 0 '\000', self_powered = 0 '\000'}, itf2drv = '\377' <repeats 16 times>, 
  ep2drv = {"\377\377", "\377\377", "\377\377", "\377\377", "\377\377", "\377\377", "\377\377", "\377\377"}, ep_status = {{{busy = false, stalled = false}, {busy = false, stalled = false}}, {{
        busy = false, stalled = false}, {busy = false, stalled = false}}, {{busy = false, stalled = false}, {busy = false, stalled = false}}, {{busy = false, stalled = false}, {busy = false, 
        stalled = false}}, {{busy = false, stalled = false}, {busy = false, stalled = false}}, {{busy = false, stalled = false}, {busy = false, stalled = false}}, {{busy = false, stalled = false}, {
        busy = false, stalled = false}}, {{busy = false, stalled = false}, {busy = false, stalled = false}}}}

[hierophect]

I'm now getting this same issue on the Espruino, but it doesn't occur on fresh feather builds, so I'm really puzzled as to what's up.

[hierophect]

Found it, was just an oscillator oversight. Sorry for the trouble.

[hierophect]

@tannewt this is tested and ready for review.

[hierophect]

@tannewt ping: ready for re-review

[tannewt]

Looks great! Thank you!