LAUNCHXL-CC26X2R1: Getting CRC mismatch for CCFG While Erasing Using Sector Erase

Hi ARUL,

Previous post: https://e2e.ti.com/f/1/t/1417833 

Are you able to provide the SBL commands and contents you use to write the CCFG and calculate the CRC32 for both matching and mismatching cases?  How are you calculating the CRC32 to check against the returned value?

Regards,
Ryan

Hi Ryan,

thanks for your response, For Sector Erase (0x26),

Content to Write CCFG is attached in the Image.

devCrc_CCFG -->CRC from TI chip

fileCrc_ccfg -->CRC from IMXRT.

from 56000 to 58000 fileCrc_ccfg value = afc6ea16 ,devCrc_CCFG = afc6ea16 (Working Case).

for 57fa8 to 58000, fileCrc_ccfg value = 29d265db ,devCrc_CCFG = 57fa8 (Not Working Case).

Let me know if any other things are Required 

Thanks

Thanks, I am also curious about the contents of your COMMAND_CRC32 (0x27) packet for each case.

Can you confirm that the IMXRT calculates the CRC in the exact same way as the CC2652R1 SBL?  Below is an excerpt from the sblAppEx explained inside of SWRAA466.  Does this happen only to the CCFG or for other sections of memory as well?

// Calculate crc32 checksum the way CC2538 and CC2650 does it.
int calcCrcLikeChip(const unsigned char *pData, unsigned long ulByteCount)
{
    unsigned long d, ind;
    unsigned long acc = 0xFFFFFFFF;
    const unsigned long ulCrcRand32Lut[] =
    {
        0x00000000, 0x1DB71064, 0x3B6E20C8, 0x26D930AC, 
        0x76DC4190, 0x6B6B51F4, 0x4DB26158, 0x5005713C, 
        0xEDB88320, 0xF00F9344, 0xD6D6A3E8, 0xCB61B38C, 
        0x9B64C2B0, 0x86D3D2D4, 0xA00AE278, 0xBDBDF21C
    };

    while ( ulByteCount-- )
    {
        d = *pData++;
        ind = (acc & 0x0F) ^ (d & 0x0F);
        acc = (acc >> 4) ^ ulCrcRand32Lut[ind];
        ind = (acc & 0x0F) ^ (d >> 4);
        acc = (acc >> 4) ^ ulCrcRand32Lut[ind];
    }

    return (acc ^ 0xFFFFFFFF);
}

Regards,
Ryan

Hi Ryan,

Yes, we are using the same code for CRC calculation, let me know if any other things are required 

Thanks 

 Does this happen only to the CCFG or for other sections of memory as well? 

This Happens only for CCFG that too With Sector Erase, With Bank erase I'm getting Expected CRC (29d265db).

COMMAND_SECTOR_ERASE and COMMAND_BANK_ERASE should perform the same operation for the CCFG memory (the content of CCFG will be reset to the same values as when the devices was delivered from TI), the exception being write-protect CCFG flash sector bits in the FCFG1/CCFG or BANK_ERASE_DIS CCFG parameter is cleared.  Are you getting an ACK from the device and can you confirm through a JTAG memory read that the CCFG contents are the same in both instances?

Regards,
Ryan

JTAG Memory read is possible with Backdoor Bootloader ?

I was more referring to sending commands with the backdoor bootloader and then checking the results with a JTAG connection.  You can also try using the COMMAND_MEMORY_READ serial bootloader command.

Regards,
Ryan

Hi Ryan, I have verified with COMMAND_MEMORY_READ, the data was proper as i attached in the image, as a next step what we can do?

Thanks for verifying.  Can you provide the COMMAND_CRC32 packet structure for both the entire last page of flash (from 56000 to 58000) and only for the CCFG area (57fa8 to 58000) as well as their return packet values (6 bytes)?  This can also be shown through logic analyzer screenshots of each transfer as well.

unsigned char ucCommand[15];
 ucCommand[0] = <size=15>;
 ucCommand[1] = <checksum>;
 ucCommand[2]= COMMAND_CRC32;
 ucCommand[3]= Data Address [31:24];
 ucCommand[4]= Data Address [23:16];
 ucCommand[5]= Data Address [15: 8];
 ucCommand[6]= Data Address [ 7: 0];
 ucCommand[7]= Data Size [31:24];
 ucCommand[8]= Data Size [23:16];
 ucCommand[9]= Data Size [15: 8];
 ucCommand[10]= Data Size [7: 0];
 ucCommand[11]= Read Repeat Count [31:24];
 ucCommand[12]= Read Repeat Count [23:16];
 ucCommand[13]= Read Repeat Count [15: 8];
 ucCommand[14]= Read Repeat Count [7: 0];

Why must the CRC be calculated for only the CCFG and not the entire last flash page for your application?

Regards,
Ryan