Author: cmackint

The UART receive implementation with circular buffer that I implemented last week had quite a few bugs. I didn’t disable several interrupts, and a buffer was being clobbered. It works at least as well as the previous implementation.

Recall this is required only for the bootloader, where it sends large UART messages containing many CAN message containing the new firmware code; we’ll finish this up after the project.

I wrote the final poster and put together a quick draft of the final report. I’ve still got to write the design trade section, which depends on the test data Zach and Stan took on Saturday.

I implemented the UART command to transmit a CAN message over the XBee bridge to the remote TOM.

There’s a problem with the UART drivers for large receive messages. The UART drivers use per-message DMA processes. The current implementation, when the read function is called, waits for a DMA process to end and return data, copies the data to a buffer, and restarts the DMA process. The brief period of time during the data copy has no ongoing DMA process, causing data loss.

The solution is to use a single DMA process backed with a circular buffer, where the receive function simply copies out from this buffer. I’ve implemented this, and will test this today.

We’ll be working on presentations/posters this coming week.

Risks

• Rev. 2 is late at this point, realistically no time for a third revision (mitigated by the fact that rev. 1 meets our M.V.P. pending some firmware updates)
• We’re beginning to implement the CMR-specific use case of the TOM: creating the ground control application that uploads the CAN bus stream to a remote server for a web application to display to other team members. This is a reach goal, thus is not planned for in our Gantt chart, thus has some deadline concerns.
• Range testing continues
  • Successful tests at pittrace under 150m proved promising but still not fully conclusive, further testing will rely on larger track areas on some of their other tarmacs in the coming weeks

Updated schedule

No updates: We’re still on schedule in terms of PCB schematic and layout, as well as firmware implementation. (See our Gantt chart for more details.)

I implemented, tested, and merged the UART commands (firewall block/allow/list, help, etc).

I refactored the config system in the stm32 drivers to increase flexibility. It now allows each client to specify the flash sector and config size. If I have time,  I can quickly update it further to only write up to the last updated flash word, rather than the entire cached config array.

We’ll be moving to implement the CMR use-case of the TOM: creating a ground control application that uploads data to a remote server for a web application to display to other CMR team members. This ground control application will communicate with the TOM via UART; I’ll be adding a command that prints the bridged CAN bus next week.

I verified the firewall functions as expected.

I implemented a few versions of the UART command line and refactored them with Stan. It all works as expected, with no timeliness issues.

I implemented the command parsing part of the UART, but need to rebase it on the latest UART revision and test it on the TOM; I’ll do this on Sunday/Monday as I’m out of town for Carnival. I suspect it will be trivial.

I removed many unnecessary features from the firewall system. Now it simply permits adding to a single firewall blacklist by CAN ID: No multiple firewalls with different priorities.

The UART command line implementation hit a road block. The UART driver’s receive function uses DMA (direct memory access) and receive idle interrupts. This had a small bug: the transmit function triggered an idle interrupt after each transmission despite the idle flag not actually being set. This was fixed by trivially checking the idle flag.

The UART driver works as expected; I’ll be implementing the command line on Sunday. The DMA receive call is blocking, thus command handling must not happen in the receive task. I’ll probably update the driver receive to be non-blocking by adding a per-message synchronization rather than global synchronization, as Stan implemented with the driver transmit function last week. Alternatively, I could simply add the received commands to a queue for a processing task to handle.

There’s currently an issue with the CAN driver; once resolved I’ll run integration tests on the firewall for a sanity check.

I spent the last week working on responding to the configuration system pull request feedback and implementing the firewall. I intended to finish the UART system and integrate it into the config system, but ran into some problems with the firewall.

I initially naively implemented the firewall by appending to an array of firewall entry structs, requiring linear lookup time. Under Zach’s suggestion, I reimplemented it using bitfields to prove constant lookup time. This is important as the firewall needs to be run on every CAN message.

The issue with the config flash system preventing reprogramming the TOM without a full chip erase became a problem in debugging the firewall. I tested the config system by reading from a flash sector, incrementing the value, and writing it back throughout the entire sector. I would reset the board multiple times, and check that the incremented value was correct by using the ST-Link Utility to analyze the flash. However, between subsequent debug executions, the TrueStudio memory viewer shows incorrect information. I ultimately verified the firewall by using debug flags.

I also had a few silly bugs in the config API that manifested when implementing the firewall, involving pointer typedefs and incrementing order of operations.

Next week, I’ll finish the UART integration and XBee switching.

Risks

• Packets dropping over the TCP link (even over a short distance) affects link stability quite significantly. The link will often be interrupted for a few seconds when packets drop.
  • We will likely switch to UDP, as we do not provide strict ordering.
  • We also have a more exotic idea in the works: UDP enables us to move
• Rev. 2 changes are still in progress.
  • The revision will be laid out by Monday, 1 April.
  • It will be reviewed/ordered shortly after.
• Range testing still to be done.
  • Testing will occur soon in the FMS breezeway and parking lot.
  • Additional testing will likely occur at PittRace; the team plans on heading there for track testing in a few weeks.

Design changes

• No design changes have been made.

Updated schedule

• No updates: We’re still on schedule in terms of PCB schematic and layout, as well as firmware implementation. (See our Gantt chart for more details.)

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.

This week I modified the CAN codec heatshrink configuration to improve performance. This invalidated the use of the augmented run length (ARL) algorithm, as on average the compression ratio of heatshrink alone is better than the compression ratio of ARL+heatshrink. The statistics for 800 messages per block are in the image below.

We visited a 1.5km line-of-sight bike path to range test the Wi-Fi X-Bee radios.

I am behind on the configuration API and firewall given school work, the design report, and our range-testing trip. I will be writing them over spring break and then testing them when I next have access to the dev boards in FMS. These two softwares aren’t terribly complicated, so I should be able to finish them by the end of next week.