STM32: Meowbit support

[hierophect]

This PR adds support for the Meowbit board by Kittenbot. Adds definitions for the STM32F401RE, a new MCU for the port. Requires #2395 and #2379. Resolves #2196, resolves #2145.

Bugs fixed as a part of debugging this board:

• A dangling pointer error was present in PWMOut, which caused erratic issues when using PWMOut and the backlight in DisplayIO . Resolves STM32: displayio information lost after a user error #2524, resolves STM32: PWMOut failure on Meowbit, possibly all F401 boards #2444.
• Resolves a vector table relocation issue that would be present for any UF2 bootloader on STM32
• Fixes a pin claiming issue that would occur in rare cases and prevent pins from being re-used.
• Inverts the polarity of PWM's duty cycle to match the other ports.
• Fixes an issue where a shared internal SPI bus would not share lock information between displayio and the flash api.

Still has a number of todos left:

• Include Screen in board init, and prevent conflicts with Flash
• Fix bug where PWM is not working on buzzer
• Create linker option for use with preprogrammed Meowbit bootloader
• Style and attribution cleanup

[hierophect]

This is almost done with two remaining issues.

1. I'm still unable to get the Meowbit's built in UF2 bootloader to recognize the UF2 files generated by tools/uf2/util/uf2conv.py. Unlike the Micropython UF2 they provide from their website, which causes a reset when loaded, ours just moves to the bootloader drive and sits there without incident. Hoping to resolve this with the Meowbit team since otherwise users will need to manually solder on an SWD header to their board to use Circuitpython.
2. Once Circuitpython is on the Meowbit, we're going to be in a bit of a pickle memory-wise. The bootloader currently reserves all of the first 4 flash sectors (16K each), which are also unfortunately the only sectors that can be used for an internal filesystem, since the later sectors are too large to buffer in RAM. This means the only viable memory will be the external flash, but that's currently on the same bus as the display, and current way DisplayIO is managed on reset means that they can't both be enabled without a total board crash. Hopefully we can either reduce the amount of space taken by the bootloader to 16K so we can have a 48K internal filesystem size, or rework DisplayIO to play better with flash on reset, or both.

Until then it might be a good idea to have two different build options, one for SWD with an internal filesystem and Display access, and another that supports the UF2 bootloader with external flash but disables the display until we can fix the flash/display restart conflict.

[tannewt]

How are you initializing the display? Is an exception printed to the serial output?

[hierophect]

How are you initializing the display? Is an exception printed to the serial output?

It does not get that far (serial output). The code is:

• initialize the display
• run some display stuff
• infinite loop of prints ("hello")

I'll see like one or two hellos and then it does a soft reboot

Code done running. Waiting for reload.
soft reboot

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:

after which it enters the crashed state.

[hierophect]

https://gist.github.com/hierophect/c73989682ffb82c26b2c09e919b9f3cc

[hierophect]

Detailed repro info:

• This now works successfully if you have a release-displays at the beginning and the end of the code, implying the recent bugfixes have resolved the major issues with release-displays. If you give a nice long delay before the code ends you'll see display activity.
• However, there is still a crash that occurs if you remove the final release-displays. Once crashed, debugger reveals the code is stuck in a TX not empty loop in HAL_SPI_Transmit.
  • Function of failure is always HAL_SPI_Transmit (hspi=0x20002600 <spi+4>, pData=0x20003778 "\001,-\262\003\001,-\263\006\001,-\001,-\264\001\a\300\003\242\002\204\301\001\305\302\002\n", Size=3, Timeout=4294967295)
  • Reproduction steps:
    • make the change
    • run the code once (to keyboard interrupt) - no crashes so far.
    • soft reboot
    • Code dies at display construction, Display.c:93 (after imports, initial release)
    • Code will be completely immobile after this point (due to infinite hang)
    • Restarting from debugger/power will result in one good loop before problem occurs again after soft reset
      • even the introduction of bugs will be fine for one loop after restart, then fail once changes are saved or program is manually restarted.
    • Error occurs between these two lines in Display.c construct (note that the first one is successful)
      • self->core.send(self->core.bus, DISPLAY_COMMAND, CHIP_SELECT_TOGGLE_EVERY_BYTE, cmd, 1); self->core.send(self->core.bus, DISPLAY_DATA, CHIP_SELECT_UNTOUCHED, data, data_size);
      • This is during the output of the init sequence
      • it does NOT occur on the first loop - it's somewhere late in the process, but always in the same place
      • It's puzzling this doesn't happen on an internal filesystem. I don't see how this is related to external flash.

[hierophect]

This PR is now ready for testing! See updated description for bugfix details.
UF2:
firmware.uf2.zip

Screen test python:
https://gist.github.com/hierophect/1a9f14d3681d73dd7e003b8f41f6666e

[ladyada]

tested by creating display and printing out sensor data - works great, very stable!

code.txt

[tannewt]

Just a few things. Thanks for getting this going!

[hierophect]

@xmeow I'd still be interested in what the 0x194 value is in the linker file
RAM (xrw) : ORIGIN = 0x20000194, LENGTH = 96K - 0x194

I notice it isn't in https://github.com/mmoskal/uf2-stm32f, and that value isn't referenced in your source code anywhere else. Do you have any comment on what that's being used for?

[tannewt]

I'd like to see the display initialized automatically. I saw your ping on Discord about the spi bus not being initialized. We can change things so it is. :-)

1. Add a call from main to board_init directly here: https://github.com/adafruit/circuitpython/blob/master/main.c#L427 This way the filesystem will be initialized.
2. Remove all board_init calls from each port's port_init. board_init is only ever used for initializing displays so waiting is totally fine.

[hierophect]

@tannewt I've made the board change, and it works for my builds, but I'm making note here of all boards that include content in board_init that isn't screen related. I don't own any of these, and they should probably get tested for any unexpected breakage.

• capablerobot_usbhub
• feather_mimxrt1011
• feather_mimxrt1062
• imxrt1010_evk
• arduino_nano_33_ble

[tannewt]

capablerobot_usbhub is now empty. The three imx ones are super alpha and I don't think they will break. @dhalbert would be able to tell about the arduino nano.

[hierophect]

I think this should be good to go now.

[tannewt]

So close! I think you missed removing board_init from the stm32 port.

[tannewt]

Yay! Looks great! Thank you!