I2C Bootloader Thoughts

  • Have the bootloader sit at the end of the region. The app image's reset vector must always point to the bootloader's start location.
    • This way the app gets to set the vector table EXCEPT for the reset vector
  • I could probably use DFU, but I probably also want the ability to customize the behavior.
    • e.g. "chain loading"
  • I probably want to have some ability to have the bootloader program to RAM, in order to update the bootloader itself. This could be done later, or you could boot to an app that reprograms the bootloader region
  • I need a second device to act as a test stand.
    • I could use two debuggers
    • I already have the nrf52 patches that include auto timeout for i2c
      • But no USB
    • I could add timeouts to the stm32f4 hal
      • Then use a pretty hal machine style RPC interface?
  • I need to implement i2c peripheral code for the g0
  • Should I just make an entire test rack?
    • I already have an everything connector
    • I could then just splice together two GPIO interfaces
  • Most of my boards provide 3v3 to QWIIC
    • Could use a custom breakout
    • Could use a custom cable
  • g0 hal already has flash page support!

Order of operations

  1. Write a basic flash-aware program to figure out the API
  2. Write an STM32F4 pretty hal machine (kta?)
  3. Probably port the timeout driver to the stm32f4
  4. Test it with an existing I2C device
  5. Write an STM32G0 I2C peripheral driver
  6. Write an application that can write to flash with I2C commands
  7. Write the rest of the bootloader