CC2541: cc2541: Reserved ID of bin file check in BIM

Hi Muqarrab,

There are a couple of fields in the image header that are meant for user to be able to specify information about the image. One is the uid bytes that you mentioned - these are user-defined image identification bytes. You could use these bytes to indicate what image you are loading. There is also the ver field. This byte is a user-defined image version number. The combination of these two would allow you to for example, define that you are loading program called 0xABCD (in uid field) so you know what kind of program you are loading, and you can say you are loading version 0x02. That would let you know what the currently loaded version of that program it is, if you keep track somewhere for yourself. You could then use this to implement in the bim to only allow images with certain uids to be loaded if you wish. Having the uid and not just version is helpful because you could theoretically have multiple products built on the same type of CC2541 device, and this way you'd be able to differentiate somehow the firmware that is loaded is for that particular product configuration.

Is there a reason you would rather use the reserved bytes instead of the provided user-id field?

Regards,
Katie

Hi Muqarrab,

I would still recommend using the other fields I have mentioned, but in either case the implementation will be basically the same. If you open the BIM project included with the CC254x BLE stack under C:\Texas Instruments\BLE-CC254x-1.4.2.2\Projects\ble\util\BIM\cc254x, and look in bim_main.c, in the main() function, you can see that right now it simply checks the CRC when determining which image to run. Instead, you will want to additionally check some other bytes in the image header to determine if you consider an image to be "valid" or one that you want to run, or not. From the OAD for CC254x user's guide http://processors.wiki.ti.com/images/8/82/OAD_for_CC254x.pdf , section 8.4.2 Image Header, it says that the image header is immediately adjacent to the image CRC structure. You can see that in the bim_main.c in main(), it uses:

  HalFlashRead(BIM_IMG_B_PAGE, BIM_CRC_OSET, (uint8 *)crc, 4);

To read the CRC, as well as crc1 which is actually coming from the beginning of the image header struct. Therefore, you can use the same method of using HalFlashRead, but with additional offset to read the values of the rest of the fields in the image header structure that you showed in your previous post - simply modify the offset and length used. For the offset, remember that the only thing on the page before the header is the 16-bit crc, so just take that and the offset of the particular field you want to read within your struct, and you should have it. Then, you can simply modify/add some if statements to assess if the values you read from either the uid or from the reserved fields (depending on the method you want to implement) match what the one that you would like to accept. You just need to make sure that you have these if statements be included with the crc check such that they happen before the setting of JumpToImageAorB and asm("LJMP x") instructions that set up the jump to application code, and handle accordingly. 

You can choose whatever method you'd like for handling if the image does not match what you expect - that will depend on your application needs for how you want it to handle that situation. Typically you would have it go to the other image instead and maybe try loading again, just as you would on a bad CRC. 

Regards,

Katie