Flashapi

[Jarvarious Hunsaker]

Iam working on a bootloader and looked at the examples in the C2000Ware libs. I found out that the examples (eg. flashapi_ex1_program_autoecc) are in the depreciated COFF format. As COFF is depriciated I am reprogramming it to work with the EABI libs.

The compiler is gives warnings that the COFF libs cannot be used when EABI is selected as output format. So I replaced driverlib with driverlib_eabi and need to replace F021_API_F28004x_FPU32.lib. As I am / was assuming that it is the RAM lib. Could you clearify what the difference is (RAM and ROM flashApi libs)?

Based on the details that you mentioned, you don't need the RAM Flash API library. You can simply use the ROM Flash API. ROM Flash API is already in the device ROM and hence you don't need to allocate any Flash/RAM space for that. And, hence you don't need to copy that to RAM to execute. You can simply execute it from ROM. When using the ROM Flash API lib, you can simply link the library to your project.

Regarding the "no matching selection" warning that you got: I think you meant "section" and not "selection". It might be because you mapped the ROM API symbols library to flash/RAM. It will not be present in the actual build as it is just a symbols library.

I am using the "flashapi_ex1_program_autoecc" example with the TI ControlCard as base for my bootloader. I do not use the sci_boot function (with the dipswitches), so starting in flash. In the example the flashApi is copied to RAM to program flash. As you stated in this example you cannot run from flash. How to run/call it from ROM then?

In the example that you mentioned, ROM Flash API library is not used. It embeds the Flash API library in to the application and hence it has to be copied to RAM. When you use the ROM Flash API symbols library, it already exists in the device ROM. Hence, there is no need to again copy to RAM to execute it. Flash API when mapped to Flash has a limitation that it can not be executed to do erase/program operations on the bank from which Flash API is executed. Hence, we suggest them to copy to RAM. This limitation is not applicable when using the Flash API that is in ROM. You can simply call the ROM Flash API functions (same functions and syntax) just like you do with the embedded Flash API. No special instructions. You just need to include the ROM API symbols library in your project - that's all. You can attach your project if you want. I can take a look regarding the warning. Also, we have an example to use the ROM API. I will see if I can send that to you. We plan to release that at the end of this quarter anyways.

Glad it is working now. That is what I meant when I said "Based on the details that you mentioned, you don't need the RAM Flash API library. You can simply use the ROM Flash API. ROM Flash API is already in the device ROM and hence you don't need to allocate any Flash/RAM space for that. And, hence you don't need to copy that to RAM to execute. You can simply execute it from ROM. When using the ROM Flash API lib, you can simply link the library to your project."

Regarding the example: It is planned for release at the end of this quarter after adding proper notes to it. Since, it is working fine for you now, I would suggest to wait for the official release. Thank you. Please open a new post if you have any other issues and we can help.

Non-volatile flash memory on C2000 devices is primarily used as program memory for the core and also as static data memory. During application development, application executable can be programmed in to the flash memory using Code Composer Studio (CCS). When CCS identifies that the code is mapped in to the flash memory for a given application, it will automatically invoke CCS On-Chip Flash Plugin to load the executable in to the flash memory. Flash Plugin GUI is available at CCS Debug view -> Tools -> On-chip Flash. By default, the on-chip Flash Plugin erases the flash before programming, generates ECC for the executable and programs it along with the main array flash content and verifies the programmed content. If needed, users can enable blank check - CPU verification to confirm that flash is erased before programming. All of the USER OTP fields (DCSM and boot settings) can be programmed as well using the CCS On-chip Flash Plugin. Checksum calculation feature is also available within the Plugin GUI. Performance of the CCS flash programming is best when using high performance debug probes (XDS200 is suggested).

TI also provides UniFlash, a standalone JTAG based flash programming tool. This has a smaller footprint compared to that of CCS, since it does not include debug support. Users can create device-specific UniFlash package to further reduce the tool size (See Standalone Command Line window in UniFlash after installation). UniFlash offers all the GUI operations that CCS Flash Plugin does.

Customers may also refer to 3rd party programmers like CodeSkin, DATA IO etc. to get flash programming support via serial peripherals like SCI, CAN etc. Elprotronic offers JTAG based C2000 GANG programmers.

TI flash tools and 3rd party flash programmers use Flash API library to perform flash erase and program operations. Flash API library and reference guide for each device are available in C2000Ware at /libraries/flash_api. Flash API library has functions to do flash operations like erase, blank check, program flash and corresponding ECC, program verify, suspend an erase or program operation, resume an erase or program operation, ECC calculation, checksum calculation, remap an ECC address to corresponding main array address etc. Note that ECC is not available for some C2000 devices. Please check Datasheet and TRM for the details. Applications that require erase or program flash at runtime can embed Flash API library to accomplish the same. An example to use Flash API library is provided in C2000Ware (e.g. C2000Ware_x_xx_xx_xx\driverlib\f2838x\examples\c28x\flash\flashapi_ex1_programming).

C2000Ware contains examples to illustrate flash kernels. Flash kernels are used by C2000 devices to provide firmware updates to a system, with a mechanism to switchover to the new firmware through a device reset. C2000Ware examples for flash kernels illustrate how to provide firmware updates over SCI, CAN [DCAN] and MCAN [CAN-FD] peripherals. For example, the C2000Ware flash kernels for the F28003x device can be found in the /driverlib/f28003x/examples/flash sub-directory of the C2000Ware installation. For example, at this path the flash_kernel_ex3_boot.c and flash_kernel_ex3_sci_flash_kernel.c refer to the SCI flash kernel example, flash_kernel_ex4_boot.c and flash_kernel_ex4_can_flash_kernel.c refer to the MCAN (CAN-FD) flash kernel example, flash_kernel_ex5_boot.c and flash_kernel_ex5_dcan_flash_kernel.c refer to the CAN (DCAN) flash kernel example. For more device examples, refer to the device specific paths given in the application note.

C2000Ware also contains an example to demonstrate EEPROM Emulation using the On-Chip Flash of some Gen 3 C2000 MCUs (F28P65x, F280013x, F280015x). This example allows for EEPROM Emulation, including Read, Write, and Erase. The example provides both Single-Unit and Ping-Pong (between two EEPROM units) implementation models with several user-configurable aspects. For example, the EEPROM Emulation Example for F28P65x can be found in the /driverlib/f28p65x/examples/c28x/flash sub-directory of the C2000Ware installation. There is a separate project for the Single-Unit and Ping-Pong implementation.

TI does not normally distribute the flash API source code nor support development, or modifications, of the flash API by customers. Programming and erase of the flash must be done in a very specific manner. Testing the flash API library involves special test modes accessed by the device during automatic test equipment (ATE). Testing of the library is accomplished by using it in TI development, device testing, write erase cycle qualification, and by all flash programming tools. Modification or rebuilding the API library will not benefit from this testing and thus the restrictions.

In situations where the application is military, aviation, or medical in nature and the user has a justifiable and legitimate need for the source code for certification purposes, it can be provided under a signed license agreement with TI. If users fall into this category, contact your TI sales or distribution representative or post in the TI E2E forum for assistance.

3a8082e126