You are here

Push FW .bin File to Controller

3 posts / 0 new
Last post
vadicus
Offline
Last seen: 3 days 9 hours ago
VESC Free
Joined: 2018-08-17 07:26
Posts: 427
Push FW .bin File to Controller

I've been working to implement OTA update for my custom hardware which has Arduino connected to UART. The Arduino has pre-loaded VESC firmware .bin image. I figured out most of the communication protocol and I can send commands to VESC and receive data back. The communication protocol has two packet types: below or above 256 bytes. The package type and length of the package is identified in the header of the packet and CRC is added to the end.

I've monitored the communication going between the VESC tool and the controller during FW flash process and I am seeing that first it sends smaller packets under 256 bytes then it will send the bulk of the .bin file using larger packets over 256 bytes.

There are three FW update specific commands in the commands.c file:

1. COMM_JUMP_TO_BOOTLOADER:

2. COMM_ERASE_NEW_APP

3. COMM_WRITE_NEW_APP_DATA 

here is the link to this location:

https://github.com/vedderb/bldc/blob/b3ad0be25a7eb8248e0a708964835506334...

I think what I am missing is the exact workflow of the update process and at what point I need to send the .bin file.

My understanding so far is that:

1. I jump to the bootlaoder (no other input or output is expected other then triggering this command)

2. Then immediately issue ERASE_NEW_APP command and pass the file stream. Wait for the function to return: send_buffer[ind++] = flash_res == FLASH_COMPLETE ? 1 : 0;

3. Finally, kick of the upgrade: COMM_WRITE_NEW_APP_DATA. I am abit confused about this stem as it seems to be expecting mroe input like length of the decompressed bin files. etc

It will return again result: send_buffer[ind++] = flash_res == FLASH_COMPLETE ? 1 : 0;

 

Could someone familiar with the process confirm what the sequence should be and what input and output each command exects or outputs, and at what moment the .bin file needs to be sent?

I did check how VESC tool is doing it but I can't find the exact spot in the code for the FW update.

Thank you.

 

 

pf26
Offline
Last seen: 3 months 5 days ago
VESC Free
Joined: 2018-12-04 08:44
Posts: 52

You could use a serial port spy (like portmon - even on USB serial ports) to catch the frames in and out from VESC-TOOL during firmware upgrade.

Why do you prefer to use an arduino instead of  making a custom app inside the VESC (in which case you keep the UART free for OTA, using a bluetooth module for instance)

vadicus
Offline
Last seen: 3 days 9 hours ago
VESC Free
Joined: 2018-08-17 07:26
Posts: 427

Yes, I've caught the traffic and looks straightforward. It's just a lot of frames to go through but I'll do that if there is no easier way. The code is supposed to give an idea where the file push happens but I am a bit confused about COM_ERASE and COM_WRITE commands as they both seem to take some input. JUMP_TO_BOOTLOADER is simple.

I use a secondary chip for Bluetooth and other connectivity and processing to offload those function from the main chip. 

 

 

NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)