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.

issue with debug (fail to halt in debug session)

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hi,

MCU - TMS570LS3137

Emulator - XDS100v2

CCS ver - 5.4

Project - Hello World with default CCS setting

When I connect board with emulator, enter to debug session, then I get following error - 

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Trouble Reading Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
CortexR4: Trouble Reading Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249

Program is loaded successfully into on-chip flash, but I am not able to setup debug point. 

When property (pressing Alt+Enter) tab is open, then option for "halt the target on connect" (shown in below image) is disabled. 

Help me, how to enable debug procedure with TMS570 processor.

  • Hi,
    I will suggest that you start with any HalCoGen examples rather than the Hello World example. The Hello World example does not setup the MCU, i.e. the CPU registers, stack pointers and the overall system.
  • Hi Charles,

    Thanks for reply.

    My project is based on HalCoGen and I am facing same issues with it.

    --Ankitkumar
  • Hi Ankitkumar,
    What do you mean you can not setup a debug point?

    When you first load your program into flash, if the flashing is successful then the debugger will halt at the entry point in the main()? Can you even get to this point? If you terminate the debug session and relaunch the debug session again normally the debugger will halt the CPU and stop at a certain line of code. If you put a breakpoint at another line and let the CPU run then it will halt at your breakpoint line again. Are you saying none of this work for you?

    Also I suggest that you update to the latest CCS version. CCS 5.4 is kind of old.

    Lastly, can you tell me which EVM you have? Is the LaunchPad or the HDK or your own custom board?
  • Hi Charles,

    Thank you for your reply. However 

    I cannot get to the point where the debugger halts at the entry point in main() .(When I first load my program into flash, the flashing is successful but the debugger does not halt at the entry point in the main()). When I click on "Debug" the console displays the following warning:
    CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Trouble Reading Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    CortexR4: Trouble Reading Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    CortexR4: Trouble Writing Register REG_AHB_DOWNLOAD: No mapped register was found for 1627402249
    The code gets programmed into the flash, which is visible as when I reset the board, the code that is programmed recently is seen to be functioning (i.e running on the board).
    Also, when the debugging is paused, CCS shows the error "No source available for "0x8000658" (Screenshot attached)
    Is there any way I can add setup debug points/ breakpoints to halt the program; as when running from flash, this feature is unavailable?
    I have tried using CCS 6 as well, but the problem persists. I'm not using any Evaluation Modules (EVMs) but a custom made board.
    Kindly tell me if there are some settings that have to be altered that are fixed by default which are forcing this behavior.

  • HI Anil,

      Can you show the XDS100 target configuration you use? It should look like below. I suspect it may have be the emulator related. Let's make sure your target configuration is proper.

      

  • Hi Charles,

    Thank you for the prompt reply. Here's the screenshot of the target configuration:

    Hope what you need to see is clear. Also, the target configuration file is attached.5684.TMS570LS3137.zip

    Thanks

  • Hi Ankitkumar,

     In your original post you mentioned that you use XDS100 as your emulator. Here you are showing you are using J-Link. I think there will be some support issue on the J-Link using CCS.

     Below is the note from Segger webpage on CCS support. I'm not sure if you have a driver issue. The problem is that likely you may not get support from Segger or our CCS team until CCS v6.2 is released. In the meantime, do you have other emulator that you can use? If you use the LaunchPad or the HDK they come with the built in XDS110 and XDS100 emulators respectively.

  • Hi Charles,

    I'm afraid to say that when using the emulator XDS100v2, we get the same issue. I'm not using the Launchpad or the HDK either.

  • Hi Ankitkumar,
    Do you get the same errors using XDS100v2?

    Do you have the HDK? Try your test program on the HDK with the same CCS you currently have. Most likely I don't you have any problem. But please try it just to make sure so we can isolate the problem to your board.
  • Hi Charles,

    I am getting the same errors using XDS100v2. 

    Also, I do not have the HDK. After looking for solutions online, I found out that it is possible to achieve something similar to what I want to by making changes in the GEL  and sys_core.asm files.

    https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/147475

    How do I go about making changes to the GEL file?

  • HI Ankitkumar,
    I'm not clear as to what is your intention to change the GEL? What do you want to change? Do you want to run code from the RAM as discussed in the post you refer?
  • ankitkumar,

    you can find out which gel file is being used (or change the GEL file being used) by inspecting the target configuration file you use to launch the debug session.
    (First screenshot).


    after the debug session is launched, you can use the Tools->GEL Files  (second screenshot - and you must be in the debug perspetive).

    this brings up a window that lists the gel files (third screenshot) and double clicking the file opens it for editing (fourth screenshot).

  • Thank you, Charles and Anthony

    I have been able to locate the GEL file successfully and made some changes in it. 6765.tms570ls3137.gel

    I can now add breakpoints into the code while the code is in the FLASH. Thanks!

  • Hi ankitkumar,
    Looks like what you did was to swap the RAM memory to address 0x0 on connect. This was the question I asked if you were trying to run code from RAM as suggest by other post. You don't really need to hack the GEL if you want to run code from RAM.

    In CCS Debug perspective, you can go to Scripts->CCS_MemMap_RAM_at_0x0 and Scripts->Target_RAM_to_0x0 that will do the same thing. This is a tip you can use instead.
  • Hi Charles,
    Thanks for the reply. I did as you mentioned, but the thing didnt work.
    We are trying to follow the link given below and make changes accordingly. But the problem is when emulator goes in debug session, it do not reach main() and it gets stuck in forever loop at sys_startup.c file line no 267 (infinite for loop).
    e2e.ti.com/.../210010
    Can you help me out with this?
  • Hi ankitkumar,
    Can you send me the sys_startup.c?
  • Sure Sir. 

    The session gets stuck at line number 267 (Infinite for loop).

    7178.sys_startup.c

  • Hi Ankitkumar,

    The MCU detects an error. This error is a severe error of type ESM group 3. Please check the ESMSR3 register and determine which flag is set.
    Did you also see the nERROR LED turned ON? Are you running any ECC test?

    In the debugger go to Registers browser and under the Esm->Sta3 you will see some flags set. You can also clear these flags by writing a '1' to them.

    if ((esmREG->SR1[2]) != 0U)
    {
    /* USER CODE BEGIN (24) */
    /* USER CODE END */
    /*SAFETYMCUSW 5 C MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
    /*SAFETYMCUSW 26 S MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
    /*SAFETYMCUSW 28 D MR:NA <APPROVED> "for(;;) can be removed by adding "# if 0" and "# endif" in the user codes above and below" */
    for(;;)
    {
    }/* Wait */
  • Hi Charles,

    The nERROR LED goes not turn ON. And I am not running any ECC Test. 

    I am afraid to say that the behavior of the debugger is going random. Now as I go to debug session, it is getting stuck at undefEntry in sys_intvecs.asm file. Also, for my application project, the debugger is getting stuck at some other location in forever loop for efcClass2Error() function in sys_selftest.c.

  • Hi Ankitkumar,
    Are you able to reproduce the efcClass2Error or other seen errors in different units? I hope you have more than one TMS570LS3137 unit.
  • Hi Charles,
    I have tested my application on other similar board, and observed that the problem persists. It is giving same errors on both the units.
  • Hi Ankitkumar,
    Can you send me your CCS project?
  • Hello Charles,

    I have made a custom project that I am attaching here. It is working fine with flash, but when I change gel file for making it run from RAM, it gets stuck at undefEntry. 

    Note: I have also attached the GEL file in which I changed OnTargetConnect() function to swap memory from FLASH to RAM.

    0020.SampleCode_N_Gel.rar

  • Hi Ankitkumar,
    Today is a US holiday. I will have a look at your project when I get back to work.
  • Hi Ankitkumar,

    I went through your code and I think the problem is stack related. Below is how you declare your stack.

    userSp .word 0x08000000+0x00001000
    svcSp .word 0x08000000+0x00001000+0x00000100
    fiqSp .word 0x08000000+0x00001000+0x00000100+0x00000100
    irqSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100
    abortSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100
    undefSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100

    When you swap between the RAM and flash via the GEL, the RAM will start at 0x0 while the flash will be swapped and starts at 0x08000000. If you declare the stack pointers at 0x08000000 then this is now the flash region which can not be used for stack. You should change to below code instead. Please give a try if you swap memory between RAM and flash and intend to run code from RAM.

    userSp .word 0x00010000+0x00001000
    svcSp .word 0x00010000+0x00001000+0x00000100
    fiqSp .word 0x00010000+0x00001000+0x00000100+0x00000100
    irqSp .word 0x00010000+0x00001000+0x00000100+0x00000100+0x00000100
    abortSp .word 0x00010000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100
    undefSp .word 0x00010000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100

    Here the stack starts at 0x00010000. If you have an application that needs more program space than 64kbytes then you will need to adjust the stack pointer accordingly, for example, like 0x00020000 which starts at 128kbytes.
  • Hi Charles,

    I have declared the stack from 0x10000, but the result is same. It is getting stuck at the same location (undefEntry). Also, I tried with the start stack location 0x20000, in this it is getting stuck at different locations every time.

    Thanks and regards,
    Ankit
  • Hi Ankit,

     I ran your code and the reason that it fails is because you have PBIST test and memory initialization in the sys_startup.c file. When you run your code from flash these selftests and memory initialization are ok since they don't affect your program space which is in the flash. However, when you run your code from RAM then it will be a problem.  At first your code is loaded to the SRAM for execution. However, your code instruct for a PBIST test. PBIST test is a memory test which destroys the program currently residing in the SRAM. In addition, you have memInit() to initialize the SRAM. This function will reset the entire content of the SRAM to zero. This again destroys the program. Now you are asking the CPU to execute code from RAM with contents of zeros and this leads to undefined.

    I have removed some of the lines in your sys_startup.c. You can compare with your original file. It should work now. Make sure you still have the new stack pointer as we pointed out before.

    4024.sys_startup.c

  • Hello Charles,

    The code is working now. I am able to set the required breakpoints also.
    Thanks for your support.

    Regards,
    Ankit
  • Hi Ankit,
    Glad your problem is resolved.