I spent Spring break familiarizing myself with the existing STM32 firmware, development tools, and designing the configuration system and firewall.
I spent last week working on the configuration system implementation and UART API. I passed off the UART API to Stan to perfect the DMA calls as he had experience with that in the SPI API. The STM32 hardware abstraction library (HAL) UART receive function doesn’t have the ability to receive an arbitrary number of bytes; this has to be implemented using DMA and UART idle interrupts. The config system itself is rather simple, simply writing and retrieving data from the MCU’s flash memory.
However, I ran into some trouble with the ST IDE, TrueStudio. After erasing or writing the flash memory with config data, the IDE fails to reprogram the development board. However, the configuration system continues to operate correctly throughout board reset. I discovered the only way to successfully reprogram the board is to completely erase the board’s flash using the ST-Link Utility software. I researched online, and discovered several possible explanations/remedies, although nobody has had the same problem as me: there is a bug with the TrueStudio flash utility, the TrueStudio flash process performs a checksum on the entire flash memory that thus fails after a flash write of configuration data (which I tested as not true, as simply erasing a flash sector that was already erased and untouched still prevented reprogramming), and the hardware abstraction library flash function sets a flash lock bit. Further, I found that writing to flash sector 2 allowed the board to be reprogrammed without error, however this overwrote part of a symbol table thus causing FreeRTOS to crash. In order to verify that my code is not simply incorrect, and that the problem does indeed lie with MCU/TrueStudio configuration, I tested the provided STM32F413 example flash program, which simply erases a few sectors (2 and 3), writes to them, reads from them, and verifies the writes were successful. This caused the same problem as the TOM firmware. I’ve decided it’s better to continue developing the firewall and live with the minor inconvenience of having to erase the flash before reprogramming. I’ll have my teammates take a look whenever they have some down time, and continue to work on it myself. One next step to confirm that the problem lies with TrueStudio, is to program the board using the STM32Programmer software. I have yet to do this as the software was too buggy on Ubuntu 18.10 to move past the start page.
My plan is to double check the config system, implement the firewall, and send a pull request for both to my teammates, by Monday night. Following this, I’ll integrate the UART API into the config system and firewall. If time permits, I’d also like to update the config system to easily switch between the Zigbee XBee and Wi-Fi XBee.