Below are a few different things that you can try to improve the flashing performance when using TI's CCS On-chip Flash Plugin or UniFlash.
a. Use a faster emulator like XDS200. Performance of this emulator is comparable to that of XDS510, but it is cheaper.
b. There is no need to erase the entire Flash bank every time a flash program operation is initiated. In the On-Chip Flash Plugin GUI, user can choose the option "Necessary Sectors Only (for Program Load)" under Erase settings. This will erase only the sectors that are supposed to be reprogrammed (based on their linker cmd file). However, if any un-erased locations exist in other sectors that are not erased, application can not use those locations at run-time. Also, the checksum of the bank might not meet the expected value as unerased sectors may have previously programmed content. This should not be an issue for the fresh parts received from TI as the flash bank will be in erased state coming out of TI production..
c. If this is a production environment, you can choose “Program Only” option as units come erased from TI.
d. You can un-check "Verify Flash after Program" under Download Settings. Please note that verify of the image will not be done after the program operation when you choose this. You can use checksum option in Plugin after the program operation to verify the authenticity of the image, if it is acceptable for you. Note that the checksum operation may need you to unlock the device if a reset is issued between the program and checksum initiation.
e. If the application has multiple sections in the linker cmd file, you can try enabling "Combine Sections during Program Load to increase Performance" under Performance Settings. If there are not many sections, this is not suggested. When this feature is used, multiple sections in the executable will be combined together and programmed at once - While doing this, all the holes in between the sections will be filled with all 1s data and ECC also gets programmed for this all 1s data. Hence, those all 1s locations can not be used at application runtime if needed.
f. You can disable blank check after erase. If you choose this option, tools will not check whether the erase operation erased all the bits or not. Hence, if a bit is not erased properly, the program operation will fail when a 0->1 transition happens as part of the program operation.
Important Notes to consider when using flash programming tools:
1. Flash plugin is developed for fully embedded flash applications. Meaning, all of the initialized sections in linker cmd should be mapped to flash. If anything needs to be executed from RAM, that content should be copied to RAM at runtime using memcpy() before executing that content. Please see below FAQ for more info on this.
[FAQ] Flash - How to modify an application from RAM configuration to Flash configuration?: https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/878674
2. For multicore devices, note that unsecured shared RAM is used (where available) for loading flash plugin code in to the device. Hence, after loading one core's flash image, if you execute the application to use the shared RAM, that content will be lost when you try to load code on another core's flash bank. Hence, load both cores' flash banks before executing the application on any core. If your application is using only one core for debug or development, then this is not applicable.
3. If the boot mode pins are configured for flash boot on your board, debugger connection can be flaky - this is because the CPU starts executing invalid opcodes if the flash is erased. Even if it is not erased, during development, if the application in the flash has any bugs or application design issues causing resets or other failures, the device may not be in an application-defined condition. This can prevent to establish a stable connection with the debugger. Even if the debugger manages to establish the connection, the device may not be in a clean initialized state due to flash application execution. Hence, we would suggest users to give a device reset, run the bootROM (resume button in CCS), halt the CPU and then proceed to the debug activities. NOTE that flash plugin or Uniflash is also an application that gets loaded to the device RAM to do flash operations. Hence, it is suggested to issue a device reset before using flash plugin or Uniflash if the boot mode pins are configured for flash boot.
4. For programming a fresh device using JTAG, the suggested boot pin configuration is wait-boot (or WIR mode for Concerto). If this is not possible, at least configure the boot pins for serial boot so that bootROM waits in serial boot without branching to unprogrammed flash. This helps to avoid ITRAPs/resets and thus provides a clean device state to establish a stable connection.
5. After loading the flash banks using any flash programming tools (TI CCS flash plugin, Uniflash or any 3rd party tools), it is suggested to reset the device once before evaluating/executing your application. This is because the flash tools will configure many registers in the device and also use RAM memory to accomplish flash erase, program, verify, checksum and other miscellaneous operations. A reset and restart will bring the device to a clean known state for you to evaluate your application.
Thanks and regards,
Vamsi
