USB PHY Dead?

[aneves]

Hi Larry,

Thanks for your guidance.

I've modified the gdb script like so. This removes any references to the write_sswitch_reg:

Code: Select all

connect
thread 1
file ./image_n0c0_2.elf
set arch xs2_reva
b write_sswitch_reg_no_ack
commands 1
silent
printf "  write_sswitch_reg_no_ack(0x%x, 0x%x, 0x%x);\n", $r0, $r1, $r2
c
end
b _done
commands 2
silent
end
load 
c
q

When I run this script, I get an error from gdb - but no crash! The error is "Invalid download offset:Rebootbin/./imagen0c0_2.elf as seen in the output below:

Code: Select all

C:\Users\Amandio\workspace\Device Reboot\bin>xgdb -x script
GNU gdb (XGDB) Community_14.2.1 (build 15182, Jun-24-2016)
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=xcore-elf".
For bug reporting instructions, please see: http://www.xmos.com/support.

0xfff004c8 in ?? ()
[Switching to thread 1 (tile[0] core[0])]#0  0xfff004c8 in ?? ()
Breakpoint 1 at 0x402d4
Breakpoint 2 at 0x4040c
Loading image to XCore 0
C:\Users\Amandio\workspace\Device Reboot\bin/script:15: Error in sourced command file:
Invalid download offset:Rebootbin/./image_n0c0_2.elf.
(gdb)

Any idea why this image is failing to load in xgdb?

[larry]

Could it be that there is problem on Windows expanding the path with spaces? ("Device Reboot")

[aneves]

You're right, there is something up with resolving file paths. I created a new project called DeviceReboot and verified everything having to do with the build and resulting binary had no spaces in it. When I run the same script xgdb gave me this error:

Code: Select all

C:\Users\Amandio\workspace\DeviceReboot\bin>xgdb -x script
GNU gdb (XGDB) Community_14.2.1 (build 15182, Jun-24-2016)
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=xcore-elf".
For bug reporting instructions, please see: http://www.xmos.com/support.

0xfff004c8 in ?? ()
[Switching to thread 1 (tile[0] core[0])]#0  0xfff004c8 in ?? ()
Breakpoint 1 at 0x402d4
Breakpoint 2 at 0x4040c
Loading image to XCore 0
C:\Users\Amandio\workspace\DeviceReboot\bin/script:15: Error in sourced command file:
C:UsersAmandioworkspaceDeviceRebootbin/./image_n0c0_2.elf: No such file or directory.
(gdb) connect
0xfff004c8 in ?? ()
(gdb) thread
[Current thread is 1 (tile[0] core[0])]
(gdb) quit

Typing each command manually in the xgdb shell I found the error came from the load command and gave the same error. Looks like the file path is getting mangled and losing the directory separators when trying to resolve a relative path.

If I specify an absolute path to the image file the script works. So the script now looks like this (note the full path on line 3):

Code: Select all

connect
thread 1
file C:/Users/Amandio/workspace/DeviceReboot/bin/image_n0c0_2.elf
set arch xs2_reva
b write_sswitch_reg_no_ack
commands 1
silent
printf "  write_sswitch_reg_no_ack(0x%x, 0x%x, 0x%x);\n", $r0, $r1, $r2
c
end
b _done
commands 2
silent
end
load 
c
q

However, what I'm seeing now is that even though xgdb appears to now be properly running the script, nothing happens. Here is the output:

Code: Select all

C:\Users\Amandio\workspace\DeviceReboot\bin>xgdb -x script
GNU gdb (XGDB) Community_14.2.1 (build 15182, Jun-24-2016)
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=xcore-elf".
For bug reporting instructions, please see: http://www.xmos.com/support.

0xfff004c8 in ?? ()
[Switching to thread 1 (tile[0] core[0])]#0  0xfff004c8 in ?? ()
Breakpoint 1 at 0x402d4
Breakpoint 2 at 0x4040c
Loading image to XCore 0
Loading section .text, size 0x450 lma 0x40000
Loading section .init, size 0x1c lma 0x40450
Loading section .fini, size 0x30 lma 0x4046c
Loading section .eh_frame, size 0x24 lma 0x4049c
Loading section .cp.rodata, size 0x14 lma 0x404c0
Loading section .cp.const4, size 0x28 lma 0x404d4
Loading section .cp.rodata.cst4, size 0x4 lma 0x404fc
Loading section .dp.data, size 0x20 lma 0x40500
Loading section .dp.data.4, size 0x10 lma 0x40520
Start address 0x40000, load size 1328
Transfer rate: 81 KB/sec, 147 bytes/write.

Nothing happens after this and I have Ctrl+C to exit.

[larry]

You're right, there is something up with resolving file paths.

Thank you, obviously it's not interpreting backslashes. I will check to see if this is a known issue.

When you Ctrl+C and do:

Code: Select all

info threads

what state is the processor in?

Is your program using xSCOPE? If yes, the connect command will need to become:

Code: Select all

connect --xscope

[aneves]

I am unable to do any postmortem analysis with xgdb under Windows. Ctrl+C kills xgdb instead of just the running program. This is a known issue to gdb: gdb: exit program without exiting gdb

Note that I tried the suggested workaround of using Ctrl+Break, but this too kills xgdb as well.

Is your program using xSCOPE? If yes, the connect command will need to become:

Code: Select all

connect --xscope

This program is not using xscope.

I changed the file path in line 3 of the xgdb script to point the xe file to see if I could get any sign of life. I get this output:

Code: Select all

C:\Users\Amandio\workspace\DeviceReboot\bin>xgdb -x script
GNU gdb (XGDB) Community_14.2.1 (build 15182, Jun-24-2016)
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=xcore-elf".
For bug reporting instructions, please see: http://www.xmos.com/support.

0xfff004c8 in ?? ()
[Switching to thread 1 (tile[0] core[0])]#0  0xfff004c8 in ?? ()
Breakpoint 1 at 0x402d4
Breakpoint 2 at 0x4040c
Loading setup image to XCore 0
Loading section .text, size 0x144 lma 0x40000
Loading section .cp.rodata, size 0x18 lma 0x40144
Loading section .dp.data, size 0x10 lma 0x4015c
Start address 0x40000, load size 364
Transfer rate: 71 KB/sec, 121 bytes/write.
Loading setup image to XCore 1
Loading section .text, size 0x40 lma 0x40000
Loading section .cp.rodata, size 0x18 lma 0x40040
Start address 0x40000, load size 88
Transfer rate: 28 KB/sec, 44 bytes/write.
First stage multi-node boot started
First stage multi-node boot completed
Loading application image to XCore 0
Loading section .text, size 0x450 lma 0x40000
Loading section .init, size 0x1c lma 0x40450
Loading section .fini, size 0x30 lma 0x4046c
Loading section .eh_frame, size 0x24 lma 0x4049c
Loading section .cp.rodata, size 0x14 lma 0x404c0
Loading section .cp.const4, size 0x28 lma 0x404d4
Loading section .cp.rodata.cst4, size 0x4 lma 0x404fc
Loading section .dp.data, size 0x20 lma 0x40500
Loading section .dp.data.4, size 0x10 lma 0x40520
Start address 0x40000, load size 1328
Transfer rate: 76 KB/sec, 147 bytes/write.
Loading application image to XCore 1
Loading section .text, size 0x20c lma 0x40000
Loading section .init, size 0x1c lma 0x4020c
Loading section .fini, size 0x30 lma 0x40228
Loading section .eh_frame, size 0x10 lma 0x40258
Loading section .cp.rodata, size 0x10 lma 0x40268
Loading section .cp.const4, size 0x24 lma 0x40278
Loading section .cp.rodata.cst4, size 0x4 lma 0x4029c
Loading section .dp.data, size 0x20 lma 0x402a0
Start address 0x40000, load size 704
Transfer rate: 57 KB/sec, 88 bytes/write.
[Switching to tile[0] core[1]]
  write_sswitch_reg_no_ack(0x1, 0x6, 0x7c02);

So looks like the breakpoint hit, but only once even though it is called twice.

[larry]

Is there a way to check that the program is getting past this first call?

What is the frequency configuration like in your XN file? If resulting PLL settings are different than 7C02, writing 7C02 to register 6 will cause a reset, at which point GDB loses the device (and no more console output).

[aneves]

Is there a way to check that the program is getting past this first call?

I don't know. I was hoping you could help me with that.

To answer your other question, the system frequency set in the xn file is 500MHz.