• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 85 subscribers
  • Views 1588 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Memory Contents Changed by EST_run()

Soon Yet Chan
Intellectual 630 points
Other Parts Discussed in Thread: MOTORWARE

Hi all gurus,

I having a very weird problem that at first I thought is stack overflow but later on found out it isn't. F28027, MotorWare v14.

Finally I tracked down that each time EST_run() is called, some memory in region 0x000620~0x000800 (in RAM M1) are changed.

This region is not allocated in linker cmd file:

PRAML0 : origin = 0x008000, length = 0x000B80 /* on-chip RAM block L0 */
DRAML0 : origin = 0x008B80, length = 0x000480 /* on-chip RAM block L0 */
RAMM0_M1    : origin = 0x000000, length = 0x0007FF     /* on-chip RAM block M0 + M1 */

/* Allocate uninitalized data sections: */

.stack : > RAMM0_M1 PAGE = 1
.ebss : > DRAML0 PAGE = 1 //RAMM0_M1  PAGE = 1
.esysmem : > RAMM0_M1 PAGE = 1

DRAM was originally in RAMM0_M1 but the memory change causes program to go in PIE_IllegalISR(), now putting DRAM in L0 as workaround.

As below: addressed in red are the ones get changed when EST_run() is called.

Thanks.

  • 0
    Intellectual 630 points
    PS: When DRAM was originally assigned to RAMM0_M1, it linked first (at address 0x000000) before the stack. The stack goes into the problematic region and when the contents were changed, program fall into PIE_IllegalISR()
  • 0 in reply to Soon Yet Chan
    TI__Mastermind 32995 points
    What do you mean 0x000620~0x000800 is not allocated in the linker command file? it is allocated to RAMM_M1 right?

    What is the function of EST_run()? What does that function do?

    If .ebss was allocated to RAMM0_M1 which is the section for static global variables, it looks like EST_run() is changing some global variables used by that function. It is possible that the stack was corrupted. How much memory did you allocate for the stack? If you increase it, does the problem persist.

    sal
  • 0 in reply to Sal Pezzino
    TI__Guru** 118000 points
    Sal,
    EST_run is a function in secure execute only ROM on the InstaSPIN enabled devise.
    There are variables in allocated RAM that are changed by the estimator running in ROM. These are so you can access variables in user code.
  • 0 in reply to ChrisClearman
    TI__Mastermind 32995 points
    So EST_run() is modifying these variables. It is possible that the stack is overflowing into the memory section containing these variables and EST is writing over the stack.

    Soon,
    What is the SP in the illegalISR()? Try increasing the stack size in the CCS project.

    sal
  • 0
    TI__Mastermind 19810 points

    Soon Yet Chan said:
    Finally I tracked down that each time EST_run() is called, some memory in region 0x000620~0x000800 (in RAM M1) are changed.

    The memory region 0x600-0x800 is supposed to be reserved, applications should not use it as it is pre-allocated for ROM code and is used by ROM code. 

    Please modify the linker command file to reserve above section and let us know if it fixes the error.

    Hope this helps.

    Best Regards

    Santosh Athuru

  • 0 in reply to Sal Pezzino
    Intellectual 630 points
    Hi Sal, .ebss is not in RAMM0_M1, it's in DRAML0.
    I checked, stacked set to 0x200, starting address 0x0. Actual usage never go beyond 0x150. In any case the stack has to overflow until 0x620 before it get overwritten.

    Maybe I used the wrong term, what I mean by unallocated is there is no variables or RAM function in that memory range, but the contents are changed.
  • 0 in reply to Santosh Athuru
    Intellectual 630 points
    Hi Santosh,
    I see, if I avoid that region for sure problem will go away.
    Can you point me to the correct documentation on this reserved area?
  • 0 in reply to Soon Yet Chan
    TI__Mastermind 19810 points
    Hi Soon,
    section 8.4.1.3 of the below user guide explains this.

    www.ti.com/.../spruhj1f.pdf


    Hope this helps.

    Best Regards
    Santosh Athuru
  • 0 in reply to Santosh Athuru
    TI__Mastermind 32995 points
    Thanks Santosh.

    sal
  • 0 in reply to Sal Pezzino
    TI__Intellectual 2745 points

    Soon,

    F28027F.cmd file in MW14 has a bug for RAMM0_M1 memory allocation. You have to modify the cmd file as Santosh mentioned or use the latest MW cmd files.

    RAMM0_M1    : origin = 0x000000, length = 0x000600     /* on-chip RAM block M0 + M1. 0x600 to 0x800 reserved for InstaSPIN */

    This bug was fixed at MW15 and 16 version.

    -Steve

  • 0 in reply to Steve Lim
    Intellectual 630 points
    Thanks Steve, I was confused by the F28027F.cmd file, never thought that region is used by EST.

    By the way, would you able to check whether 0x0007FF location is actually used?

    We are in a bad situation where our application is setting a flag in that location to be read by our software bootloader after a soft reboot. We are using the software bootloader to perform application firmware update via UART (bootloader is not updated). If we want to change the flag location, the bootloader firmware has to change as well, which is not possible for us.

    The workaround I foresee is to disable FOC upon setting the flag (to prevent it gets overwritten by FOC) and reboot afterwards. But it will be really good to know whether 0x0007FFF location is actually used.

    Thanks again.
  • 0 in reply to Soon Yet Chan
    TI__Intellectual 2745 points

    Soon,

    The actual RAM_M1 region used by FAST ROM code is 0x600~0x7FC. The 0x7FD ~ 0x7FF is not used by EST.

    So I think you can use 0x7FF.

     

    -Steve

  • 0 in reply to Steve Lim
    Intellectual 630 points
    Hi Steve,

    I checked the memory contents, 0x7FD~0x7FF are indeed unchanged so far.
    Thanks for the confirmation.
  • 0 in reply to Soon Yet Chan
    TI__Genius 17175 points

    Soon,


    While Steve is correct that addesses 0x7D-0x7F of RAM_M1 are currently unused, I wanted to mention that these memory locations are generally not intended to be utilized by the customer. Utilizing these addresses may well work for your code now, but if a change to ROM happens in the future at some point, your code might not work as it does today.


    I wanted to offer this information as a heads up in case a future update breaks the program you have working today.


    Regards,

    Sean

  • 0 in reply to Sean Bigley
    Intellectual 630 points
    Hi Sean,

    Thanks for your concern, I asked for this, because we already released our application and try to understand the risk. We will definitely fix it once we have the chance.