CC2642R: What is the true starting address that the user program stores when the cc2642r1f is doing an OTA upgrade?

Hi Cherry,

I have assigned this thread to a relevant expert and they will be in touch shortly.

Best Regards,

Jan

Hey Cherry,

Are you inquiring about on chip or off chip oad?

Cherry Zhou said:

So what is the starting address for the first packet to write to flash after receiving the bin file data from the mobile app?

I imagine this is application dependent. It may be beneficial to take a look at oad.c where this logic exists. I would take a look at oadImgIdentifyWrite() in particular. Below is a code snippet from this file after the OAD image is validated and the copy process is being prepared for:

// If image ID is accepted, set variables and pre-erase flash pages
    if(idStatus == OAD_SUCCESS && verifStatus == OAD_SUCCESS)
    {

        if(!useExternalFlash)
        {
            imageAddress = 0;
            imagePage = 0;
            metaPage = 0;
        }
        else
        {
            ImageSizeInfo_t extFlInfo[OAD_EFL_MAX_META] = {0};

            // Warning: oadFindExtFlMetaPage needs to be called first
            // to populate the imageInfo structure.
            oadFindExtFlMetaPage(&metaPage, extFlInfo);
            // oadFindExtFlImgAddr will find a suitable region
            // based on ext meta
            imageAddress = oadFindExtFlImgAddr(extFlInfo , idPld->len);
            imagePage = EXT_FLASH_PAGE(imageAddress);
        }

If you connect just the application to the debugger, you can pause the debugger at this point to find the contents of imageAddress, which is what I believe you are inquiring about (from an off-chip OAD perspective).

Cherry Zhou said:

2) Each page for CC2642 is 8k, meaning that the first page cannot be used to hold the user program?

I don't suspect this is the case.

Cherry Zhou said:

3) write flash, is it required to write the entire page? Or can write it alone, erase it all?

I believe the default example allows a write to any space, but the example erases entire pages. I see the function eraseFlashPg inside flash_interface_ext_rtos_NVS.

I hope this helps as a start. Please let me know if you'd like some additional clarity on this and I will help answer your follow up questions.

Hey Ammar,

Thanks for your help.

Ammar N said:

Are you inquiring about on chip or off chip oad?

They are using on chip OTA. However, they don't use the official OAD routine and the storage start address is found.

The customer use non-secure mode, so the first page needs to read out the saved interrupt vector before erasing. Read the first 60 bytes with readFlashPg(0,Temp,60); and then print out, unlike the data read with Flash Programr 2.

Also here're 2 more questions: 

1.some addresses starting with flash on the first page of CC2642, are cortex interrupt vectors installed, etc., are they readable or not readable?

2. would these interrupt vectors be wiped off with eraseFlashPg(0)?

Thanks and regards,

Cherry

Hey Ammar,

The flash erasing issue has been resolved, while here's a new condition:

The customer is cropping and writing OTA programs in official persistent_app engineering. Now they find that flash space is not enough. Is it possible to change the default nvs assignment of 2pages to 1page? This gives an extra 8k of flash to write to the downloader. However, after changing the SIZE and persistent_app start addresses in .syscfg and .cmd, it still report the error "addresses overlap".

Thanks and regards,

Cherry

Hey Cherry,

It should be possible to only use 1 nv page. Have you also modified the linker file inside the simple_peripheral_oad_onchip example? You will need to make sure both that project and persistent_app is modified correctly to avoid overlapping segments.

Hey Ammar,

The customer also modified .cmd, .syscfg, and so on in the user program multi_role, but still reported an error.

Ammar N said:

Have you also modified the linker file inside the simple_peripheral_oad_onchip example?

Could you help list the linker file so that they can check one by one and confirm the overlapping?

Also, after nvs only assigns 1 page=0x2000, does the SNV_ID range: 0x100~0x11F need to be changed?

Thanks and regards,

Cherry

Hey Cherry,

Let me try this out on my end and I can follow up with some instructions. I hope to have a reply by Tuesday of next week.

Hey Ammar,

Thanks.

The customer just followed the steps you given except for step 1, and changed 0x00038000 to 0x00034000. And leave nvs allocation 2page=0x4000 unchanged, only compresses user APP space, but it still reports an error.

The file path for the customer, such as .cmd, is the one in the development engineering that was backed up to the engineering directory, instead of the default path of the installation. Will this be an issue?

Thanks and regards,

Cherry

Hey Cherry,

Cherry Zhou said:

The file path for the customer, such as .cmd, is the one in the development engineering that was backed up to the engineering directory, instead of the default path of the installation. Will this be an issue?

As long as the customer points to the correct linker file by modifying the project properties, this should be ok.

Cherry Zhou said:

The customer just followed the steps you given except for step 1, and changed 0x00038000 to 0x00034000. And leave nvs allocation 2page=0x4000 unchanged, only compresses user APP space, but it still reports an error.

To use one page NV, I would make sure to define the predefined symbol and set it to 1 as stated. What is the motivation to reduce the start address by 0x4000? The persistent app will save 0x2000, and then you must also make a similar change on the other side (simple_peripheral app) and you can save another 0x2000.

To help me understand better, does the customer only want to save space in the persistent app?

I'm a bit confused as the screenshots provided show Region base at 0x30000, why is this?

Hey Ammar,

Ammar N said:

To help me understand better, does the customer only want to save space in the persistent app?

The customer actually is wanting to expand the persistent app space, which is not enough to write OTA private protocol program.  And the user app space was redundant. So they want to compress the user's APP flash space for the persistent app project. They move the 16k(=0x4000)flash space for the persistent app. 

Ammar N said:

I'm a bit confused as the screenshots provided show Region base at 0x30000, why is this?

This Region Base at 0x30000: is by a small shift of 0x34000 to 0x4000.

nv still uses the default 2 page.

Thanks and regards,

Cherry