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.