Re: Debugging threads
Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org> Thu, 28 Jun 2018 20:19:02 +0200
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
>>>>> "Ole" == Ole Reinhardt <ole.reinhardt-L1vi/[email protected]> writes: Ole> Hi Uwe, I remember we had a similar discussion quite some time Ole> ago. If I remember correctly, someone just wrote Nut/OS for gdb Ole> some (long) time ago. But I'm very unsure... Ole> I think you'd need a tracing solution. If the debugger stops in the Ole> idle thread you'll quite likely be in the idle thread, which means Ole> that your code waits for something (for some data on a socket or Ole> uart, a mutex, a sleep, etc.) an no other thread is runnable. Ole> So you ideally need to trace back your code path into the past to Ole> see from where you changed into the idle thread. Hello Ole, nice to hear from you again! In the meantime, I revived and fixed some issues in http://openocd.zylin.com/#/c/3881/ It works soemhow with on a nucle_l053 and I can see the threads. However the hand does not happen on L053. On f3 discovery, where th thread hang happens, OpenOcd has the old problems with halting the target and the thread list does not make sense. I have to dig deeper. And maybe I have to activate and understand SWO... Bye -- Uwe Bonnes bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion