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
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

------------------------------------------------------------------------------
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

Reply via email to