• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 443 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.

RM57L843: Cannot initialize more than 1 byte at the same time with FreeRTOS

surialic
Prodigy 160 points
Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

7875.Test.zipHello Community,

I'm encountering a problem when merging my application with FreeRTOS. The application by itself runs well bare metal. 

I created a new CCS project (v7.4) and a new HALCoGen file for the merged version. Now whenever I try to initialize a variable in the stack that is more than 1 byte in size (int for example), the program crashes and ends in the "dataEntry" line of HL_sys_intvecs.asm. I checked the MPU settings and according to them RAM should start at 0x08000000 and end at 0x0807FFFF. For some reason the initial SP is getting set to addresses like 0x07FFFAA00. Therefore, it is out of bounds of the RAM. If I manually change the SP address to something close to 0x08000000 then the initialization works (but of course this is not a solution). Going through the disassembly, I noticed that bools, unit8_ts, and other one byte long data types get allocated and initialized inside the RAM boundaries by passing in big offsets to the strb instruction:

strb       r12, [sp, #0x8a4]

This is the for the first boolean that gets initialized.

However, the following is the instruction that gets executed when initializing an int:

str        r12, [sp] (no offset and SP is set to an address outside of RAM)

The program then crashes since it tried to write to a prohibited location.

Sounds to me like something is off configuration wise...but I've compared the CCS and HALCoGen settings between my two projects and so far have not found anything that would have to do with this. Also, I ran the same application with FreeRTOS using a TMS57 board and it worked fine with it. For both, I used the TI v16.9.6.LTS compiler.

I attached my HALCoGen file in case someone can take a look at it.

I appreciate any help and guidance you can provide.

Thank you,

Surialic 

  • 0 in reply to QJ Wang
    Prodigy 160 points
    Hello QJ Wang,

    We referred to that link when building our application for the TMS570 board and it worked. However, we are having the problem described above when we run the application on an RM57. I regenerated the FreeRTOS and peripheral files using HALCoGen and basically imported everything else from the TMS570 project. Is there any way I can see the initialization code that happens before main() gets called? Maybe this could give me more information as to why the Stack Pointer is getting set to something out of bounds.

    Thank you,

    Surialic
  • 0 in reply to surialic
    TI__Guru**** 197126 points
    Hello Surialic,

    After reset, the MCU registers are initialized. The R[14:1] should be initialized to 0 by calling this function:
    _coreInitRegisters_();

    The SP is initialized by _coreInitStackPointer_(), and initialized SP is 0x0800xxxx.

    How do you initialize a variable in the stack? Why do you place your variable in stack? Does your variable overwrite the content in stack?
  • 0 in reply to QJ Wang
    Prodigy 160 points

    QJ Wang,

    Thanks for your reply and information. I just resolved the issue by enlarging the user portion of the stack in HALCoGen. RM57_FREERTOS > RAM

    I enlarged it from 0x00000300 to 0x00008000. Pretty sure I don't need that much but at least for now I'll leave it like that.

    I don't quite understand why it would still allocate one byte variables and crash as soon as I allocated a 2/4 byte one. But I guess I can investigate that later.

    Thank you,

    Surialic

  • 0 in reply to surialic
    Expert 1995 points
    This might be something, but it is only an uninformed guess. Were you initializing 2 and 4 byte values on 2 and 4 byte aligned address?