Things I’ve accomplished this week

• • Robustness testing, extensive range testing at the track Saturday
  • TOM rev. 2, MCU board #1 assembled, not working in time for demo as of Sunday Night — MCU does not program despite all connections seeming to be solid electrically, and I’m pretty sure it was not thermally shocked during rework 🙁
    • Rework / assembly / post-mortem pending further review
  • Enclosure finished for use at the track

Deliverables for next week:

• Continue work on CAN bootloader, more track testing
• Final status of Rev. 2

Updates on schedule:

• Schedule has been updated for final report

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.

Risks

• Rev. 2 assembly has fallen behind due to other more critical tasks for driving the car and testing the existing system
  • Assembly may occur tomorrow (05-05), but non-critical as the existing revisions work perfectly fine
• Ground control UI remains unintegrated, and likely will not be ready in time for public demo
  • On the other hand, PCAN’s plotting and trac  ing functionality proved to be quite useful, and pretty much feature-complete in terms of data visualization
• Even with the larger PittRace area, we were unable to test at the full desired range of ~600 m (max. tested ~230 m)
  • Nevertheless, we remain confident that Wi-Fi is feasible from the competition stands, given sufficient line-of-sight (achievable by mounting the directional dish to a tripod, and placing it on the roof of e.g. a vehicle)

Design changes

None.

Updated schedule

No updates. See our Gantt chart for more details.

Individual updates

• Assisted with FMS parking lot testing
  • Successfully used the system for providing immediate feedback about the effects of experimental traction control features on the vehicle’s performance
• Assisted with PittRace track testing
  • Again, the system worked well, this time oriented more towards debugging various motor controller faults and providing live battery pack status (voltage, temperature, etc.)

Schedule status

Final wrap-up continues; at this point, additional features are optional “nice-to-haves.” Some effort will also be devoted to extra module assembly and the final report.

Deliverables for 2019 May 11

• Auto-detection of XBee settings upon boot
  • This requires AT command request/response management in the XBee interfaces
• Basic Ground Control UI integration

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.

Individual updates

• Debugged a UART issue that prevents transmission of large chunks
  • Working with Cameron to switch over to a circular DMA buffer to support these payloads for the bootloader
• Went to PittRace on a cold, rainy Friday
  • Spent most of the time debugging various technical issues on the car
  • Not enough driving time to collect meaningful data; will be revisiting the FMS lot this week

Schedule status

I have completed my mission-critical schedule items, and am continuing work on the “stretch goals.”

Deliverables for 2019 May 4

• Auto-detection of XBee settings upon boot
  • This requires AT command request/response management in the XBee interfaces
• Basic Ground Control UI integration

Risks

• Ground control application still remains underway; hopefully, it will be ready in time for the public demonstration, as it is arguably the most interactive part of our system.
• Bootloader work continues; it looks promising, but requires significant rewriting of the UART driver on the TOM to support wireless reflashing.
• Rev. 2 assembly will be occurring as soon as the board arrives on Monday.

Design changes

None.

Updated schedule

No updates. See our Gantt chart for more details.

Things I’ve accomplished this week

• TOM rev. 2 (final) ordered, arriving Monday
  • $70 in budget remaining
• CAN Bootloader progress
  • ‘Made the Jump:’ Relocated code to a different flash sector, called from standard user code
  • Included lots of hacky debugging, like moving the vector table around and debugging assembly
  • Turns out branching in ARM thumb mode needs to see lsb = 1, who knew
  • Wrote a script to convert a binary file into a TOM-parseable UART stream for CAN transmission
• Helped Cameron and Stan debug a UART/DMA issue
• Fleshed out binary transmission protocol: Use 0-255 message chunks of 7 bytes each, with each chunk headed by a message containing the start address and length in bytes of its payload
• Things still to fix:
  • Need to poke around more with the different flash sectors, some don’t seem to program despite the flash utility reporting them as writeable
  • Need to figure out why CAN hardware is inactive after jumping to bootloader code

Deliverables for next week:

• Manufactured rev. 2 hardware, prepped for final demo, report mostly finalized
• More progress on the CAN bootloader (bonus work, outside the literal scope of the project)

Updates on schedule:

• Slack has been eaten into, crunch time is here, but assuming the 2nd revision works readily enough we’ll be fine

What I’ve accomplished this week:

• Got rev. 2 ordered at long last
  • Included migrating CAN interface pins, double checking connector interface, sourcing appropriate ribbon cables, adding a Link OK LED, etc.
• Begun work on the CAN bootloader
  • Working prototype sees another STM32 controller blasting out a long string of binary data, with flow numbers for each packet to verify they’re arriving in sequence
  • Bootloader accumulates this data, verifying that a) messages are received in the correct order and b) that the CRC matches
    • CRC seems to only work on the sending side (hardware can’t be enabled on the receiver), but as the receiving side is an 413ZH dev board controller at the moment I’m not too concerned
  • If messages are received out of sequence, there is a timeout, the CRC fails, the received binary is too large, or there is an internal error, the bootloader aborts and hard resets the microcontroller
  • Some TODO’s here:
    • Make the bootloader actually flash the received code
    • Expose an interface for writing non-contiguous data: The .elf’s are 200+KB, which is getting close to our memory limit, whereas the binaries themselves are only 20+KB, so this saves time and space at the cost of a bit of implementation complexity
    • Migrate the bootloader code to a specific page in flash that won’t get overwritten by flashing new code
    • Allow non-contiguous messages within one ‘wrap’ of the 1 byte sequence. My first idea here was to just tag each possible sequence number (256), and error if any number in the run is received twice before the sequence wraps around. This erroneously errors when the last message in the sequence is reordered though, so I think a better approach would be to split the transfer into multiple chunks, with a header message carrying a different ID for the chunk’s address
    • Require the sender to confirm the total bytes sent via a handshake (currently just a one-way ACK back)

Deliverables for next week:

• Prototypical bootloader or some variant thereof: In particular, the ability to flash an MCU over CAN with respect to a blind byte stream.
• A sketch of a more robust communication protocol, or implementation hints for one.
• Status on rev. 2’s fabrication/delivery (won’t be manufactured until end of April most likely, but we have the BOM and PCB’s for another rev. 1 just in case)

Updates on last week’s deliverables:

• Email sent to Quinn ordering TOM rev. 2. Will follow up with him during the work week to further coordinate that expenditure.
• UART testing proved succesful, and we’re able to stream CAN->UART thanks to Stan’s hard work in particular. Next up will be two-way transmission over that link.

Individual updates

• Worked with Cameron to implement various UART firewall configuration commands and properly integrate the firewall
• Implemented and tested CAN streaming over UART
  • I.e., messages received over XBee are also re-broadcasted over UART (upon enabling via user command)
  • Sending upon user command still to be implemented
• Revisited architecture for streaming data to web backend

Schedule status

I am back on track for my schedule items.

Deliverables for 2019 Apr. 27

• Auto-detection of XBee settings upon boot
  • This requires AT command request/response management in the XBee interfaces
• Basic Ground Control UI integration