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

RAML3 on 28035 with no CLA

Thomas Blocher
Intellectual 475 points

Hello!

Can I use RAML3 to store program memory there, if I am not using CLA?

I observe that I can use RAML3 up to 50%. If I use more than 50% (0x009800) then my program crashes hard.


-Thomas

  • 0
    TI__Guru* 93800 points
    Tom,

    If it is a 28034 or 28032 then yes the whole L3 is available.
    If it is a 28031 or 28030 then only part of L3 is available.

    Which device are you using?

    Regards
    Lori
  • 0 in reply to Lori Heustess
    Intellectual 475 points
    Hi lori,

    it is the 28035PN.
    It has a CLA but I don't use it.

    -Thomas
  • 0 in reply to Thomas Blocher
    TI__Guru* 93800 points

    Thomas,

    I understand now.  The RAM is all available to the main CPU.  You can try reading/writing to it in a memory window as a simple test.  It will take some debug to figure out why the program is crashing.  Are there any symptoms?  Could the stack be overflowing the allocated memory?


    -Lori

  • 0 in reply to Lori Heustess
    Intellectual 475 points
    Hello Lori!

    Thanks for your answer.

    I can read/write the RAML3 memory without any problems and even after a crash (jump to BOOTROM 0x3ff806) the program memory in RAML3 is unchanged.

    I seems that the problem is somehow connected to my isr and to memory alignment. May something doesn’t like odd addresses.
    If I add one nop-command to the isr the error is gone.
    If I add two nop-commands to the isr then the error is back.

    Now I think that problem isn’t related to the RAML3 memory. It was a coincidence that, reducing memory size hides the error. It will be fun to find the real cause of the error :)

    -Thomas
  • 0 in reply to Thomas Blocher
    TI__Guru* 93800 points
    Tom,

    It looks like that address is in the SCI boot routine. I'm thinking that your device likely took a reset - possibly the watchdog reset it. Is the watchdog enabled? You can also monitor the XRSn pin with an o'scope to see if you see the watchdog continuously resetting the device.

    003ff7dd _SCI_Boot
    003ff82b _SCIA_GetWordData

    You can also try putting a breakpoint at InitBoot which is the start after a reset to see if you land here. If you do it adds to the theory of a reset occuring.

    003ff8a1 _InitBoot

    Curious if the ISR is written in C or assembly?

    Another thing to check is the device errata. Make sure you are not violating the "Memory fetch past valid memory" headline. http://www.ti.com/lit/SPRZ295

    -Lori
  • 0 in reply to Lori Heustess
    Intellectual 475 points

    Hi Lori,

    Sorry for the late replay.

    The watchdog caused the RESET.

    The problem was that the ISR become too long and so the main loop become too slow. The ISR is written in C (optimizer was off) and the ISR was called every 10us (600 cycles), and the ISR duration was about 450 cycles (if I remember correctly). A little bit longer ISR, made the main loop several times slower.


    Now I switched on the optimizer and the ISR duration is ~300 cycles and everything is fine.

    Lori, thank a lot for your help.

    Lg
    Thomas

  • 0 in reply to Thomas Blocher
    TI__Guru* 93800 points

    That's great!  I'm glad you found the cause.

    Happy coding!

    Lori