Firmware Update of an embedded system over modbus RTU using serial communication (UART)

V

Thread Starter

vee

Can I update the firmware of an embedded system using modbus RTU over UART?

If yes, what function code needs to be used for firmware update? and How?

Currently, my system supports 1, 2, 3, 4, 5, 6, 15, 16, 23 function codes.

A quick reply will be highly appreciated.
 
I'm aware of one control device that uses Modbus for download and upload of configurations. It uses function codes 20 and 21 to transfer the configuration data.

That same device applies firmware updates with a Windows based "loader" application that manages the firmware data download.

My gut feeling is that if you have to ask how to accomplish a firmware update, you're not in a position to execute an update successfully.
 
> I'm aware of one control device that uses Modbus for download and upload of
> configurations. It uses function codes 20 and 21 to transfer the configuration data.

Can you please name that control device?

> That same device applies firmware updates with a Windows based "loader"
> application that manages the firmware data download.

What format you receive a file on the device, how does it get stored in memory?

> My gut feeling is that if you have to ask how to accomplish a firmware update,
> you're not in a position to execute an update successfully.

Correct, I'm a novice programmer for modbus and firmware update. I've implemented modbus using some function codes as mentioned.
Can you provide more details on FW update as mentioned?
 
Thanks for the reply.

Your response refers to function codes 20 (0x14) & 21 (0x15) which are Read File Reference & Write File Reference respectively.

I feel that there is no file read or write function under Modbus.

Does the use of the function code 16 (0x10), which would allow to write 200 bytes of data per message, from PC to device resolve my problem?

Following are the steps I would like to implement for firmware update through modbus RTU over serial(loading device with a new image file):

1. Break down the image file (FW update) into groups of bytes not to exceed 200 bytes per group.

2. Encapsulate each of the 200 byte groups as write register commands (i.e. add destination Modbus Address 1-249), function code (16 (0x10) = write multiple registers), starting address (two bytes, value depends on how you are managing the counting of groups), qty = 2 bytes value 200 decimal, and than the error check (CRC-16 two bytes).

3. Transmit the groups of bytes from PC to device ONE group at a time. As the response indicates that group of bytes is received, send the next one.

4. Assemble the file from the received groups on the other end (slave).

Please correct me if I'm wrong.
 
L

Lynn August Linse

As someone else pointed out, most vendors either use propritary functions like 0x7D, or the file read/write.

Using standard functions like 16 will be problematic since Modbus holding registers have no notion of moving say 128Kbytes as a whole - which is why the file read/write is preferred.

Plus how are you going to prevent missing a block? Or duplicating a blocks? Imagine this situation - you write block #75, the slave sends a response so now expects block #76 ... but your master misses the response and resends block #75.

In your design you are already demanding a custom 'master' tool breaking up the file and sending it, as well as a custom 'slave' function - why bother misusing using function 16? What does it buy you? Problems is all that I can see you gaining.

The file read/write include offsets, plus if I understand the standard correctly the 10000 'records' can be for example 200 bytes each, so one could move a file of up to 2MB. If your product has different text/code segments, those could be different files which allow you to replace the code in phases.
 
Thanks Lynn.

As modbus RTU messages are limited to 256 bytes in length, and I feel that it does not matter which function code you use, it is still 256 bytes per message.
Am I correct?

If we can use any function code, please follow these steps:

1. Obtain the new image file (say SREC format) with changes in firmware after compilation of user application (say IAR Embedded Workbench for ARM) and provide the same (say SREC) output file for FUU.

2. Establish serial communication with the device remotely using Firmware Update Utility(FUU).

3.So, break (say SREC) new image file contents and map the physical address with data and store it in ‘Send’ file in PC before we can initiate modbus transactions for firmware update. ‘Send’ file contents are given below:

<Address><Data><Data><Data>…<Data
<Address><Data><Data><Data>…<Data
...
<Address><Data><Data><Data>…<Data

4. FUU should be intelligent enough to send each line from ‘Send’ file in the form of a modbus request message as given below. Modbus response messages will be echo of the request messages.

Device ID 1 byte
Function Code 1 byte
Firmware Update address 2 bytes (Special address)
Physical Memory Address 2/4/6 bytes
Data 248/246/244 bytes
CRC 2 bytes

5. During each modbus request, the device has to store all 256 bytes in a local buffer. Strip off device id, function code, CRC bytes and check for address (FU address).

6. If the address sent is FU then, new image file is transferred in the form of modbus transactions. Send a different address when you reach the end of the ‘Send’ file contents to transfer. We store all absolute addresses and corresponding data in local buffers.
7. After completion of modbus transactions, a new firmware update is performed by erasing the entire flash, unsecuring the device and writing data to flash at specified absolute address from local buffers using flash routines.
8.We need to have a software reset routine to reboot the entire system.

Please correct me if I'm wrong.
 
L

Lynn August Linse

Keep in mind you could even transfer Intel HEX files as Modbus payload:
:020000040007F3
:1000000096D2000480030A160000000000000000E1
:1000100000310000000015B500184E001A50001CF9
(etc)

I would just suggest reinventing as few wheels as you can, and avoid 'confusing' users by using function 16 in non-standard ways. No one will expect function 16 to work in the psuedo-queue design you plan to use.

I'd suggest either using the published Modbus 'File read/Write', or use any of the equally valid published Modbus 'User Defined Function Codes" in the range 65 to 72, or 100 to 110.

At least with the public codes you can do ANYTHING you wish, as long as you keep the max size in the normal range, the CRC16 valid and the first 2 bytes (slave id and function code) correct. The user defined codes will pass through Modbus TCP-to-serial bridges or Modbus-aware radios just fine.
 
Top