Hi everyone,
I'm still working on implementing new CPU to RTOS.
ARM7TDMI and ARM926-ejs are nearly ok but I've got the same error as here.
After I do a "info threads" gdb crash with :
/thread.c:613: internal-error: is_thread_state: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable./
Without RTOS or if I don't ask "info threads" there is no problem.
So did someone made any improvements ?
I saw this patch (http://sourceware.org/bugzilla/show_bug.cgi?id=12228)
but it's not possible to use it, fail to compile.
Best regards
Vivien
On 17/05/2012 21:15, Paul Fertser wrote:
> Hi,
>
> Sorry it took me so long to reply, but finally i had enough time and
> equipment at hand...
>
> On Sat, May 12, 2012 at 03:45:28PM +0200, Freddie Chopin wrote:
>> 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.
> Ok, i have no clue about Eclipse yet, but your gdb issue seem to be
> clear now.
>
>> 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).
> ...
>> As you see, everything works fine until I issue "info threads"...
> ...
>
> Well, i've finally got ahold on an STM32L Discovery board, brought it
> home, connected it, compiled git head of OpenOCD... That st-link
> support is amazing, the embedded st-link v2 works out-of-the-box,
> perfectly!
>
> I needed a trivial patch to the FreeRTOS support to let it know about
> "stm32_stlink" target name (i'm not sure if it's that good of a
> choice, does stlink actually supports other Cortex-M3 devices?) and i
> made your project more applicable to STM32 (by commenting out all
> hardware-specific activities).
>
> What i saw when i tried to reproduce your gdb session is that indeed
> it doesn't work the way you expect it to, but it does work
> somehow. The trick is to switch to the thread that's "Running"
> according to the "i th" output, and then you can do "c" all right:
>
> (gdb) monitor reset halt
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0800022c msp: 0x20004000
> (gdb) c
> Continuing.
>
> Program received signal SIGINT, Interrupt.
> Task2 (pvParameters=0x0) at main.c:181
> 181 {
> (gdb) i th
> Id Target Id Frame
> 7 Thread 536871200 (LED1) LED_Task (pvParameters=0x8000b10) at main.c:151
> 6 Thread 536871624 (LED2) LED_Task (pvParameters=0x8000b98) at main.c:151
> 5 Thread 536872048 (UART) uart_task (pvParameters=0x0) at main.c:203
> 4 Thread 536872472 (T1) Task1 (pvParameters=0x0) at main.c:170
> * 3 Thread 536872896 (T2) Task2 (pvParameters=0x0) at main.c:181
> 2 Thread 536873320 (T3 : : Running) Task3 (pvParameters=0x0) at
> main.c:197
> 1 Thread 536873744 (IDLE) prvIdleTask (pvParameters=0x0) at
> FreeRTOS/tasks.c:1872
> (gdb) c
> Continuing.
>
> Program received signal SIGINT, Interrupt.
> Task2 (pvParameters=0x0) at main.c:181
> 181 {
> (gdb) c
> Continuing.
>
> Program received signal SIGINT, Interrupt.
> Task2 (pvParameters=0x0) at main.c:181
> 181 {
> (gdb) t 2
> [Switching to thread 2 (Thread 536873320)]
> #0 Task3 (pvParameters=0x0) at main.c:197
> 197 count3 *= 2;
> (gdb) c
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> vTaskDelay (xTicksToDelay=999) at FreeRTOS/tasks.c:716
> 716 }
> (gdb) i th
> Id Target Id Frame
> 7 Thread 536871200 (LED1) vTaskDelay (xTicksToDelay=500) at
> FreeRTOS/tasks.c:716
> 6 Thread 536871624 (LED2) vTaskDelay (xTicksToDelay=50) at
> FreeRTOS/tasks.c:716
> 5 Thread 536872048 (UART) vTaskDelay (xTicksToDelay=1500) at
> FreeRTOS/tasks.c:716
> 4 Thread 536872472 (T1 : : Running) Task1 (pvParameters=0x0) at
> main.c:175
> 3 Thread 536872896 (T2) Task2 (pvParameters=0x0) at main.c:181
> * 2 Thread 536873320 (T3) vTaskDelay (xTicksToDelay=999) at
> FreeRTOS/tasks.c:716
> 1 Thread 536873744 (IDLE) prvIdleTask (pvParameters=0x0) at
> FreeRTOS/tasks.c:1872
> (gdb) t 4
> [Switching to thread 4 (Thread 536872472)]
> #0 Task1 (pvParameters=0x0) at main.c:175
> 175 count1++;
> (gdb) c
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> vTaskDelay (xTicksToDelay=1000) at FreeRTOS/tasks.c:716
> 716 }
> (gdb) i th
> Id Target Id Frame
> 7 Thread 536871200 (LED1) vTaskDelay (xTicksToDelay=500) at
> FreeRTOS/tasks.c:716
> 6 Thread 536871624 (LED2) vTaskDelay (xTicksToDelay=50) at
> FreeRTOS/tasks.c:716
> 5 Thread 536872048 (UART) vTaskDelay (xTicksToDelay=1500) at
> FreeRTOS/tasks.c:716
> * 4 Thread 536872472 (T1) vTaskDelay (xTicksToDelay=1000) at
> FreeRTOS/tasks.c:716
> 3 Thread 536872896 (T2 : : Running) Task2 (pvParameters=0x0) at
> main.c:186
> 2 Thread 536873320 (T3) vTaskDelay (xTicksToDelay=999) at
> FreeRTOS/tasks.c:716
> 1 Thread 536873744 (IDLE) prvIdleTask (pvParameters=0x0) at
> FreeRTOS/tasks.c:1872
> (gdb)
>
> I never noticed that before probably because it seemed natural to have
> to switch to the running thread, but now thinking more about it i
> guess it might be that gdb should switch automatically. That needs
> more research but the support is already useable as you can see.
>
> Using GNU gdb (Gentoo 7.3.1 p2) 7.3.1 here with
> set tdesc filename target.xml
> set architecture arm
>
> I now have everything needed to debug any issues (that do not require
> Eclipse) i think, please do not hesitate to report your findings :)
>
> HTH
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
