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.

CC2640: Cannot get agreement between ROM bootloader COMMAND_CRC32 and HapiCrc32()

Part Number: CC2640

CRC Discrepancies

I cannot get CRC32 values to match between the ROM bootloader COMMAND_CRC32 function and  HapiCrc32().

Keeping to the app area to avoid any BLE Stack interference (0-0xEFFF) I never get agreement.

BOOTLOADER:


The call to the COMMAND_CRC32 packet, dumped from Eclipse debug session:


(sPacket is the serial stream sent over UART to ROM bootloader)

sPacket[0]    I8    0xf (Hex)    
sPacket[1]    I8    0x17 (Hex)    
sPacket[2]    I8    0x27 (Hex)    
sPacket[3]    I8    0x0 (Hex)    
sPacket[4]    I8    0x0 (Hex)    
sPacket[5]    I8    0x0 (Hex)    
sPacket[6]    I8    0x0 (Hex)    
sPacket[7]    I8    0x0 (Hex)    
sPacket[8]    I8    0x0 (Hex)    
sPacket[9]    I8    0xf0 (Hex)    
sPacket[10]    I8    0 '\0'    
sPacket[11]    I8    0 '\0'    
sPacket[12]    I8    0 '\0'    
sPacket[13]    I8    0 '\0'    
sPacket[14]    I8    0 '\0'    
sPacket[15]    I8    0 '\0'    

Which breaks down to:
    Size = 15   Chk= 17  Cmd = 0x27   StartAddr=0  Size = 0x0000F000  Iterations=0

The command acks and processes successfully and returns what looks like a good CRC32 value.


HAPI:

From executable I call:
        
        uAppCRC = HapiCrc32(0, 0xF000, 0);

        
uAppCRC never matches the ROM bootloader given CRC.   I tried playing around with the endianess but that just results in crashes (as you would expect). I also tried playing around with the size (i.e. uAppCRC = HapiCrc32(0, 0xEFFF, 0), but no luck.
        
        
* Is the HAPI CRC32 function the same one that the Bootloader uses?        
* If so, any ideas?

The target app and bootloader interface (Ubuntu/Gcc) modify the user config area to get back and forth but that is outside this range so it should not effect anything.
       

Thanks,

Mark