...
General procedure
The ccm module provides some multiple ways to update the firmware. On the module 2
two firmware objects are present. Those are the bootloader and the application.
The bootloader is immutable by the user. It contains the basic startup code,
firmware flashing routines and signature verification code for firmware
update.
All shown firmware update methods have a basic procedure in common:
the The running applications application puts the firmware update data into the RAM of the
module.if If firmware update data was received a reboot of the running application is
performed. This step can be permitted by the application controller.the The bootloader starts and detects a pending firmware update.
the The bootloader verifies the firmware signature, if passed the firmware is
flashed . here - the previously running firmware is still kept.the The bootloader starts the new firmware.
if If configured, the commits the running firmware during bootup . - else this
commit process is triggered from external.
Depending on the commit execution the bootloader then starts the new firmware
or the previously run firmware.
...
Method | Description |
|---|---|
HTTP | Firmware upload using a an HTTP-POST Request, used by the communication explorer tool Industrial Communication Explorer |
FoE | Firmware upload using a an EtherCAT FoE transfer, used by the communication explorer tool for EtherCAT devices |
SPI | Firmware upload using RPC functions by the application controller |
...
The following table shows the default behaviour for firmware update regarding commit:
Method | Firmware Commit configuration |
|---|---|
HTTP | by default commit is required, thus a specific URL has to be requested after firmware update which triggers the commit |
FoE | commit is automatically done after booting of the updated firmware |
SPI | commit is automatically done after booting of the updated firmware |
Table: Firmware update commit configuration
...
The mentioned methods FoE and SPI set this variable implicitly, however after firmware update the variable is reset to the default value of 0.
...
Firmware is delivered as a firmware package. This file, e.g. irj45_1.2.0.35_ci1243.pfw, is basically a zip archive which contains the following files:
File | Description |
|---|---|
bundle/bundle.xml | bundle description |
irj45_2port.dat | firmware update file for HTTP method |
irj45_2port.bin | firmware update file for FoE/SPI method |
...
A valid IP configuration of the device must be configured to support update
over HTTP. The application controller needs to permit firmware update in
general. This is the case by default, but can be configured using a an RPC
function:
| Code Block |
|---|
GOAL_STATUS_T appl_ccmUpdateAllow(
void
);
GOAL_STATUS_T appl_ccmUpdateDeny(
void
); |
...
Firmware update over HTTP supports basic authentication. Authentication
credentials are compared against CM variables:
...
The application can register an optional callback function to take control of some aspects during firmware update.
...
If the application does not register a callback function, the communication module will reboot when firmware reception is done. If the application does register a callback function, the communication module will reboot only when appl_ccmFwUpdateExecute() is called by the application controller.
...
If successful, this transmission will perform a reboot of the device. Startup takes a long time since the bootloader will verify and flash the new update. The updated firmware will restart after this process, which may take up to 2 minutes.
If the updated firmware is running, a commit step is required to permanently enable the updated firmware. Firmware update commit is done using a HTTP Post Request:
...
The application controller needs to permit firmware update in
general. This is the case by default, but can be configured using a an RPC
function:
| Code Block |
|---|
GOAL_STATUS_T appl_ccmUpdateAllow(
void
);
GOAL_STATUS_T appl_ccmUpdateDeny(
void
); |
...
Firmware update over FoE supports authentication. Authentication
credentials are compared against CM variables:
...
The application can register an optional callback function to take control of some aspects during firmware update.
...
If the application does not register a callback function, the communication module will reboot when firmware reception is done. If the application does register a callback function, the communication module will reboot only when appl_ccmFwUpdateExecute() is called by the application controller.
...
Firmware Update Method SPI
Preconditions
A An SPI communication between AC and CC must be established.
The application controller needs to permit firmware update in
general. This is the case by default, but can be configured using a an RPC
function:
| Code Block |
|---|
GOAL_STATUS_T appl_ccmUpdateAllow(
void
);
GOAL_STATUS_T appl_ccmUpdateDeny(
void
); |
...
The application can register an optional callback function to take control of
some aspects during firmware update. If the application does not register a callback function, the communication module will
reboot when firmware reception is done.
...
Firmware transmission is done using a an RPC request.
| Code Block |
|---|
/* start firmware update */
if (GOAL_RES_OK(res)) {
res = appl_ccmFwUpdateStart(pBufFw, fsize);
} |
It requires the address of the firmware data, which must be located in memory. This
data must contain the data from the bundle file ir45_2port.bin.
...
The ccm module can be reset by the application controller. During a firmware
update process this reset must not be performed. During the performing of the
firmware update by the bootloader and commit step by the application, the
module will not be communicating over the SPI interface. Thus the communication
from the application controller to the ccm module can only be established
when the firmware update process is done.
...