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.

TMS320F280049: Fapi_error_fail using a bootloader

Part Number: TMS320F280049

Dear all,

I am developing a bootloader for the micro in question. I don't have too much experience on this.

Right now I am using the sample firmware flashapi_ex2_sci_kernel and serial_flash_programmer provided by ti.

It seems that I can successfully load the firmware from the PC using the DFU_CPU1 command, but I get an error in copying to flash.

So I tried to send a simpler command ERASE_CPU1 and again I get an error when I use the flash (Fapi_Error_Fail)

From this I deduce that something is misconfigured. Can you give me some ideas to proceed with debugging? For example in the various requests on the forum I saw that it is important to use a correct file for the linker. Can you give me details about it.

Regards

  • Matteo,

    Are you able to erase/program this device fine using CCS flash plugin?  Or do you get any error?

    I will assign this to our kernel expert to help you.  

    Thanks and regards,
    Vamsi

  • Matteo, 

    Regarding the linker cmd file, for the application that you are downloading, aligning the sections to 128 bit boundaries using the "ALIGN(8)" directive will make sure the kernel can properly write the application into Flash. 

    When you get an error after the Erase command, what address is returned?

    Thanks, 

    Anu

  • I managed to get some order. I think I have two different issue:

    1_

    I tried to load two different firmware using compiled kernel (flashapi_ex2_sci_kernel)

    led_ex1_blinky (CPU1_LAUNCHXL_FLASH, 28004x_generic_flash_lnk.cmd, --boot --sci8 --ascii) works correctly. After download I'm able to run the firmware from kernel and after a reboot (with digital input in flash boot configuration) the same firmware is running at startup. Address 0x80000 is returned from kernel. Everything seems to be fine.

    I make my firmware which blinks a led and send a CAN message every 500ms (28004x_generic_flash_lnk.cmd, --boot --sci8 --ascii). After download I receive 0x8357c. I'm not able to run the firmware. The same firmware doesn't work  in debug mode. it works in debug with (280049C_RAM_lnk.cmd)

    I think I have to clarify how command linker works exactly and which one I should use.

    2_ 

    Compiling "my version" of flashapi_ex2_sci_kernel (BANK0_NO_LDFU) I notice that I get error erasing flash when I send ERASE_CPU1, while the same command seems to works correctly if I compile with configuration BANK1_NO_LDFU

    Can you explain me which is the difference between the two configurations?

    Solving these two different issues i should be close to get all working hopefully.

    Regards

  • Matteo, 

    For info on linker command files, please refer to the following: https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_Linker-Command-File-Primer.html 

    The two configurations differ in terms of which bank the kernel is linked to. Maybe you can compare the linker command files of the two configurations? Did you make any changes to the BANK0_NO_LDFU configuration?

    Thanks, 

    Anu

  • No changes have been made on the linker command files.

    I modify the kernel in order to change a bit the logic, but functions which act on the memory have not been touched.

    Other suggestions to go on with debug?

  • Matteo, 

    For help with getting the firmware running with the RAM build config working with a Flash build config, please refer to the following: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/878674/faq-flash---how-to-modify-an-application-from-ram-configuration-to-flash-configuration

    For the kernels, did your added logic change where the Flash API functions got mapped? You can compare the two map files for the build configurations to see where everything in the project is located in memory. 

    Thanks, 

    Anu