• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 585 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.

Compiler/TMS320F28379D: Flash To Ram

Hakan B
Expert 1110 points
Part Number: TMS320F28379D


Tool/software: TI C/C++ Compiler

Hi guys,

I want to copy my application from flash to ram and run it on the ram. I did that with my F28335 using below link.

When I do the same thing with my F28379d, I have a problem. The program does not stop at beginning of main function, it automatically starts execution, when I start debugging. It works fine but I want the cpu to stop at the beginning of main function. How can I do that? (By the way, everything works fine in the RAM configuration)

Hakan

  • 0
    TI__Mastermind 21305 points
    Kadir,

    Make sure you have specified the entry symbol for your application, usually _c_int00. This will ensure that the code branches to the start of the C-environment initialization routine. The codestart section should be place in memory with the linke command file (.cmd). Make sure you also have the respective CodeStartBranch.asm file in your flash project.

    Check out Chapter 6 in this document for more information: www.ti.com/.../spra958l.pdf

    Regards,
    Ozino
  • 0 in reply to Ozino Odharo
    Expert 1110 points
    Ozino,

    I check the entry symbol. It is "code_start", which a section in the CodeStartBrach.asm. It disables WD and jumps to copy_section, which copies .text, pinit, etc from flash to ram and then jumps to _cc_int00 (LB _c_int00).

    I also checked and verified that codestart is defined in cmd file, mapped to BEGIN_FLASH, which is in Page 0, has the address 0x080000 and length 0x00002. Moreover wddisable and copysection are also defined in cmd file (FLASHA in Page0)

    When I pause the pragram while debugging, I can see that the call stack starts with c_int00 -> _args_main -> main -> My function. So everything seems to be correct as far as I can see. But I can not understand why it doesn't stop at the beginning of main function.

    Thanks.
  • 0 in reply to Hakan B
    TI__Mastermind 21305 points

    Kadir,

    Thanks for checking that. In CCS, there is a setting for memory load options to disable the breakpoints when loading a program. If you have this enabled, then debugger would not stop at main. Can you please check that this is not the case in your project?

    Additionally, what version of CCS are you using with your project?


    Thanks,
    Ozino

  • 0 in reply to Ozino Odharo
    Expert 1110 points
    Ozino,

    The only setting I could find is "Disable all breakpoints when loading a different program". Enabling or disabling it, didn't change anything. My CCS version is 7.4. While googling the problem, I've found this.

    processors.wiki.ti.com/.../C2000_Breakpoints_in_code_loaded_to_Flash_and_run_from_RAM

    It says:

    Introduction
    In C2000 applications, software breakpoints set in code regions that are loaded to Flash but run from RAM and enabled prior to loading code, may not work as expected. The breakpoints will appear be set correctly in the RAM address but program will not halt when the code is run the first time after a load/reload. If the breakpoint is simply disabled/re-enabled by unchecking and re-checking the check box in the Breakpoints view then it will halt correctly at those breakpoints (until another reload of the program). Also "Trouble removing Breakpoint" messages will appear in the console when the breakpoint is disabled. (Kadir: I get this message as well)

    Explanation
    When a software breakpoint is set, the emulation driver reads the instruction at that location and replaces it with a software breakpoint op-code that will then halt the target when in debug mode. The debugger somewhat hides this from you so you can still see the original disassembly and/or modify it.

    If the application writes a new instruction to the address where a software breakpoint has been set (as in the case of code that is copied from Flash to RAM at boot time), the special halting opcode will be replaced with this new instruction. This effectively removes the breakpoint without the debugger's knowledge. This is why the breakpoints fail to halt, and also why an error is printed when you remove it (as a remove writes the original opcode back, but it checks that the breakpoint opcode is still there first).




    There is also a workaround on the webpage, which looks promising. But it is very strange that I didnt face this problem with my old F28335. I only see this problem with my new F28379D. Very interesting!! Is there any TI employee that can explain why this phenomenon does not happen with F28335?

    Ozino, thanks for your help by the way.

    Regards,
    Hakan
  • 0 in reply to Hakan B
    TI__Mastermind 21305 points

    Hakan,

    Thanks for the feedback. What version of CCS was used when you tried the same procedure with the F28335?

    Regards,
    Ozino

  • 0 in reply to Ozino Odharo
    Expert 1110 points
    Ozino,

    It was CCS 5.5. By the way, I tried to put a HW breakpoint like mentioned in the solution above. It worked. Nevertheless it is not comfortable to put a HW breakpoint to the beginning of main function every time. Luckly, I mostly work with RAM configuration, which works flawlessly. Flash to Ram is my release configuration.

    Regards,
    Hakan
  • 0 in reply to Hakan B
    TI__Mastermind 21305 points

    Hakan,

    I am going to forward this post to the CCS team. They will be able to comment what changes have occurred with regards to the behavior you noticed between CCS 5.5 and CCSv7.4.

    Regards,
    Ozino