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.

Code Memory 0x20000 and beyond not usable on 5419/5438?

Hello again,

My code has grown larger and the debug version now goes beyond the boundary of Bank1, entering Bank2 (0x20000). There is one problem, the program won't run if it goes beyond the address of 0x20000. The release version stays in the 0x20000 boundary, so it works fine. Before the debug version grew beyond 0x20000, it worked OK too.

Did I miss something? Yes, I did ALL the homework when my program acrossed the 64K bound, (address above 0x10000), address model, lib version, ISR location etc. what did I do wrong this time?

Thanks!

  • Hi graviton,

    you need to enable the --silicon_version (-v) mspx. Have a look at your project properties to verify this. In addition, the ISR location should be in the lower 64k Flash (Bank1).

    Rgds
    aBUGSworstnightmare 

  • Thanks! Yes, I have done both things when I crossed the 64K bound.

    Is there a limit for every 64K of memory space, and we have whole new set of hoops to jump each time?

  • Hello,

    graviton said:
    Is there a limit for every 64K of memory space, and we have whole new set of hoops to jump each time?

    No, there is no such limitation. Can you explain more precisely how the code fails? Have you partitioned certain portions of your code in higher memory that you are now unable to access? Do you get any errors or warnings when you compile and build? Are you coding in C or do you have a mixed C and ASM code?

     

    -Priya 

  • Thanks for the reply.

    There is no compliation and/or linking error, my code is primarily in C++ and a tiny bit of ASM to work around the RTC problem. the ASM code is modified from TI's sample to make it C++ linkable. I didn't explicitly put any code into higher memory space, the linker grows the memory space as I add more code in. The way the program fails is after the chip is flashed by debugger, the execution stop point is not at the begining of the main() routine. The main() is happened to be linked to a address above 0x20000, by the way. When I pause the excution, the execution stop point is anywhere inside the memory space below 0x20000, the processor is out of control.

    When all the code are limited in the space below 0x20000, like my release built, everything works OK.

  • Which version of CCS are you using? There were some issues in CCS 4.0.x related to accessing bank 2 flash memory, discussed in these posts:
    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/3230/11324.aspx#11324
    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/3180/11032.aspx#11032

    These should be resolved in CCS 4.1.0.

  • Thank you for the reply, I will upgrade to the CCS v4.1.

  • Is there a solution for those using CCE 3.1? I'm facing this problem in F5418 now. Program size should be over 60k by now.

    Please don't tell me to buy another CCS again. My boss ain't gonna be happy to hear this.

  • Kai said:

    Is there a solution for those using CCE 3.1? I'm facing this problem in F5418 now. Program size should be over 60k by now.

    Please don't tell me to buy another CCS again. My boss ain't gonna be happy to hear this.

    kai - if you purchased a full license of CCE, you should have been contacted to get a free upgrade to CCS v4.  if you weren't, please email ccs_subscriptions@list.ti.com and let them know that you need a CCS license.  in the meantime, i recommend that you download and install the 30-day trial version of CCS (www.ti.com/ccs) you can activate later when you get your license code.

  • I have 2 full licenses, and was never informed about the free upgrade exercise. When did the free upgrade started?

**Attention** This is a public forum