[#6657] gdbproxy fails when trying to debug hardware board twice

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#6657] gdbproxy fails when trying to debug hardware board twice

Submitted By: Peter Budny

Open Date

2011-06-21 09:37:14    

Priority:

Medium     Assignee:

Jeff Bartlett

Chad Wentworth

Jie Zhang

Board:

Custom     Silicon Revision:

Resolution:

Assigned (Not Started)     Fixed In Release:

N/A

Processor:

BF516     

Host Operating System:

Windows 7

toolchain rev.:

SVN 2011-6-13     kernel rev.:

State:

Open     Found In Release:

snaps

Is this bug repeatable?:

yes     

Summary: gdbproxy fails when trying to debug hardware board twice

Details:

 

I'm using a custom hardware board, which has a FT2232HL wired like a gnice+.

 

If I start gdbproxy with --reset, I can connect with gdb to debug the board. However, if I then set up SDRAM and the PLL, end the debugging session, and try to start another gdb session, gdbproxy crashes as soon as I try to access any memory on the board (e.g. by doing "load" from gdb).

 

The crash does not appear if I don't use --reset, or if I never touch SDRAM/PLL.

 

Here is the debug output from gdbproxy, after I connected with gdb and tried to do "load":

 

notice:    gdbproxy: connected

debug:     bfin: bfin_connect ()

debug:     bfin: emulation_enable ()

debug:     [0] DBGSTAT [0x4000]: core_fault cause:emuexcpt <before>

debug:     [0] DBGSTAT [0x4000]: core_fault cause:emuexcpt <after>

debug:     [0] DBGCTL [0x00a3]: emudatsz_40 emuirsz_32 emfen empwr <emulation_en

able>

debug:     bfin: emulation_trigger ()

debug:     [0] DBGSTAT [0x4000]: core_fault cause:emuexcpt <before>

debug:     [0] DBGSTAT [0x4000]: core_fault cause:emuexcpt <after>

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

info:      [0] core fault: DBGSTAT [0x400A]

info:      Resetting ...

debug:     Reset core(s)

debug:     Reset system

debug:     [0] DBGSTAT [0x404A] PC [0x0022000F]

debug:     bfin: bfin_current_thread_query ()

debug:     bfin: bfin_offsets_query ()

debug:     bfin: bfin_raw_query ()

debug:     bfin: bfin_read_mem (0x0022000F, ptr, 2, ptr)

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     bfin: bfin_read_mem () through Core [0]

debug:     bfin: bfin_write_mem (0x00000000, ptr, 0)

debug:     bfin: bfin_write_mem (0x00000000, ptr, 16336)

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     bfin: bfin_write_mem () through Core [0]

Assertion failed: emuready, file bfin.c, line 577

 

gdbproxy reports its version as 0.7.2; UrJTAG as 0.10 #5476.

 

Follow-ups

 

--- Mike Frysinger                                           2011-06-21 11:56:53

just to be clear, this is a Win7 host, not a coLinux or native Linux

 

--- Jie Zhang                                                2011-06-21 15:32:29

Hi Peter,

 

Can you show me the debug log of the first gdb session? Thank you!

 

--- Peter Budny                                              2011-06-21 16:02:19

I've attached the gdb sessions with the commands I entered, as well as the

complete gdbproxy debug output.

 

--- Jie Zhang                                                2011-06-21 16:55:04

Hi Peter,

 

Could you also attach simple.elf? Thank you!

 

--- Peter Budny                                              2011-06-21 17:39:27

Sure. It's a demo I wrote trying to get our RTOS running compiled with

Eclipse/GCC, and use a sleeping task to blink some LEDs. Unfortunately, I

suspect you may not be able to load it because it's written specifically for our

board. But, here it is anyway...

 

--- Peter Budny                                              2011-06-21 17:40:29

I should mention, it doesn't have to be "load", either. I can try

writing to 0xffa00000 or 0xffc00000 and it will still crash, even though those

are in core and I can read them both.

 

--- Jie Zhang                                                2011-06-21 18:14:15

I tried your example on ADI bf518 ezkit board on Linux host. I could not

reproduce your issue. I'm still trying to figure out how to build

urjtag/gdbproxy for Windows. But below is my guess is:

 

When you quit from the first gdb session, gdbproxy will resume program on the

board. So it will start running simple.elf from its entry address 0xffa00000.

But it caused a core fault (or called double fault). That why you see a core

fault during the second session. But what I'm wondering is why gdbproxy cannot

bring the processor out of core fault by reseting. You can try "kill"

when quit the first gdb session. "kill" will keep target halted so the

simple.elf just loaded will not run.

 

--- Mike Frysinger                                           2011-06-21 19:35:08

with debian based systems, it's simple.  install the mingw packages which are

part of the distro already, and then run:

./BuildToolChain -H mingw32 urjtag

(replace "ming32" with whatever toolchain prefix debian uses)

 

--- Peter Budny                                              2011-06-22 10:53:14

Jie,

 

I tried using "kill" as you suggested; it didn't make any difference

for me.

 

When I ran "kill", gdbproxy said:

debug:     bfin: bfin_kill ()

debug:     bfin: bfin_stop ()

debug:     bfin: emulation_trigger ()

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <before>

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <after>

info:      gdbproxy: session killed. Will wait for a new connection

 

Then when I reconnected and tried to write to 0xffa00000, it said:

notice:    gdbproxy: connected

debug:     bfin: bfin_connect ()

debug:     bfin: emulation_enable ()

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <before>

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <after>

debug:     [0] DBGCTL [0x08a7]: wakeup emudatsz_40 emuirsz_32 emeen emfen empwr

<emulation_enable>

debug:     bfin: emulation_trigger ()

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <before>

debug:     [0] DBGSTAT [0x0058]: cause:emuin emuready emudiovf <after>

debug:     Reset EMUPC

debug:     [0] EMUPC [0xffa0000c] <before>

debug:     [0] EMUPC [0xffa00000] <after>

info:      Resetting ...

debug:     Reset core(s)

debug:     Reset system

debug:     [0] DBGSTAT [0x404A] PC [0xFFFFFFFF]

debug:     bfin: bfin_current_thread_query ()

debug:     bfin: bfin_offsets_query ()

debug:     bfin: bfin_set_gen_thread (1)

debug:     bfin: bfin_read_single_register (37)

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     bfin: bfin_raw_query ()

debug:     bfin: bfin_write_mem (0xFFA00000, ptr, 0)

debug:     bfin: bfin_write_mem (0xFFA00000, ptr, 4)

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     bfin: [0] core_cache_status_get ()

debug:     Reset EMUPC

debug:     [0] EMUPC [0xef000006] <before>

debug:     [0] EMUPC [0xef000006] <after>

debug:     bfin: bfin_write_mem () through Core [0]

Assertion failed: emuready, file bfin.c, line 577

 

--- Jie Zhang                                                2011-06-22 11:20:28

It did have some difference. Now when gdb connects to gdbproxy for the second

session, the core is not in core fault mode. But reset causes core fault after

that. But I don't know how reset would cause core fault.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

gdb output.txt    text/plain    3812    Peter Budny

simple.elf    application/octet-stream    1500813    Peter Budny

gdbproxy debug output.txt    text/plain    21403    Peter Budny

Outcomes