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

CCS/66AK2H12: Proper Debug technique

Mike Dannhardt
Expert 2580 points
Part Number: 66AK2H12
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

I am having difficulty debugging my A15 ARM applications.

I have a couple of projects in my work space. CCS7.2. All the target configurations and GEL files I use for my EVM are the same.

The first project is a simple Hello World. From a cold start (everything disconnected and not powered up, CCS not running), I start everything up, launch the target config, load the GEL and connect arm_A15_0. I than Run→Load my test.out. It runs, hits my break points. All is good.

Question is, how to I properly terminate and then restart/debug? If I hit the red Terminate and then try to debug again using the debug Bug button, the core says it is running but nothing happens. Debug window says the core is (Running). I either need to r-click the core and Relaunch or hit the Bug a second time. I’m prompted with message that current debug session needs to stop and I agree. A new debug starts and I am then able to debug again seemingly fine.

I don’t mind all of the above but my next project is the NIMU_emacExample_EVMK2H_armBiosExampleProject. The first time I run it from a cold start it works. I can ping it and do the udp echo from the supplied winapp test application testudp.exe (it runs until fails: testudp: failed on size 1455). I can pause, debug, etc. All good. But if I terminate using the red Terminate CCS button and try to restart (using the Bug), Debug shows arm_A15_0 as ‘Disconnected’ (but the red terminate button is again available?). Sometimes I’ll hit the Bug again, get the warning about needing to terminate, say yes and then it will reload but the session terminates at

No source available for "do_AngelSWI(int, void *) [C:/ti\pdk_k2hk_4_0_6\packages\MyExampleProjects\NIMU_emacExample_EVMK2H_armBiosExampleProject\Debug\NIMU_emacExample_EVMK2H_armBiosExampleProject.out] at 0x80088cb8"

and the debug window shows:
“[arm_A15_0] ti.sysbios.family.arm.gic.Hwi: line 1200: E_undefined: Hwi undefined, intnum: 211
xdc.runtime.Error.raise: terminating execution”

After the above, it acts like the HelloWorld I first described. I can terminate (Red button) and then start another Debug session (Bug button) and every other time I hit breakpoints and can debug. HOWEVER: it the NetworkIPAddr() callback will never again get called. I can never ping it again. I have to reset the EVM before it will work again.

Sorry for the vagueness of this post but it is not a very repeatable sequence other than I don’t understand how to stop and restart a debug session without having to go through a EVM reset each time for the network example.

Mike

  • 0
    TI__Guru**** 171309 points
    Mike,

    One important consideration when loading and running code on a device is how much it affects its status when comparing to a power up or cold reset. This is even more critical when external devices such as the Ethernet PHY is involved.

    With this in mind, a simpler code such as Hello world can be reloaded many times to the device without major changes in outcome. When more complex code such NIMU_emacExample modifies external peripherals, a subsequent reload may work or not. That depends if the code properly resets the PHY or assumes it is coming from a power up or the PHY actually requires a power cycle to properly initialize. When I thoroughly used NDK a long time ago, the latter was usually the case.

    Back to how properly launch and terminate a debug session: when modifying the code and re-testing it, you may either adopt a few approaches:
    - If you are using a standalone Debug Probe, you can disconnect the core (or cores) via menu Run --> Disconnect Target, power cycle the board and re-connect (menu Run --> Connect Target) and re-load code (menu Run --> Load --> Load Program). That is the closest to terminating the debug session, but without the lag between the Terminate/Launch process.
    - If you are using an embedded Debug Probe, sometimes power cycling the board will get you completely disconnected (you can test this to see if it influences this). In this case, you can disconnect the core (or cores), issue a device or board reset, reconnect the core and reload the code.
    - With any Debug Probe, you can modify the code and either re-load it to the core (menu Run --> Load --> Reload Program) or, if no code changes are needed and you simply want to start over, you can simply Restart from the code entry point (menu Run --> Restart) or perhaps with a soft Reset (menu Run --> Reset --> some resets to choose). With these options the chances of subsequent runs do not work are higher. Also, don't forget that any Reset will undo many other configurations such as PLL or DDR/EMIF - you need to re-run the GEL script that performs the board/device initialization, which for the case of A15 is menu Scripts --> Global_Default_Setup

    The terminate button is usually used if you are switching targets or configurations, if anything else fails to work or if you are going home at the end of the day :)

    When working with multicore devices, you can also check the short clip below that helps loading multiple cores to multiple devices.
    https://youtu.be/tl-yal3rTqY

    Hope this helps,
    Rafael
  • 0
    Guru 92251 points

    Mike Dannhardt said:
    Question is, how to I properly terminate and then restart/debug?

    The problem is with SYS/BIOS program for a Cortex-A15 that the SYS/BIOS startup code attempts to invalidate the cache, but the Cortex-A15 treats the invalidate instruction as a clean/invalidate instruction. The end result is that:

    a) If you reset the EVMK2H, e.g. by using the reboot command from the BMC serial terminal, then you can successfully download and run a SYS/BIOS program for a Cortex-A15 which enables the processor cache.

    b) If you terminate the debug session and then start a another debug session without a reset of the EVMK2H then the program crashes since the SYS/BIOS startup code which attempts to invalidate the cache actually flushes some stale data in the cache from the previous run to memory. This corrupts the contents of the program in memory leading to crashes.

    See Does the ARM Cortex-A15 treat the invalidate instruction as a clean/invalidate instruction due to a design decision or due to an errata? for some background information.

    My work-around is to reset the EVMK2H before starting a debug session. This is slow, since has to run the GEL script initialisation every time.

    Mike Dannhardt said:
    I don’t mind all of the above but my next project is the NIMU_emacExample_EVMK2H_armBiosExampleProject. The first time I run it from a cold start it works. I can ping it and do the udp echo from the supplied winapp test application testudp.exe (it runs until fails: testudp: failed on size 1455).

    I can repeat the issue with testudp failing on size 1455. I also found a different udpSendReceive program works at a size of 1454 but fails at size 1455; in that the NIMU_emacExample_EVMK2H_armBiosExampleProject example never echos UDP packets with a data size of 1455 (or larger). Suspect a problem with the example (or the NDK).

  • 0 in reply to Chester Gillon
    Expert 2580 points
    Thank you Rafael and Chester. I can disconnect the core, issue a reboot via the BMC terminal, reconnect (runs my GEL) and then download my build to re-run. A much better approach than what I was doing before.

    Chester -thank you for confirming the UDP failure with the example. I have not looked into the problem at all since I will be using TCP.

    Mike
  • 0 in reply to Mike Dannhardt
    Expert 2580 points
    One problem the above approach seems to have is that System_printf() no longer works on subsequent runs of the debug sessions. I can see the System_printf() data still going into the SysMin OuputBuffer and that buffer clearing on BIOS_exit() but it no longer makes it to the Console window on CCS7.2. I have to do a complete terminate and start over from launching the Target Configuration.
  • 0 in reply to Mike Dannhardt
    TI__Guru**** 171309 points
    Mike,

    The System_printf() works similarly as the regular printf() and sets a SW breakpoint during code load - I suspect this is being cleared/disabled during soft resets.

    Some additional details are shown at:
    e2e.ti.com/.../2284591

    I am still checking for a way to re-enable these breakpoints without having to restart the debug session or reload code. I will get back if I find anything.

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Guru 92251 points

    desouza said:
    The System_printf() works similarly as the regular printf() and sets a SW breakpoint during code load - I suspect this is being cleared/disabled during soft resets.

    I haven't tried it, but maybe de-selecting the "Allow software breakpoints to be used" option to force hardware breakpoints to be used will work-around the problem:

  • 0 in reply to Chester Gillon
    Expert 2580 points
    Thank you Chester. I tried deselecting "Allow software breakpoints to be used" and then starting from scratch (new EVM power on), Launched the target config, loaded the GEL and then connected to ARM0. Loaded and ran my application with good System_printf() output to console. Disconnected ARM0, reset power on EVM, reconnected, reloaded my application and ran. The application works (functions as expected) but no prints to the CCS console.

    I need to power cycle the EVM and re-Launch the target configuration in order to get the print to show on the Console (like pressing the Red Terminate square menu bar button).

    I do appreciate the suggestion.

    Mike