CC2642R: FOTA Implementation using simple peripheral off-chip application

Hi,

I am going to ask the engineer who has supported you last time to comment. May I kindly ask you to specify the SDK version you are using, and any change you may have implemented since your last post?

Best regards,

Hi Clement,

We are using the below mentioned SDK,

SDK : simplelink_cc13x2_26x2_sdk_5_20_00_52 

To access the external flash the below changes we did , 

In simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos_ccs project -> OAD folder -> Instead of "flash_interface_ext_rtos_NVS.c" file we are using "flash_interface_ext_rtos.c" to access external SPI flash as per TI suggestion.

In project "simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos_ccs project" By default  "flash_interface_ext_rtos_NVS.c" file were used but now we replaced the file with "flash_interface_ext_rtos.c", "ExtFlash.c", "ExtFlash.c" files to access External SPI flash. .

Hey Mohan,

I think you're close to answering your questions and I will try to help. If the image size is not entirely transferred over, then a CRC error can occur.

mohan prasanna R said:

1) What are the elements you are considering to calculate CRC32 checksum.

For details, see the crc32.c file inside the OAD folder in the project.

mohan prasanna R said:

2)  we are using same .bin image for Firmware up-gradation and we are observing   the length of block size which is available in the Header structure also differing In EVK and customised board . Block size is 60 bytes and total no of block transferred from mobile app to target board is  2181.

For this and #3, I suspect there is an issue setting up the custom external flash interface, which could explain the differences between the EVK and the custom board. Can you walk me through the changes that were done?

Hey Ammar N,

SDK USED : simplelink_cc13x2_26x2_sdk_5_20_00_52

HARDWARE USED:  EVK BOARD CC2642

SOFTWARE USED : simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos , Bim_offchip

In simple_peripheral_oad_offchip_CC26X2R1_LAUNCHXL_tirtos_ccs project -> OAD folder -> When we are using "flash_interface_ext_rtos_NVS.c"  and "flash_interface.h" to acces the external flash, the firmware image upgrade through BLE is working fine.

But, as discussed earlier, we replaced the file with "flash_interface_ext_rtos.c", and "ExtFlash.c" files to access External SPI flash in the EVK board.

In ExtFlash.c, instead of using  PIN_setOutputValue() we are using GPIO_write() for pin select and deselect.

then to access the spi external flash the following API are working fine.

1) flash_open - To open the SPI external flash

2) flash_close - To close the SPI external flash

3) readFlashPg - To read data from the SPI external flash using Page

4) readFlash - To read data from the SPI external flash using Address

5) writeFlashPg - To write data from the SPI external flash using Page

6) writeFlash - To write data from the SPI external flash using Address

7) eraseFlashPg - To erase selected page 

i) we have a 1st observed that candidate length was differing from 122108 -> 125900 without any changes in code for selecting same firmware from mobile app ,how the length was differing?  due to these changes total block was differing from  2181 to 2249. 

ii) We observed that the total no of blocks that need to transfer from the mobile app to the target board is  2249 for a Firmware image to be upgraded. when it checks during the OAD FW upgrade completes transferring from mobile app to external flash as per the below validation,

by " if (OAD_SUCCESS != oadCheckDL())" in oad.c. In oadCheckDL() the crc value from header and the downloaded crc value are differing for extflash 

For NVS:

 crcCalculated = CRC32_calc(imagePage, EFL_PAGE_SIZE, 0,  imgHdr.fixedHdr.len, useExternalFlash);

imagePage: 35
EFL_PAGE_SIZE = 0x1000
len:125900
useExternalFlash:1

For EXTFLASH:

 crcCalculated = CRC32_calc(imagePage, EFL_PAGE_SIZE, 0,  imgHdr.fixedHdr.len, useExternalFlash);

imagePage: 4
EFL_PAGE_SIZE = 0x1000
len:-1
useExternalFlash:1

Hey Ammar N,

We are struck here Please support us.

Hey Mohan,

Apologies for the delay.

mohan prasanna R said:

For EXTFLASH:

 crcCalculated = CRC32_calc(imagePage, EFL_PAGE_SIZE, 0,  imgHdr.fixedHdr.len, useExternalFlash);

imagePage: 4
EFL_PAGE_SIZE = 0x1000
len:-1
useExternalFlash:1

The len (which I assume here is imgHdr.fixedHdr.len) is an invalid value here. I would try to investigate why that is through debugging.

But first, can you confirm the contents of the external flash are written the same for the NVS instance and the ExtFlash instance? Any discrepancy in memory here will probably impact the issue here. You can use a logic analyzer to check if the same data is being read by the NVS/ExtFlash, or dump the contents to UART and print them out (however you find easier).

mohan prasanna R said:

then to access the spi external flash the following API are working fine.

You mention the API's that are working correctly, however, can you verify that the call to extFlashVerifyPart is successful and that the correct flashInfo[] index is recognized for your new part? I expect index 0 since you mentioned you are using an MX25R1635F.

Yes, we verified that extFlashVerifyPart is successfully recognized the correct devID, and deviceSize. the following flashinfo[] is taken for the process

.manfId = MF_MACRONIX, // Micronics
.devId = 0x15, // MX25R1635F
.deviceSize = 0x200000 // 2 MByte (16 Mbit)

Then we confirmed that the same instance was written in NVS and Extflash. The length is found correct now as 122108. 

Now,
 oadFindExtFlMetaPage(&metaPage, extFlInfo);  -> return as MetaPage for NVS = 1 and for extflash =3

imageAddress = oadFindExtFlImgAddr(extFlInfo , idPld->len);   ->for NVS image address = 266240 and for EXTFLASH =16384

imagePage = EXT_FLASH_PAGE(imageAddress); -> for NVS image page = 65 and for EXTFLASH image page =4

QUERIES:

i)How the meta page differed from each other?
NVS : 1 & EXTFLASH : 3

ii)We checked the CRC page by page, in which we found that 1st 4096 byte(1st page) has same CRC for NVS and EXTflash, but for next page differs , How it differs?

For NVS:

 crcCalculated = CRC32_calc(imagePage, EFL_PAGE_SIZE, 0,  imgHdr.fixedHdr.len, useExternalFlash);

imagePage: 65
EFL_PAGE_SIZE = 0x1000
len:122108
useExternalFlash:1

For EXTFLASH:

 crcCalculated = CRC32_calc(imagePage, EFL_PAGE_SIZE, 0,  imgHdr.fixedHdr.len, useExternalFlash);

imagePage: 4
EFL_PAGE_SIZE = 0x1000
len:122108
useExternalFlash:1

Hey Mohan,

The difference between the NVS instance and EXTFLASH is that the NVS instance calls NVS_read() with EXT_FLASH_ADDRESS() passed in as an argument. For the EXTFLASH instance, ExtFlash_read() is called with FLASH_ADDRESS() passed in. These two macros are resolving to different flash addresses:

#define FLASH_ADDRESS(page, offset)     (((page) << 13) + (offset))
.
.
.
/*!
 * MMacro to return an address based on an external flash page and offset into
 * the page
 */
#define EXT_FLASH_ADDRESS(page, offset)     (((page) << 12) + (offset))

This is the reason for the discrepancy, including the CRC calculation. I will need to investigate this further. In the meantime, please try using EXT_FLASH_ADDRESS instead (by modifiying flash_interface_ext_rtos.c) to see if this resolves the issue.

Hey Ammar,


As per your reference Now in the EXTFLASH instance, the firmware image's CRC is matched with CRC from the header. The downloading process is 100% completed.

After the downloading process, the device gets rebooted and reads the downloaded image through BIM OFFCHIP.

Now in the BIM OFFCHIP file,  Bim_checkImages() >>> It tried to fetch the data in External flash by the checkImagesExtFlash() function but it gets failed.

So, it fetches the data in the Internal flash by the checkImagesIntFlash() function, and the image in the internal flash gets booted instead of the image in the external flash.

/* check BIM and Metadata version */
        if((metadataHdr.fixedHdr.imgCpStat != NEED_COPY) ||
           (metadataHdr.fixedHdr.bimVer != BIM_VER  || metadataHdr.fixedHdr.metaVer != META_VER) ||
           (metadataHdr.fixedHdr.crcStat == CRC_INVALID))  /* Invalid CRC */
        {
            flashPageNum += 1; /* increment flash page number */

            continue;          /* Continue search on next flash page */
        }

the above statement was failing.

here we want to read data from external flash so kindly support us.

mohan prasanna R said:

As per your reference Now in the EXTFLASH instance, the firmware image's CRC is matched with CRC from the header. The downloading process is 100% completed.

This is great news, we're one step closer!

Have you been able to verify the contents in the external flash? Can you read out the contents and inspect them to see if the header has been copied over?

If the contents are there, then I would suggest stepping through the code to see if the BIM is skipping over pages. There are some defines in flash_interface.h that should be modified to your external flash so that the BIM also correctly searches the entire flash. For the bim_offchip example, it references flash_interface.h from its location in the source SDK (i.e. source/ti/common/cc26xx/flash_interface/flash_interface.h).

Hi Ammar,
 

The application SimpleLink Starter  ( Version 5.12.2      Build 98) is not responding. Previously it was working fine , right now the application can read the BLE device's advertisement . once after connecting, at select image page, it displays that TI EOAD Client waiting for MTU Update , and the application couldn't process to open Google drive where we use to select the image that need to be flashed.

I have attached the photo copy of the applications's response for your reference.

kindly check on the same and update asap.

Hey Mohan,

I would recommend restarting Bluetooth on the mobile phone and delete any stale bonding information on both sides to reset the app. If this does not work, I would try using BTOOL as the OAD distributor using another CC26x2.

Hey Ammar,

After resetting the mobile application, Now the simple link starter application was working properly.

New Querry :

Now by using the EXTFLASH interface lib instead of NVS lib, We are facing a problem with reading a image from bim after completion of  100 % download from the mobile app.

In OFF chip application after completion of 100% upgrade image It enters into the OAD_COMPLETE state
In this state, event is OAD_EXT_CTRL_WRITE_CMD it enters into >> oadProcessExtControlCmd() -> case OAD_EXT_CTRL_ENABLE_IMG: 

(Here NEED_COPY status is updating on external flash by using writeflashpg API. Arg:metapage - 1, offset - 0, header buffer, size of buffer)

After writing the NEED_COPY status we are read backing the same by using readflashpg with the same metapage as 1 and offset as 0. but we are getting 0xFF(Default state) instead of 0xFE(NEED_COPY state). because of this In the bim_offchip app while it is reading the copy status from externalflash it is reading as 0xFF instead of 0xFE. So, It is skipping to copying from external flash and entering into the inter flash(Old code). 

(here we assumed that writeflashpg was not properly written but other than this upgraded image which is downloaded from mobile app was writing properly)

extFlMetaHdr.fixedHdr.imgCpStat = NEED_COPY;
extFlMetaHdr.fixedHdr.crcStat = CRC_VALID;
eraseFlashPg(metaPage);


writeflashpg API:

(writeFlashPg(metaPage,0,(uint8_t *)&extFlMetaHdr,sizeof(ExtImageInfo_t)) == FLASH_SUCCESS)

readflashpg API
readFlashPg(metaPage,0,(uint8_t *)&extFlMetaHdr_VVDN,sizeof(ExtImageInfo_t)

Please support us How can we get like this? 

(Note: We debugged the bim_offchip by led debugging)

Hey Mohan,

Are you reading back the flash page directly after the writeFlashPg call? What are the statuses of both the writeFlashPg and readFlashPg API calls? I would expect the readFlashPg API call to return the values written in the prior writeFlashPg call.

When stepping into the writeFlashPg calls, can you confirm that the EXTFLASH lib function is what is called, i.e. ExtFlash_read()?