• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 84 subscribers
  • Views 1157 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28386D: custom bootloader, RUN in RAM, rts2800_fpu64_eabi.lib

Fernando Marotta
Prodigy 40 points

Part Number: TMS320F28386D

Hello everyone,



I am developing a custom bootloader for my project, I have assigned the first two sectors of FLASH to it.
So far I manage to load in the FLASH the first two sectors and run the whole program in RAM except for the rts2800_fpu64_eabi.lib, because this library contains the whole partition, memset, memcpy routines necessary for the .binit section created by the linker command.
The need to be able to run the whole bootloader from RAM is so that the bootloader can update itself.

Is there any way to link all this library for the c2000_init routine, binit LOAD in FLASH an RUN in FLASH and then for the rest of the Bootloader C program link as LOAD in FLASH and RUN in RAM?

My compiler version is TI v20.2.5.LTS

Attached a piece of my cmd linker

.TI.ramfunc {-l c28x_vcrc_library_fpu64.lib -l F2838x_C28x_FlashAPI.lib -l rts2800_fpu64_eabi.lib }
LOAD = FLASH0,
RUN = RAMLS5_7 | RAMGS3_8,
TABLE(BINIT)
ALIGN(8)

The result is that if you run this project it will crash because of the absence of the copy table routine in the RAM expected for the c2000_init routine.

Any suggestions would be greatly appreciated.

Regards,

Fernando Marotta

  • 0
    TI__Guru* 87155 points

    Fernando,

    We will review and get back to you on wednesday 2/9.

    Thanks and regards,
    Vamsi

  • 0
    TI__Guru**** 253590 points

    I don't understand everything about your system.  But I can comment on your use of table(BINIT).

    The syntax table(BINIT) tells the linker to create a copy table for that output section.  In your case, this output section is named .TI.ramfunc.  Code in the boot routine supplied with the compiler RTS library automatically detects the presence of this copy table, and uses it to copy .TI.ramfunc from flash to RAM.  Your system does not use the boot routine supplied with the compiler RTS library.  Thus, the best thing to do is use a custom copy table name instead of BINIT ...

    table(custom_copy_table)

    At the appropriate point in your system, have code similar to the following ...

    /* These lines typically in a header file */
#include <cpy_tbl.h>                  /* defines the type COPY_TABLE */
extern COPY_TABLE custom_copy_table;  /* defined by the linker */

/* This line inside a function in a C file */
    copy_in(&custom_copy_table);

    The call to copy_in copies .TI.ramfunc from flash to RAM.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    Hi George,

    The problem is not the copy table, the major problem is the routines contained in RTS library like memeset, memcpy or div23, this routine is used in my code generated, so i think ok i can resolve my problem with LOAD in FLASH and then RUN in RAM this Routine (RTS), but this routines is needed for process memcpy from FLASH to RAM at the moment to execut cinit, however if this routine for cinit compiled expect that funcitions someone copy imself in a RAM previously this generate a genesis problem, who realize this job at te beginning the times?

    For this reason i think RUN this routines on separately memory on cinit and my code application.

    Thanks

    Fernando

  • 0 in reply to Fernando Marotta
    TI__Guru**** 253590 points

    Parts of the system cannot be in an output section, such as .TI.ramfunc, that loads in flash and runs from RAM.  These parts must execute directly from flash.  This includes the boot routine (whether it comes from the compiler RTS library or not), the function copy_in, the function memcpy (which is called by copy_in), and the copy tables themselves (which the linker automatically puts in the output section named .ovly).  There are probably other parts of the system which are under the same constraint.

    Thanks and regards,

    -George

  • 0 in reply to Vamsi Gudivada
    Prodigy 40 points

    Hi Vamsi,

    Any solution or suggestion?

    Thanks

    Fernando

  • 0 in reply to Fernando Marotta
    Prodigy 70 points

    Im quite interested in this issue too

  • 0 in reply to Fernando Marotta
    TI__Guru* 87155 points

    Hi Fernando and Miguel,

    This is assigned back to our team today.  We will review and get back to you in a day or two.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87155 points

    Fernando,

    When you say you want to update the bootloader itself: When will this be determined in your application?  Does application receive an input at runtime indicating that it has to update the bootloader?  

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Prodigy 40 points

    Yes it is correct, when the previous version bootlodar is LOAD in FLASH RUN in RAM it will receive by own protocol commands through SPI the command of ERASE ALL and then Program/Verify if all the process is correct it will command a CPU Reset.

  • 0 in reply to Fernando Marotta
    TI__Guru* 87155 points

    Fernando,

    When it receives the command to erase all, can you stream in a new kernel in to RAM and branch to it?  You can develop that kernel to contain all the functionality that you need.  

    Please note: I am OOO currently.  I am assigning this post to another expert in our team.

    Thanks and regards,
    Vamsi