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.

CC2652R7: Program loading using a modified BIM

Part Number: CC2652R7
Other Parts Discussed in Thread: MSP430F2272

We are replacing an MSP430F2272 with the CC2652.  The previous product was single threaded and included a program update section of code so we could store a second program image in flash and copy it over the main program.  In the CC2652 version, we implemented TI RTOS7 and are using a modified dual image BIM to transfer the second image to location 0.  We verified all of the code, but can't seem to get the program to restart after the image transfer.  If we reload the BIM, the new program works fine so we know the new program image is in place.  Does anyone have any suggestions as to what to look for or what to be careful of?  We use the config file from the BIM so the program starts in the BIM.  When a new image is loaded we jump to the BIM reset vector.  Once in the BIM, the new image is moved and erased, if there is a new image, then the BIM reset vector is called so it returns to the BIM which goes to the reset vector for the main program if there is no new image.

  • Hi Gary,

    Please confirm that you are using the Dual_image build configuration of the on-chip BIM project.  Image erasure through Bim_EraseOnchipFlashPages should not be enabled unless BIM_ERASE_INVALID_IMAGE is defined.  It is likely the case that the BIM header (imgHdr.fixedHdr) of the new program does not read as an image status of present (IMG_TYPE_IMAGE_PRESENT) and/or valid (IMG_TYPE_VALID_APPSTACKLIB_IMG).  You can try to load images into either/both application memory spaces, then open a BIM debug session to step through the code and determine the root cause of the issue.

    Regards,
    Ryan

  • I debugged the main BLE project, not the BIM, and once control is passed back from the BIM it goes to Hwi_excHandlerMin.  I will work on why, but any suggestions would be appreciated.  We have some large capacitors on this product and once they get discharged causing a normal power on reset, the product work normally so I am not sure what is not being reset when the BIM jumps to the main project reset vector.

  • The way in which the BIM is being entered is causing a HWI assert.  OAD-enabled applications (on-chip/off-chip simple_peripheral or simple_mesh_node) perform a soft system reset (SysCtrlSystemReset) to enter the BIM after completing an image update and are ready to execute the new application.  

    Regards,
    Ryan

  • I added the system reset at the point where the new image is loaded and we are ready to go to the BIM.  At that point the emulator loses control regardless of emulating the program or the BIM.  The BIM is never reached.  If I set a breakpoint at the point where the image is loaded and then switch to BIM emulation everything restarts just fine.  The BIM is loaded last so we use the configuration file for the BIM.  There are no image headers, our BIM has been simplified to check for a new image, not erased, copy it to location 0, erase the first sector of the new image and go to the new reset vector at location 0.  The original code jumped to the BIM and that worked until the reset vector was called after the program was changed.  Is there anything that needs to be stopped before the system reset?

  • It is understood that the IDE's debugger will lose control of the device during a device reset.  What is observed such that you say "the BIM is never reached"?  This would either mean that the BIM application symbols are not loaded, the BIM does not contain the correct reset vector address, or the CCFG is incorrect. Please consult the BLE Enhanced OAD Advanced SimpleLink Academy Lab for further instructions on debugging BIM functionality.  Nothing needs to be stopped before the system reset, you can consult usage of SystemReset inside the persistent_app and OAD-enabled applications previously mentioned.

    Regards,
    Ryan