User forums > Nightly builds

The 11 February 2012 build (7790) DEBUGGER BRANCH version is out.

<< < (3/11) > >>

oBFusCATed:
The last log seems OK.
Can you post one valid debug session with command line gdb?

themaddin:
I think the last log seems not OK. Every instruction is confirmed twice. And it seems also executed twice.
Why do you think the log is OK?

Here is a valid debug session i typed manually to the DOS command line.

--- Code: ---(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0x00000000 in ?? ()
(gdb) monitor speed auto
Select auto JTAG speed (4000 kHz)
(gdb) monitor endian little
Target endianess set to "little endian"
(gdb) load
Loading section .isr_vector, size 0x184 lma 0x8000000
Loading section .text, size 0x1958 lma 0x8000184
Loading section .data, size 0x24 lma 0x8001adc
Start address 0x800058c, load size 6912
Transfer rate: 450 KB/sec, 2304 bytes/write.
(gdb) monitor reset
Resetting target
(gdb) break main.c:63
Breakpoint 1 at 0x80004b6: file D:\Evaltest207\source\Main.c, line 63.
(gdb) cont
Continuing.

Breakpoint 1, main () at D:\Evaltest207\source\Main.c:63
63        GPIO_WriteBit(GPIOC,GPIO_Pin_7,Bit_SET);//LED4 on
(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x080004b6 in main at D:\Evaltest207\source\Main.c:63
        breakpoint already hit 1 time
(gdb)

--- End code ---

If I do the same with the Code::Blocks GUI at first the break point is set twice. This is no problem unless you want to remove the break point. If I click continue Code::Blocks stops at the break point and the target is running. I think this is because Code::Blocks executes the instruction "continue" twice.

oBFusCATed:
Strange.
Is this version of gdb available to the general public?
Also Do I need some hardware to reproduce the problem?

themaddin:
I will look if there is a solution to repruduce the problem without hardware and public tools.

oBFusCATed:
Another option is to debug it yourself.

You can put a breakpoint in PipedProcess::SendString and you can inspect the coming commands.

Something else you could do is to try different end of line mode for the wxTextOutputStream.
I have a guess, that using wxEOL_UNIX will fix you problem.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version