• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1102 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.

How does one debug the NDK?

Raymond Mack
Expert 1575 points


I am trying to figure out why the NDK scheduler does not seem to get the semaphore indicating that an ethernet packet has arrived. I trace down into EMACSnow.c but at very many places I get a "There is no AET resource to support this job." when trying to set breakpoints. What does this mean and is there a way to be able to set a breakpoint? Hitting F6 also does not step over such a situation. In one case this is a macro so it may make sense to replace the macro with real code to get breakpoints to set. Is this the right way to "fix" this?

It is also very unhelpful that the stack is apparently built by concatenating a very large number of files and then compiling them into a large image. The source file used is then apparently discarded.  It makes debugging the stack basically impossible.

I also tried to put System_printf calls in EMACSnow.c but that does not actually send output to the debug console. Why does System_printf not do output from EMACSnow.c?

Any pointers on how to do this debug? It is almost certainly a configuration issue, but I sure haven't discovered it!

  • 0
    TI__Guru* 96960 points

    There are a limited number of hardware breakpoints on the he TM4C129 devices. If you run out of them, you get an error when you try to set more. You need hw breakpoints because the code is in flash (if you put the code in RAM, you can have basically unlimited SW breakpoints). You can disable the default breakpoint that is used for "Run to main" in CCS to get another one.

    The code is compiled with optimization which confuses the debugger many times. Which version of TI-RTOS are you using. We've simplified the way to change the optimization in 2.10 (more details are in sections 3.1.1 and 8.1.4 of the TI-RTOS User Guide).

    Where the output from System_print goes depends on the System provider. Please refer to the "Output with System_printf()" section in the TI-RTOS User Guide for more details.

    Todd

  • 0 in reply to ToddMullanix
    Expert 1575 points

    Todd:

    Thanks for the quick response.  I am running tirtos_tivac_2_00_01_23.

    This is not a HW breakpoint issue because I can set other HW breakpoints. It is unclear what Eclipse means by AET resources.  I suspect that it has something to do with a lack of line numbers linking the source with the binary, but I haven't found a definition.  It is easy to get overwhelmed trying to find answers when you have been neck deep in alligators all day, so the answer may be in a forum and I just didn't search correctly.

    I will look at tirtos.mak and see if there is a way to keep it from deleting the source file after the library is made.  I am not sure why the system uses that method rather than just creating a library of individual objects. I may be old school, but those are a lot easier to use for debugging than one monolithic file.  Of course, it may make the linker faster to have one large file to search rather than a million little objects to search. And how often do you need t debug the system libraries!

    I will RTFM regarding the System_printf calls in the library.


    Have you ever seen a case where a configuration gets hosed such that the stack part of NDK does not get packets but EMACSnow is seeing the packets?  At least it is a fairly simple sequence. My QNX host sends 5 ARP request packets and the EMACSnow functions see the packets.  I have not been able to see where or how (presumably) the NDK main loop NetScheduler in netctrl.c is supposed be getting a semaphore that indicates EMACSnow has put a packet in the queue.  This is driving me nuts trying to find where the packets disappear.

    I fully believe I have accidentally changed some configuration option in the XDC system that makes the low level stuff disconnected from the high level stuff.  I just haven't found it!

    Ray

  • 0 in reply to Raymond Mack
    Expert 1575 points

    Todd:

    I found the place in ndk.bld to turn on debug for the stack. I hope it leaves the source file.  It is pretty obvious in that file how to make a debug version of the stack.  You have to do gmake -f tirtos.mak clean-ndk and then gmake -f tirtos.mak ndk to rebuild the library (go get a cup of coffee while it builds!).

    I have high hopes this will let me see where the packets are getting dropped.

    Ray

  • 0 in reply to Raymond Mack
    TI__Guru* 96960 points

    Hi Ray,

    There is a known issue with the EMAC on the TM4C129 boards. We have a work-around for it described on this page: http://processors.wiki.ti.com/index.php/TI-RTOS_Support (actually the link is on this page...search for EMAC).

    The work-around was incorporated into TI-RTOS 2.00.02.36: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/index.html

    Todd

  • 0 in reply to ToddMullanix
    Expert 1575 points

    I have applied the fix in EMACSnow_NIMUInit.  We discovered this very early and updated the driver library.  Without that fix the EMAC never does interrupts if I remember correctly.  We know we have the workaround installed correctly because we get interrupts and process packets at the hardware level.

    The packets appear to get lost when EMACSnow queues the packets and sends them up to the stack.