• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 40 subscribers
  • Views 540 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC3200: Error : "CdnClient_Run: Create/Open for write file /sys/mcuimgA.bin" in OTA download followed by SFlash filesystem...

CC3200: Error wth the OTA download leading to SFlash filesystem corruption

bhupendra prajapati
Intellectual 400 points
Part Number: CC3200
Other Parts Discussed in Thread: UNIFLASH,

Hi There!

We are facing an issue with the OTA download of the firmware binary image for the second time i.e. downloading /sys/mcuimg3.bin via OTA update.

Describing the issue a bit,  the freshly flashed firmware i.e. /sys/mcuimg1.bin downloads the updated firmware /sys/mcuimg2.bin smoothly and runs the new firmware after rebooting fine. But when this new firmware attempts to download the updated firmware further, it fails in opening/creating the file  /sys/mcuimg3.bin with an error _OpenStorageFile: error in pOpenFile, status=-3. and this corrupts the SFLASH file-system requiring us to format and flash it again, manually.

PS: For the sake of testing, we are using the same firmware image for all the updates i.e. all the mcuimg1, 2, and 3 are the same.

I would request you to refer my previous related thread for the same problem, though we were getting this error very rarely earlier but it was not solved. In our latest firmware, we have made a few changes  but they are not related to the OTA logic, means the OTA logic is intact as of previous FW version where this error was rare but persistent. But now, with the new firmware this error is very frequent and we get it every time.

For your information, the changes in the new firmware are as below:

1. Earlier our device was reading the data from the daughter boards over SPI in polling mode, but now in the new firmware, we have modified it to read data and POST it based on a timer interrupt. The new firmware solves its purpose effectively and runs smoothly but also with the above error in the OTA which is unchanged.

I am attaching the terminal log of our device for both the success case followed by the failure case, please have a look and suggest us some work around for the issue.

1. Success with /sys/mcuimg2.bin

Available Updates : Device FirmWare
Starting OTA
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=ota.orxa.io
OtaClient_ConnectServer: http_connect_server ota.orxa.io
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=SE201804
OtaClient_UpdateCheck: call http_build_request /api/file/List_Folder
CdnDropbox_SendReqDir: uri=/api/file/List_Folder
    metadata file=/SE201804/f20_sys_config.json, size=361
    metadata file=/SE201804/f80_sys_mcuimgA.bin, size=146872
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=2
pOtaApp->file_path: /SE201804/f80_sys_mcuimgA.bin
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/SE201804/f80_sys_mcuimgA.bin, size=146872
OtaClient_ResourceMetadata: call http_build_request /api/file/get_temporary_link
OtaClient_ResourceMetadata: file flags=80,metadata flags=80
CdnDropbox_SendReqFileUrl: uri=/api/file/get_temporary_link
sl_extLib_OtaRun: ResourceMetadata CDN file URL = ota.orxa.io/.../SE201804`f80_sys_mcuimgA@bin
_ReadFileHeaders: domain=ota.orxa.io, file=/api/File/download/SE201804`f80_sys_mcuimgA@bin
_ReadFileHeaders: skip http headers
CdnClient_Run: Create/Open for write file /sys/mcuimgA.bin
_McuImageGetNewIndex: active image is 0, return new image 1
sl_extlib_FlcOpenFile: MCU imagename converted to /sys/mcuimg2.bin
CdnClient_Run: file opened
CdnClient_Run: Write size 1440 to file /sys/mcuimg2.bin total 0.
CdnClient_Run: Write size 1440 to file /sys/mcuimg2.bin total 1440.
CdnClient_Run: Write size 1440 to file /sys/mcuimg2.bin total 2880.

// removed for the sake of sanity!

CdnClient_Run: Write size 1440 to file /sys/mcuimg2.bin total 142560.
CdnClient_Run: Write size 1440 to file /sys/mcuimg2.bin total 144000.
CdnClient_Run: Write size 1432 to file /sys/mcuimg2.bin total 145440.
CdnClient_Run: End of file
CdnClient_Run: Downloading File Completed - Size=146872
sl_extLib_OtaRun: ---- Download file completed /sys/mcuimg2.bin
pOtaApp->file_path: sl_extLib_OtaRun: -------- end of updates
OtaRun returned : 2
sl_extlib_FlcTest: change image status to IMG_STATUS_TESTREADY
ReadBootInfo: ucActiveImg=0, ulImgStatus=0xabcddcba
WriteBootInfo: ucActiveImg=0, ulImgStatus=0x56788765
_OtaCleanToIdle: close OTA client and CDN client and back to IDLE
OTA: NEW IMAGE DOWNLOAD COMPLETE
ErorrLog.txt Size = 57 KB
Connection to server created successfully
HTTP Post to ota.orxa.io/api/DeviceStats/OTAStatus returned 200 OK!
Rebooting...

2. The device and reboots fine, followed by committing the new firmware and continues working.

ReadBootInfo: ucActiveImg=0, ulImgStatus=0x12344321
EXTLIB_OTA_GET_OPT_IS_PENDING_COMMIT? 1
OTA: PENDING COMMIT & WLAN OK ==> PERFORM COMMIT
ReadBootInfo: ucActiveImg=0, ulImgStatus=0x12344321
sl_extlib_FlcCommit: Booted in testing mode.
WriteBootInfo: ucActiveImg=1, ulImgStatus=0xabcddcba
Commit Success!

3. Failure logs with /sys/mcuimg3.bin:

OTA server info is set!
Available Updates : Device FirmWare
Starting OTA
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=ota.orxa.io
OtaClient_ConnectServer: http_connect_server ota.orxa.io
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=SE201804
OtaClient_UpdateCheck: call http_build_request /api/file/List_Folder
CdnDropbox_SendReqDir: uri=/api/file/List_Folder
    metadata file=/SE201804/f20_sys_config.json, size=361
    metadata file=/SE201804/f80_sys_mcuimgA.bin, size=146872
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=2
pOtaApp->file_path: /SE201804/f80_sys_mcuimgA.bin
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/SE201804/f80_sys_mcuimgA.bin, size=146872
OtaClient_ResourceMetadata: call http_build_request /api/file/get_temporary_link
OtaClient_ResourceMetadata: file flags=80,metadata flags=80
CdnDropbox_SendReqFileUrl: uri=/api/file/get_temporary_link
sl_extLib_OtaRun: ResourceMetadata CDN file URL = ota.orxa.io/.../SE201804`f80_sys_mcuimgA@bin
_ReadFileHeaders: domain=ota.orxa.io, file=/api/File/download/SE201804`f80_sys_mcuimgA@bin
_ReadFileHeaders: skip http headers
CdnClient_Run: Create/Open for write file /sys/mcuimgA.bin
_McuImageGetNewIndex: active image is 1, return new image 2
sl_extlib_FlcOpenFile: MCU imagename converted to /sys/mcuimg3.bin
_OpenStorageFile: error in pOpenFile, status=-3
CdnClient_Run ERROR: pCdnClient->pOpenFileCB
sl_extLib_OtaRun ERROR: Failed on CdnClient_Run
OtaRun returned : -7
OTA: Error -7 with OTA server!

 Please help us resolving the issue

Thanks and regards.

Bhupendra Prajapati.

  • 0
    TI__Guru 63006 points

    Hi Bhupendra,

    Is this the first OTA that you perform?

    -3 (SL_FS_ERR_INVALID_MAGIC_NUM) typically comes when trying to open a file that was not closed correctly, but if this is the first OTA then mcuimg2.bin was not created before.

    The other possible reason for the error (indicating flash corruption), is if you have stability issues on you Flash SPI interface. Please monitor the interface and make sure there are no power glitches. 

    br,

    Kobi 

  • 0 in reply to Kobi Leibovitch
    Intellectual 400 points

    Hello Kobi,

    No, the error we are getting is in the second OTA download and only with the firmware file,  I tried updating another device configuration file OTA which is very small than the firmware file, and got no issues with that.

    As you may find in the logs I shared, can there be some problem with the firmware binary's file size? We observed earlier in our old firmware it was about 140K but now  the binary size has increased to about 160K.

    Also today we tried updating with the older (smaller) firmware over the new firmware running at the device in the second attempt and found it was downloaded fine, so could it be a size issue?

    But, we have installed 8MB SFLASH and I suppose the file download takes place in chunks of 1440 Bytes.  So can there be any problems with it?

    Regarding the power glitches in the SFLASH SPI interface, I will check that.

    Thank you for your response,

    Best regards.

    Bhupendra.

  • 0 in reply to bhupendra prajapati
    Intellectual 400 points

    Also, to avoid confusion by the "second attempt" I mean that we are doing OTA one more time after it succeeded for the first time. In the second time, it was the first attempt only and no previous failure attempts it made, so there should not be any file by the same name that has not been closed properly.

    I hope I could make it a bit more clear now.

    Thanks again!

    Bhupendra.

  • 0 in reply to bhupendra prajapati
    TI__Guru 63006 points

    Please update the MAX SIZE in uniflash when you create the mcu image.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 400 points

    Hi Kobi,

    What do you mean by increasing the MAX_SIZE in uniflash? Can you please explain it a bit?

    Actually I have never seen this setting in the Uniflash we use for CC3200, we can only see the flash size to be formatted while formatting the SFLASH and as I mentioned, we have 8MB of flash so we always choose it to be 8MB. Is that what you mean?

    Or by creating mcuimg before flashing, are you relating it to the new version of Uniflash we use for CC3220? But that is not our case right we are using older Uniflash and we directly flash the binary built by the CCS IDE via Uniflash.

    Please tell me if you meant something else.

  • 0 in reply to bhupendra prajapati
    TI__Guru 63006 points

    Check the "CC32xx MCU image flashing (CC3200 only)" section  in

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 400 points

    Okay, thanks for providing the reference!

    I have read the section you mentioned, Just one more question on it. The said section says: " Mode: nothing is checked, indicating a non-secured image. Rollback is mandatory in order to support OTA (non-configurable by the user)."

    Whereas  I read in the known issues link, that we need to keep all the firmware files to be  "non fail-safe" but as per the wiki link you provided, keeping the rollback flag checked makes the mcuimg fail safe at the time we program it. It seems contrary. What would you recommend me to follow?

    The rest of the suggestions I will try them tomorrow and let you know the results.

    Thank you very much for the answers!

    -Bhupendra.

  • 0 in reply to bhupendra prajapati
    TI__Guru 63006 points

    The rollback support was added for future reference, but fail-safe was not implemented on CC3200.

    You can support fail-safe and rollback for the MCU image update by using the FLC library.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Intellectual 400 points

    Hello Kobi,

    I tried keeping the "Rollback" flash unchecked in Uniflash while flashing the image and it worked for us. We are able to download it fine!

    Thank you for your support!

    much appreciated!

    Bhupendra Prajapati.