• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 543 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.

Concerto gets lost in start-up code when locating variables in message ram...

Wil P.
Expert 1660 points

Consider this in my M3 CMD file:

/* Message RAM */
CTOMRAM (RX) : origin = 0x2007F000, length = 0x0400 /* C28 to M3 Message RAM */
GC_FF (RX) : origin = 0x2007F400, length = 0x0002 /* Generator Control Fault flag */

...

FF_GenControl : > GC_FF

GROUP : > CTOMRAM
{
GETBUFFER : TYPE = DSECT
GETWRITEIDX : TYPE = DSECT
PUTREADIDX : TYPE = DSECT
}

This in a C file:

Uint16 FaultFlags_GeneratorControl_c28;

//#pragma DATA_SECTION(FaultFlags_GeneratorControl_c28, "FF_GenControl");

If I build and load this project with these lines, it works as expected.  If I uncomment the highlighted line, the processor gets lost in the start-up code (it never reaches main).

Is there a rule that I am breaking about explicitly putting variables in the Message ram?

  • 0
    TI__Guru* 92250 points

    William,

    Without the pragma statement, where does FaultFlags_GeneratorControl_c28 end up?  This may provide some clues.   See if it is in the memory map (.map file in the same directory as your .out file).

    -Lori

  • 0
    Guru 92251 points

    William Perdikakis said:
    If I build and load this project with these lines, it works as expected.  If I uncomment the highlighted line, the processor gets lost in the start-up code (it never reaches main).

    Is there a rule that I am breaking about explicitly putting variables in the Message ram?

    The M3 C run-time start up code will attempt to initialise the FaultFlags_GeneratorControl_c28 variable by writing to it. The Concerto F28M35x Technical Reference Manual SPRUH22C section 5.1.1.3 MSG RAM states:

    The message RAMs will have only CPU and DMA read/write access from one side (M3 or C28), and CPU/DMA read from the other side. For MTOCMSGRAM, M3 CPU and uDMA will have read and write accesses, whereas C28 CPU and DMA will have only read access. Similarly for CTOMMSGRAM, C28 CPU and DMA will have read and write accesses, whereas M3 CPU and μDMA will have only read access.

    Therefore, I think the M3 C start-up code is halting with an exception when it attempts to initialise the FaultFlags_GeneratorControl_c28 variable in the C to M MSG RAM, which the M3 only has read-only access to.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    ARM Assembly Language Tools v5.0 User's Guide SPNU118K section 7.5.7 Special Section Types mentions a NOINIT section type which can be specified in a linker command file, which means the section is NOT C auto-initialised by the linker. Suggest that NOINIT should be applied in the M3 linker command file for the CTOM MSG RAM sections which the M3 has read-only access to.

  • 0 in reply to Chester Gillon
    Expert 1660 points

    Chester Gillon said:

    If I build and load this project with these lines, it works as expected.  If I uncomment the highlighted line, the processor gets lost in the start-up code (it never reaches main).

    Is there a rule that I am breaking about explicitly putting variables in the Message ram?

    The M3 C run-time start up code will attempt to initialise the FaultFlags_GeneratorControl_c28 variable by writing to it. The Concerto F28M35x Technical Reference Manual SPRUH22C section 5.1.1.3 MSG RAM states:

    The message RAMs will have only CPU and DMA read/write access from one side (M3 or C28), and CPU/DMA read from the other side. For MTOCMSGRAM, M3 CPU and uDMA will have read and write accesses, whereas C28 CPU and DMA will have only read access. Similarly for CTOMMSGRAM, C28 CPU and DMA will have read and write accesses, whereas M3 CPU and μDMA will have only read access.

    Therefore, I think the M3 C start-up code is halting with an exception when it attempts to initialise the FaultFlags_GeneratorControl_c28 variable in the C to M MSG RAM, which the M3 only has read-only access to.

    [/quote]

    This sounds right.  I changed all of my declarations in the CtoM RAM to pointers and it runs perfectly.  

    Thanks

  • 0 in reply to Chester Gillon
    Expert 1660 points

    Chester Gillon said:

    ARM Assembly Language Tools v5.0 User's Guide SPNU118K section 7.5.7 Special Section Types mentions a NOINIT section type which can be specified in a linker command file, which means the section is NOT C auto-initialised by the linker. Suggest that NOINIT should be applied in the M3 linker command file for the CTOM MSG RAM sections which the M3 has read-only access to.

    Holy SH*T,  Even better.  Chester, you sir, get +1 Internets for the day.