B&R firmware update

[Romain Naour]

Hello

Is it possible to update B&R module firmware through the EPL stack (v1.8.2) ?
What is the procedure for updating in this way ?

The MN is under Linux connected to an X20BC0083 bus controller.
There is an X20DO6322 connected on the X2X bus that needs to be updated.

What about of the "Firmware Upgrade Manager" in the road map ?

Thank you
Romain

[Wolfgang Seiss]

Hi Romain,

There are two parts of the topic:
1) Update of a POWERLINK device
2) Update of a modular device within a POWERLINK device (second level bus)

Part 1 can be addressed with a firmware update manager, as described also in the EPSG DS301 specification. Unfortunately, this feature has not been integrated in the stack yet and still remains unplanned.

Part 2 is different as from POWERLINK point of view the device on the bus is the Bus Controller, and everything behind it is manufacturer specific - meaning not covered by the generic POWERLINK specification. You'd find information about the manufacturer specific implementation in the B&R X20 Bus Controller manual (see B&R homepage).

Best regards,
Wolfgang

[Romain Naour]

Hi Wolfgang,

Thank you for your explanation.

For the moment I work on the Part 2 with an upgrade application.
I am able to load a new firmware on X20DO6322 module but it is not 100% reliable.
I contacted B&R directly for have more infos.

I am also interested in the update of a POWERLINK device (CN).
Have you some advice on the implementation of firmware update manager ?
What are the parts to be modified to implement the firmware update manager ?

I suppose the CN must be on specific state (CsPreOperational1 ?) before send the firmware to the index 0x1F50.

I am analysing the updating process between an X20CP1586 and X20BC0083 to understand what happen.
This is currently the only way to upgrade the CN.
I'll try to reproduce the same process but it may be specific to B&R device.

Best regards,
Romain

[Romain Naour]

Hi Wolfgang,

I'm still working on updating the B&R firmware module.
Durring update, the MN return an SDOevent with kEplSdoComTransferLowerLayerAbort state,
because SDO transmission reaches the timeout EPL_SEQ_DEFAULT_TIMEOUT (5sec)

On Wireshark we can see the problem on 5th frame segment durring an segmented transfer :

718 14.144944000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 4

727 14.344991000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 5

The CN answering to the 5th frame with an "retransmission request"

736 14.544416000    Bernecke_16:e5:84   EPLv2_ASnd  EPL 60  ASnd   src =   1   dst = 240   SDO   
SendSequenceNumber: 4 "Error Response (retransmission request)"

The MN resend the 5th frame again

745 14.745005000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 5

754 14.944430000    Bernecke_16:e5:84   EPLv2_ASnd  EPL 60  ASnd   src =   1   dst = 240   SDO   
SendSequenceNumber: 4 "Error Response (retransmission request)"

and again...

763 15.145018000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 5

772 15.344444000    Bernecke_16:e5:84   EPLv2_ASnd  EPL 60  ASnd   src =   1   dst = 240   SDO    
SendSequenceNumber: 4 "Error Response (retransmission request)"

781 15.545032000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 5

790 15.744459000    Bernecke_16:e5:84   EPLv2_ASnd  EPL 60  ASnd   src =   1   dst = 240   SDO     
SendSequenceNumber: 4 "Error Response (retransmission request)"

799 15.945048000    Bernecke_19:ed:da   EPLv2_ASnd  EPL 286 ASnd   src = 240   dst =   1   SDO   Requ. Segment
SendSequenceNumber: 5

At this point, CN ack the 5th frame but the transmission is not continued by the MN.

808 16.144474000    Bernecke_16:e5:84   EPLv2_ASnd  EPL 60  ASnd   src =   1   dst = 240   SDO   
SendSequenceNumber: 5

... nothing during 5sec

Why transmission is interrupted by the MN following the CN ack ?

You can find in attachment the wireshark trace.

Thank you
Romain

[Wolfgang Seiss]

Hi Romain,

You are right. It seems, the MN's SDO stack is stuck after receiving the ACK instead of sending the next segment(s).

Maybe you can add some code snippets on how you implemented the SDO Write?
(E.g. where are you calling the write? Are you receiving any events in the event callback...)

Best regards,
Wolfgang

[Romain Naour]

Hi Wolfgang,

I'm calling EplApiWriteObject() from an user application through /dev/epl

tEplSdoComConHdl SdoComConHdl;
unsigned int uiSize = 2;
EplRet = EplApiWriteObject(&SdoComConHdl, 0x01, 0x2103, 0x23, pbBuffer, FwSize, kEplSdoTypeAsnd, NULL);
if (EplRet == kEplApiTaskDeferred)
{   // SDO transfer started
    printlog("kEplApiTaskDeferred\n");
    EplRet = kEplReject;
}
else if (EplRet == kEplSuccessful)
{   // local OD access (should not occur)
    printlog("AppCbEvent(Node) write to local OD\n");
}
else
{   // error occurred
    printlog("AppCbEvent(Node): EplApiWriteObject() returned %s 0x%02X\n", EplGetEplKernelStr(EplRet), EplRet);
    EplRet = EplApiFreeSdoChannel(SdoComConHdl);
}
break;

As expected, EplApiWriteObject() return kEplApiTaskDeferred

2013/06/21 13:08:09 - kEplApiTaskDeferred

And after a few seconds I get another SDO event

2013/06/21 13:08:17 - AppCbEvent(SDO=0x1, SDO event)
2013/06/21 13:08:17 - 0x2103/0x23 finished with 1272 bytes transfered
2013/06/21 13:08:17 - (Abortcode: 0x5040000 Handle: 0x63 State: 0x5 Transfer aborted by lower layer)

After the CN Ack, the last two SDO event in the EPL stack is :

[10919.957160] EplSdoAsySequ: StateConnected kAsySdoSeqEventFrameRec
[10924.960056] EplSdoAsySequ: StateConnected kAsySdoSeqEventTimeout

Thank you
Romain

[Romain Naour]

Hi Wolfgang,

The problem seems to be related to the size of SDO history (EPL_SDO_HISTORY_SIZE = 5), the cycle time and the size of the firmware.

As a workaround, I can use an EPL CycleLen of 300ms instead of 100ms or change EPL_SDO_HISTORY_SIZE to 10.

But the wireshark trace is weird...
The last frame is sent eight times !

You can find in attachment the wireshark trace.
(EPL_SDO_HISTORY_SIZE = 10, EPL CycleLen = 100ms)

Regards
Romain

[Romain Naour]

Hi Wolfgang,

I fixed the problem by removing the SdoState change in EplStack/EplSdoAsySequ.c
When the SdoState is in "WaitAck" state and an "Error Ack" frame is receved,
the SdoState doesn't be reset to "Connected".

Where can I send you the patch ?

Here are the corresponding wireshark trace

Regards,
Romain

[Wolfgang Seiss]

Hi Romain,

Can you please fork the openPOWERLINK git repo into your user account and provide the patches via a bug fix branch?

Thanks,
Wolfgang

[Romain Naour]

Hi Wolfgang,

You can find my git repo at http://sourceforge.net/u/kubu/openPOWERLINK/

Let me know if you have any comments.

Thank you,
Romain

[Wolfgang Seiss]

Hi Romain,

Thanks! We'll have a look at it and come back to you if questions arise.

Regards,
Wolfgang

[Romain Naour]

Hi Wolfgang,

I noticed that my previous patches have been added for the next openpowerlink release.
Thanks !

Two other patches have been added in my v1.8.3-bug-fix branch.
The last one fix kernel oops when the ethernet cable is not connected.

Regards,
Romain

[Wolfgang Seiss]

Hi Romain,

Your additional patches will be included in the next official version. The release will be done within the next days.

Thanks for your support,
Wolfgang

[Ole]

Hi
Regarding 2) Update of a modular device within a POWERLINK device (second level bus)

Is there any open source application that can do this, or could any of you share some information on how to do this?

[Romain Naour]

Hi Ole,

There are no application currently available but I'm able to update my X20 and X67 B&R Powerlink device without a CPU B&R :)

For that you need the latest version of the openpowerlink stack wich include my patch "[FIX] Fix NoAck during segmented transfer"

Then, you need to open a firmware and send it to index 0x1F50/01 for a CN
or index/35 (ex 0x2101/35) for a module device.

The update process is long especially for the X20BC0083 and X20SM1436 devices.
I have tested several cycle time, I recommend you to use at least 100ms as cycle time.

You can easily start from the demo_mn_console code.

My code is specific to linux (kernel stack) and it is not ready to be released (it is a prototype)

I hope this will help you
Best regards,
Romain Naour

[Ole]

Thank you for your feedback. Where do you add the code for upgrading the FW?

[Thomas A Gatliff]

Any update on the steps to updating the firmware of the X20 cards? Even a basic procedure would be very much appreciated.

[Romain Naour]

Hi Thomas, Ole

You can start hacking the demo_mn_console code to implement your firmware updater :)
Here are the steps required to update B&R modules:

0) I suppose all B&R firmware (*.fw) are copied from FieldbusDeigner to a firmware directory.

1) Depending on your hardware configuration, you need to create a specific cdc file.
I suppose you have only one CN and several X20 modules behind.
The cdc need only to have the B&R vendor part in order to initialize the second level bus (X2X bus).
I recommand to use a long cycle > 100ms

2) Since the firmware update is a maintenance operation, there is no need to initialize entierly the OpenPowerLink bus.
So, you can stop the initialization process in NMT_MS_READY_TO_OPERATE state.
It's safe since all actuators aren't operational :)
"The transmitted data shall be declared invalid by resetting the RD flag"
Thanks to that, you don't need a sync thread, only event thread.

3) At this step, the cdc is loaded and the MN and CN are in READY_TO_OPERATE state.
You can scan your EPL hardware
For each declared CN in the cdc file (index 0x1F81, subindex 1 to 0xFE)
check if node exist and is a CN (bit0 and bit1 are set), if no skip it.
On each CN found (only one for now), read the following indexes:
0x1018/1 (VendorID) if not 0x0100006C (B&R ID) skip it.
0x1018/2 (ProductCode)
0x1018/3 (Revision)
0x20F0/2 (bootFirmwareVersion)
0x20F0/3 (UpgradeFirmwareVersion) (may be 0)
0x20F0/5 check if bootFirmwareVersion is active
0x20A0/0 Read how many modules are present in cdc
0x20A1/0 Read how many slots are physicaly present
0x20A2/0 Read how many modules are ready

4) For each MOD_SlotCount
0x21xx/10 Get module status
0x21xx/7 Get module HardwareId
0x21xx/17 Get module FirmwareVersion
0x21xx/18 Get module HardwareVariant

5) At this step, you know all info from your B&R hardware.

6) You need to find the matching firmware file (*.fw) in the firmware directory.
For that, you need to open the firmware file and check the firmware version in the xml part. (see hexdump -n 300 -C foo.fw)

7) A matching firmware file is found and is newer than the one on X20 module
Send it to index 0x1F50/01 for a CN or index/35 (ex 0x2101/35) for a module device.

8) wait

9) At the end of update process, you need to restart the OpenPowerLink bus.

10) You can check if the update is sucessful by checking again the UpgradeFirmwareVersion index on each updated modules.

Best regards,
Romain