Firmware upgrade using FSI - buffer allocation size?

EdFrancy · September 24, 2021, 8:09pm

I see that the docs indicate that when doing a write to the Firmware folder that…

“In the firmware folder, it is not possible to use append mode when writing a file. Use
write mode only.”

The file I have to send to the B40 is “ABCC_40_DPV1_7332_1_15_01.hiff” - correct?

That’s a 737K file. Does this mean I must allocate a buffer that large to call ANB_FSI_FileWrite?
(I don’t have this much RAM to Malloc)

Is there a way to do a ‘FileCopy’ or something so that I can do an append (with smaller buffers) and then copy the image over to the Firmware folder?

Thanks,
-Ed

jonc_hms · September 27, 2021, 1:04pm

Hi @EdFrancy,

Does this mean I must allocate a buffer that large to call ANB_FSI_FileWrite?

No, when opening in ABP_FSI_FILE_OPEN_WRITE_MODE the data written to the file will start at the beginning of the file (effectively erasing any preexisting data), versus ABP_FSI_FILE_OPEN_APPEND_MODE which would use the current “end of file” as the starting point for writing new data.

Regardless of which of these file access modes is used, the ABP_FSI_CMD_FILE_WRITE command behaves the same, effectively, it is a data stream.

Each write will move the file instance’s internal “write pointer” forward by the number of bytes “actually written” (this is indicated by the ABCC’s response message and is handled in the FileWriteRsp function in anb_fsi_obj.c). Using a file stream means the host has the flexibility to specify whatever buffer size it wants to (up to 1524 bytes of message data, as specified in the ABCC SW Design Guide). This means the host can iteratively, piece-by-piece send the firmware file data to the ABCC via ANB_FSI_FileWrite and then once completed issue ANB_FSI_Close. At this point the ABCC should be ready to commence with the validation and firmware update process (exact behavior is network specific).

EdFrancy · September 27, 2021, 1:33pm

Phew. Excellent.

Just to confirm, once the entire new file is loaded to the Firmware directory, do I execute the ‘ANB_FSI_InvalidateUploadedAbccFw’ command to start the update, or do I just do a reboot?

(Sounds like that command would invalidate what I just uploaded)

Thanks!

-ed

jonc_hms · September 27, 2021, 2:01pm

Just to confirm, once the entire new file is loaded to the Firmware directory, do I execute the ‘ANB_FSI_InvalidateUploadedAbccFw’ command to start the update, or do I just do a reboot?

As you suggested, ANB_FSI_InvalidateUploadedAbccFw is only for invalidating, thus cancelling the firmware update process. This is mainly intended for a combined firmware file blob approach where a single firmware file contains firmware for both the ABCC and host system. This would be used in a scenario where the host detects a problem during the update/transfer process and it wants to ensure that the ABCC’s firmware update is aborted. Depending on the ABCC’s network type, there are network specific reactions to this type of invalid firmware event (EtherCAT for instance would assert a specific standardize error code). Regardless of the network type, after the function corrupts the firmware candidate, during the next startup the ABCC will detect an invalid firmware candidate thus remaining on the current firmware version.

For DeviceNet and many of the other networks, after closing the file, it is sufficient to reboot the device to start the firmware update process.

Ideally, it is best to confirm that the ABCC has set the Firmware File Candidate file to TRUE and the host has updated it’s non-volatile flag accordingly in the application specific function SetCandidateFirmwareAvailable (this logic resides in the SDK’s ABP_APP_IA_FW_AVAILABLE handler in app_obj.c) before restarting the device. This will ensure that the host application will adjust the startup time of the SDK to permit the update process to complete before trying to communicate with the ABCC (avoiding a timeout condition in the SDK’s startup logic).

EdFrancy · September 27, 2021, 8:41pm

HI,

I’ve got the transfer process going… writing data to the module using the FSI interface.

It appears that the file write is happiest with blocks of only 128 bytes at a time – if I do larger ones it must ‘Execute the same sequence step’ which causes resource issues. I tried increasing the number of messages, but then tried just reducing the block size to 128 bytes to not get the ‘same sequence’. Is this correct? The file is 735K, so 128 byte blocks will take some time to transfer… I feel like I’m missing something here.

-ed

jonc_hms · September 27, 2021, 9:18pm

Is this correct?

After a write, the ABCC may need some time to erase sectors of flash in which case there may be a period of time where further File Write requests are more or less ignored and the ABCC reports 0 bytes written. Perhaps this is in the scenario that you are encountering?

Some other questions/confirmations:

What version of the SDK you are running?
What is ANB_FSI_WRITE_MAX_DATA_LEN set to (in anb_fsi_obj.c)?
Are you using SPI? If so, what is ABCC_CFG_SPI_MSG_FRAG_LEN (in abcc_drv_cfg.h)?
Could you elaborate on what you mean by resource issues?

EdFrancy · September 28, 2021, 2:20pm

Hi Jon,

In good news, the firmware upgrade was successful! (1.7.3 to 1.15.1)

I have these versions right now:

** ABP 7.76.01 (2020-10-19) **

** ABCC Driver 5.07.01 (2020-10-12) **

ANB_FSI_WRITE_MAX_DATA_LEN is 255

ABCC_CFG_SPI_MSG_FRAG_LEN is 16

Once I increased ABCC_CFG_SPI_MSG_FRAG_LEN to 32 the speed was much faster!

Not sure why if I increase the ‘chunk size’ from 128 to 255 I still get the resource error.

I increased ABCC_CFG_MAX_NUM_CMD_SEQ from 2 to 10, but still get the following severe error: (at the end)

Mem: Buffer allocated: 0x80036f1c

CmdSeq(9d07bfe4)->FileWriteCmd()

Command queued: MsgBuf:0x80036f1c SrcId:0x1f

CmdQ status: 2(2)

Outstanding commands: 1

Msg sent:

[ MsgBuf:0x80037b24 Size:0x00ff SrcId :0x1d DestObj:0x0a

Inst :0x0001 Cmd :0x56 CmdExt0:0x00 CmdExt1:0x00 ]

[ 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00

0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00

0x20 0xa9 0x3d 0x00 0x20 0x08 0xb5 0x00 0x20 0x02 0xf0 0x8a 0xfa 0x1e 0xf0 0x04

0x0f 0x0c 0xbf 0xef 0xf3 0x08 0x80 0xef 0xf3 0x09 0x80 0x01 0x49 0x08 0x47 0x00

0x00 0x89 0x3d 0x00 0x20 0x08 0xb5 0x01 0x20 0x02 0xf0 0x7a 0xfa 0x0b 0x4b 0x4f

0xf4 0x00 0x52 0x10 0xb5 0x1a 0x60 0x00 0x24 0x09 0x480x42 0x60x00

0xbf 0x80x20 0x3Mem: BufCommand dequeued: MsgBuf:0x80037520 SrcId:0x1e

CmdQ status: 1(2)

Mem: Buffer allocated: 0x80037b24

Outstanding commands: 0

Msg received:

[ MsgBuf:0x80037b24 Size:0x0000 SrcId :0x1d DestObj:0x0a

Inst :0x0001 Cmd :0x16 CmdExt0:0xff CmdExt1:0x00 ]

[ ]

Routing response to registered response handler: MsgBuf:0x80037b24 SrcId:0x1d

CmdSeq(9d07bfe4)->FileWriteRsp()

Mem: Buffer returned: 0x80037b24

CmdSeq(9d07bfe4)->Done

ANYBUS: Write complete

ANYBUS: Write 256 bytes, 1024 so far

Mem: Buffer allocated: 0x80037b24

CmdSeq(9d07bfe4)->FileWriteCmd()

Command queued: MsgBuf:0x80037b24 SrcId:0x20

CmdQ status: 2(2)

Outstanding commands: 1

Msg sent:

[ MsgBuf:0x80037520 Size:0x00ff SrcId :0x1e DestObj:0x0a

Inst :0x0001 Cmd :0x56 CmdExt0:0x00 CmdExt1:0x00 ]

[ 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00

0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00 0x20 0xa9 0x3d 0x00

0x20 0xa9 0x3d 0x00 0x20 0x08 0xb5 0x00 0x20 0x02 0xf0 0x8a 0xfa 0x1e 0xf0 0x04

0x0f 0x0c 0xbf 0xef 0xf3 0x08 0x80 0xef 0xf3 0x09 0x80 0x01 0x49 0x08 0x47 0x00

0x00 0x89 0x3d 0x00 0x20 0x08 0xb5 0x01 0x20 0x02 0xf0 0x7a 0xfa 0x0b 0x4b 0x4f

0xf4 0x00 0x52 0x10 0xb5 0x1a 0x60 0x00 0x24 0x09 0x480xb1 0x40x00

0xbf 0x80xe0 0x70x23 0x5Command dequeued: MsgBuf:0x80036f1c SrcId:0x1f

CmdQ status: 1(2)

Mem: Buffer allocated: 0x80037520

Outstanding commands: 0

Msg received:

[ MsgBuf:0x80037520 Size:0x0000 SrcId :0x1e DestObj:0x0a

Inst :0x0001 Cmd :0x16 CmdExt0:0xff CmdExt1:0x00 ]

[ ]

Routing response to registered response handler: MsgBuf:0x80037520 SrcId:0x1e

CmdSeq(9d07bfe4)->FileWriteRsp()

CmdSeq(9d07bfe4)->Executing same sequence step again

CmdSeq(9d07bfe4)->FileWriteCmd()

Command queued: MsgBuf:0x80037520 SrcId:0x21

CmdQ status: 2(2)

Outstanding commands: 1

Mem: Buffer allocated: 0x80036918

CmdSeq(9d07bfe4)->FileWriteCmd()

Severity : ABCC_SEV_WARNING

Error code: ABCC_EC_NO_RESOURCES (ErrNo: 25)

Add info : 0 (0x0)

File : …/src/AnyBus/abcc_drv/src/abcc_handler.c (Line:843)

Thanks,

-ed

jonc_hms · September 28, 2021, 3:00pm

Hi @EdFrancy,
Glad you found some success.

Looking at the log I suspect the issue you are running into is a matter of (data) flow control. There is another function that needs to be used in this File Write process for this purpose which I forgot to mention.

The anb_fsi_obj.c unit does not define this very clearly, but you will want to call/check ANB_FSI_GetInstanceLocked(), before attempting to make a call to ANB_FSI_FileWrite(). This check should prevent you from running out of resources and preserving the state of the buffer until the entire payload has been written to the ABCC filesystem.

When ANB_FSI_FileWrite() is called, it sets an internal flag (anb_fsi_fInstanceAccessLocked) which serves as means to prevent another request from being started. It probably would be better to name this flag anb_fsi_fWriteInProgress (and the getter/setter functions similarly) since that is really the only thing this is being used to indicate.

In any case, the way it is currently implemented puts the dependency on the application side so it is perhaps a little prone to (user) error than it would be if the unit handled this logic internally and reported a status code to the application on whether the request was accepted or rejected.

Hopefully this information helps guide you to a better more optimal solution.

EdFrancy · September 28, 2021, 7:29pm

Ah!

The flow control makes sense. I actually added my own (not knowing what ‘instance lock’ meant.

Unfortunately I put mine in the wrong places.

Works much better now.

Couple of quick questions while I have your expert ear.

If I upload a ‘junk’ file – will the module do a reboot and NOT install it? (so I can test the process with a smaller file?) and not be bricked?
Can I upload the same version again and have the module install that? (I need to implement the ‘SetCandidateFirmwareAvailable’ functionality)

Thanks again,

Ed

EdFrancy · September 28, 2021, 8:19pm

One more quick one….

Is there a place online to find old and new firmware packages? (.hiff files)?

-ed

jonc_hms · September 28, 2021, 8:42pm

If I upload a ‘junk’ file – will the module do a reboot and NOT install it? (so I can test the process with a smaller file?) and not be bricked?

After a firmware candidate has been sent to the ABCC’s filesystem there is no automatic reset behavior regardless of a good/bad firmware (an exception for this would be for EtherCAT which has a BOOT–>INIT reset event that will request the host if a device reset can be performed).

If you happen to reset the device after a bad firmware has been sent to the device, the ABCC has sufficient validation checks (i.e. validation of a cryptographic signature, among other checks) that the firmware update process will be aborted and the ABCC remains on the old version. There is also a golden image on the ABCC which should recover from cases where the flashed firmware is bad/corrupted (this may for instance occur if you accidently power cycle the device while the ABCC is re-flashing).

Can I upload the same version again and have the module install that? (I need to implement the ‘SetCandidateFirmwareAvailable’ functionality)

When uploading the same ABCC firmware that is already running on it the ABCC will still treat it as a “FW candidate” but on the next ABCC startup when it commences with FW update it will determine that the candidate version is the same version already loaded. This typically means the firmware update process will be much shorter than normal (I think this is typically around 20 seconds).

Is there a place online to find old and new firmware packages? (.hiff files)?

Currently there is no web interface for this; you should contact your local sales person to get firmware updates.

-Jon

EdFrancy · September 29, 2021, 7:21pm

Jon,

Wanted to thank you for your help over the past few days.

Thanks again.

-ed

jonc_hms · September 29, 2021, 9:14pm

Hi @EdFrancy,
I appreciate the feedback and I am glad I was able to help.