OK, we're getting closer - now I see the threads in Eclipse most of the time. "Mmost of the time", but sometimes they just disappear... Nothing but restarting OpenOCD helps.
I have two threads and a breakpoint in each of them. I run the code and hit the breakpoint in first thread a few times and when I expect the code to finally reach the second thread... the debugger stops in vPortYieldFromISR() continuously - nothing helps but removing the breakpoint(s). Any hints on that? Because in this shape such support in Eclipse is unusable... I can also cause such problem in GDB run via command line: > >arm-none-eabi-gdb lpc1769_blink_led.elf > GNU gdb (GNU Tools for ARM Embedded Processors) 7.3.1.20120316-cvs > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i586-mingw32 --target=arm-none-eabi". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from > d:\Elektronika\ARM\projects\lpc1769_blink_led_freertos\out/ > lpc1769_blink_led.elf...done. > (gdb) set arm abi APCS > (gdb) target remote localhost:3333 > Remote debugging using localhost:3333 > Task1 (pvParameters=0x0) at main.c:178 > 178 count1++; > (gdb) monitor reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc > (gdb) b main.c:178 > Breakpoint 1 at 0x4da: file main.c, line 178. > (gdb) b main.c:189 > Breakpoint 2 at 0x4fa: file main.c, line 189. > (gdb) c > Continuing. > stepi ignored. GDB will now fetch the register state from the target. > > Program received signal SIGINT, Interrupt. > 0x1fff0080 in ?? () > (gdb) c > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > Invalid ACK 0x7 in JTAG-DP transaction > > Breakpoint 1, Task1 (pvParameters=0x0) at main.c:178 > 178 count1++; > (gdb) c > Continuing. > > Breakpoint 2, Task2 (pvParameters=0x0) at main.c:189 > 189 count2--; > (gdb) c > Continuing. > > Breakpoint 1, Task1 (pvParameters=0x0) at main.c:178 > 178 count1++; > (gdb) c > Continuing. > > Breakpoint 2, Task2 (pvParameters=0x0) at main.c:189 > 189 count2--; > (gdb) info threads > [New Thread 268438336] > [New Thread 268437488] > [New Thread 268436640] > [New Thread 268437912] > [New Thread 268435792] > [New Thread 268436216] > Id Target Id Frame > 7 Thread 268436216 (LED2) 0x00001de8 in vPortYieldFromISR () > at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 6 Thread 268435792 (LED1) 0x00001de8 in vPortYieldFromISR () > at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 5 Thread 268437912 (T3) 0x00001de8 in vPortYieldFromISR () > at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 4 Thread 268436640 (UART) 0x00001de8 in vPortYieldFromISR () > at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 3 Thread 268437488 (T2 : : Running) Task2 (pvParameters=0x0) > at main.c:189 > 2 Thread 268438336 (IDLE) 0x00001b36 in prvCheckTasksWaitingTermination > () at FreeRTOS/tasks.c:2086 > * 1 Thread 268437064 (T1) 0x00001de8 in vPortYieldFromISR () > at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00001de8 in vPortYieldFromISR () at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 200 } > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00001de8 in vPortYieldFromISR () at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 200 } > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00001de8 in vPortYieldFromISR () at FreeRTOS/portable/GCC/ARM_CM3/port.c:200 > 200 } > (gdb) As you see, everything works fine until I issue "info threads"... If I disconnect from OpenOCD, restart it, and connect again - everything works fine. If I issue "info threads" (to cause the problem), shutdown GDB, start it again - everything works fine. Maybe that's because "arm abi APCS" is actually wrong, but it's the simpliest way to get rid of "remote reply packet g" problem... Sometimes I can even crash GDB: > (gdb) c > Continuing. > /home/build/work/jenkins-daily-build/src/gdb/gdb/thread.c:620: > internal-error: i > s_thread_state: Assertion `tp' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) I've tried the same with CodeSourcery's version of GDB (older, does not require "arm abi APCS" to work fine), and it's almost the same - it crashes almost every time I do "info threads", with a similar message: > (gdb) c > Continuing. > /scratch/jwlemke/2011.09-arm-eabi-lite/obj/gdb-src-2011.09-69-arm-none-eabi-i686 > -mingw32/gdb/thread.c:598: internal-error: is_thread_state: Assertion `tp' > faile > d. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) Just before the crash, during "info threads", OpenOCD says: > Error: JTAG-DP STICKY ERROR > Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0xa5a5a5a6 If I change command order (connect to target, info threads, c, c, c, ...) it is also blocked on another system function: > (gdb) c > Continuing. > Note: automatically using hardware breakpoints for read-only addresses. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00001aa6 in prvCheckTasksWaitingTermination () at FreeRTOS/tasks.c:2055 > 2055 { Any ideas? 4\/3!! ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
