Menu
▾
▴
avarice-user — AVaRICE Users
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
(3) |
Mar
(3) |
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(11) |
Mar
(29) |
Apr
(27) |
May
(21) |
Jun
(24) |
Jul
(18) |
Aug
(30) |
Sep
(8) |
Oct
(15) |
Nov
(33) |
Dec
(15) |
| 2004 |
Jan
(14) |
Feb
(29) |
Mar
(16) |
Apr
(2) |
May
(8) |
Jun
(3) |
Jul
(1) |
Aug
(29) |
Sep
(16) |
Oct
(8) |
Nov
(53) |
Dec
(47) |
| 2005 |
Jan
(70) |
Feb
(15) |
Mar
(5) |
Apr
(44) |
May
(17) |
Jun
(12) |
Jul
(8) |
Aug
(15) |
Sep
(11) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2006 |
Jan
(6) |
Feb
(20) |
Mar
(5) |
Apr
(35) |
May
|
Jun
(17) |
Jul
(5) |
Aug
(9) |
Sep
(9) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2007 |
Jan
|
Feb
(3) |
Mar
(9) |
Apr
(7) |
May
(9) |
Jun
(7) |
Jul
(15) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
(58) |
Feb
(25) |
Mar
(18) |
Apr
(38) |
May
(24) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
(5) |
Oct
(5) |
Nov
(2) |
Dec
(2) |
| 2009 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(6) |
May
|
Jun
(4) |
Jul
(5) |
Aug
(21) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(4) |
Feb
|
Mar
|
Apr
(3) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(3) |
| 2011 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
(5) |
May
(2) |
Jun
|
Jul
|
Aug
(12) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
(13) |
| 2012 |
Jan
(5) |
Feb
(6) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(4) |
Nov
(33) |
Dec
(2) |
| 2013 |
Jan
(35) |
Feb
(3) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2014 |
Jan
(6) |
Feb
(10) |
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(11) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(1) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(12) |
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
(2) |
Mar
(31) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
| 2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg W. <j...@ur...> - 2018-07-10 10:39:01
|
As Marian Buschsieweke wrote: > the attached patch fixes an incorrect return statement: Apparently old GCC > versions implicitly casted "false" to "NULL", which no longer is the case. So > the "return false;" statement in jtagrw.cc:134 in function > > uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes) > > should be replaced by "return NULL;" See bug report #24 (filed just recently) > Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe > running astyle, uncrustify, or whatever of the code would be a good idea? ;-) Changing whitespace just for the purpose of changing it is generally not a good idea. It potentially obfuscates real code changes later on. That doesn't mean maintaining a consistent style is a bad idea, but I wouldn't want to commit changes just for that. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Marian B. <mar...@ov...> - 2018-07-10 07:51:04
|
Hi, the attached patch fixes an incorrect return statement: Apparently old GCC versions implicitly casted "false" to "NULL", which no longer is the case. So the "return false;" statement in jtagrw.cc:134 in function uchar *jtag1::jtagRead(unsigned long addr, unsigned int numBytes) should be replaced by "return NULL;" Also, there is a lot of inconsistent use of tabs and spaces for indent. Maybe running astyle, uncrustify, or whatever of the code would be a good idea? ;-) Kind regards, Marian ------------------------------------------------------------- M.Sc. Marian Buschsieweke Dept. Communication and Networked Systems (ComSys) Institute for Intelligent Cooperating Systems (IKS) Otto-von-Guericke-University of Magdeburg Universitätsplatz 2, Building 29, Room 314 39106 Magdeburg Germany http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html Tel.: +49 - 391 - 67 - 52673 Fax: +49 - 391 - 67 - 41161 |
|
From: Alberto V. <bet...@gm...> - 2017-04-29 00:52:18
|
Hello,
I'm trying to debug an AVR Atmega328p with the Atmel ICE using debugWire.
I'm able to connect to the debugger, open the file with Avr-gdb, and go
through the code. But after setting up breakpoints and 'continue', the
program doesn't on them. If I interrupt and go through the instructions i'm
able to see the break message. Don't know if is a problem with AVARICE, or
AVR-GDB, or is that I'm doing something wrong. Could you help me with this?
The versions running:
AVARICE 2.13svn20160229
AVR-GCC 6.3.0
AVR-GDB 7.12.1
AVARICE debug output
********************************************************************
AVaRICE version 2.13svn20160229, Apr 28 2017 19:48:31
Found HID PID:VID 0x03eb:0x2141, serno J41800000668
Probing for HID max. packet size
Setting max. packet size to 512 from DAP_Info
JTAG config starting.
HID thread started
command "sign-on" [0x01, 0x10]
0E 00 00 00 01 10 00
Received 0x81 0x11 0x00 0x06 0x0e 0x00
read: 0e 00 00 01 80 00
Got message seqno 0 (command_sequence == 0)
response: 01 80 00
command "get info (serial number)" [0x00, 0x00]
0E 00 01 00 00 00 00 81
Received 0x81 0x11 0x00 0x12 0x0e 0x01
read: 0e 01 00 00 81 00 4a 34 31 38 30 30 30 30 30 36 36 38
Got message seqno 1 (command_sequence == 1)
response: 00 81 00 4A 34 31 38 30 30 30 30 30 36 36 38
Found a device, serial number: J41800000668
command "get parameter" [0x01, 0x02]
0E 00 02 00 01 02 00 00 00 05
Received 0x81 0x11 0x00 0x0c 0x0e 0x02
read: 0e 02 00 01 84 01 00 01 26 81 00 00
Got message seqno 2 (command_sequence == 2)
response: 01 84 01 00 01 26 81 00 00
ICE hardware version: 0
ICE firmware version: 1.38 (rel. 129)
command "set parameter" [0x12, 0x01]
0E 00 03 00 12 01 00 00 00 01 01
Received 0x81 0x11 0x00 0x06 0x0e 0x03
read: 0e 03 00 12 80 00
Got message seqno 3 (command_sequence == 3)
response: 12 80 00
command "set parameter" [0x12, 0x01]
0E 00 04 00 12 01 00 00 01 01 02
Received 0x81 0x11 0x00 0x06 0x0e 0x04
read: 0e 04 00 12 80 00
Got message seqno 4 (command_sequence == 4)
response: 12 80 00
command "set parameter" [0x12, 0x01]
0E 00 05 00 12 01 00 01 00 01 05
Received 0x81 0x11 0x00 0x06 0x0e 0x05
read: 0e 05 00 12 80 00
Got message seqno 5 (command_sequence == 5)
response: 12 80 00
command "AVR sign-on" [0x12, 0x10]
0E 00 06 00 12 10 00 00
Received 0x81 0x11 0x00 0x0b 0x0e 0x06
read: 0e 06 00 12 84 00 0f 95 00 00 00
Got message seqno 6 (command_sequence == 6)
response: 12 84 00 0F 95 00 00 00
AVR sign-on responded with device ID = 0x950F
Reported device ID: 0x950F
Configured for device ID: 0x950F atmega328p
Automatic device detection:
command "set parameter" [0x12, 0x01]
0E 00 07 00 12 01 00 02 00 1F 80 00 00 80 00 00 00 00 00 00 00 3F 00 00 00
01 00 04 04 01 01 00 00 00 00 22 21 1F 20 00 46
Received 0x81 0x11 0x00 0x06 0x0e 0x07
read: 0e 07 00 12 80 00
Got message seqno 7 (command_sequence == 7)
response: 12 80 00
JTAG config complete.
Preparing the target device for On Chip Debugging.
command "set parameter" [0x12, 0x01]
0E 00 08 00 12 01 00 03 00 01 00
Received 0x81 0x11 0x00 0x06 0x0e 0x08
read: 0e 08 00 12 80 00
Got message seqno 8 (command_sequence == 8)
response: 12 80 00
command "start debugging" [0x12, 0x13]
0E 00 09 00 12 13 00 01
Received 0x81 0x11 0x00 0x06 0x0e 0x09
read: 0e 09 00 12 80 00
Got message seqno 9 (command_sequence == 9)
response: 12 80 00
command "reset" [0x12, 0x30]
0E 00 0A 00 12 30 00 01
Received 0x81 0x11 0x00 0x06 0x0e 0x0a
read: 0e 0a 00 12 80 00
Got message seqno 10 (command_sequence == 10)
response: 12 80 00
read: 0e 00 2c 00 12 40 44 00 00 00 01 00 00 30
Event serial 0x002c
ignoring break event
Waiting for connection on port 4242.
Connection opened by host 127.0.0.1, port 50318.
GDB:
<qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+>
->GDB: qXfer:memory-map:read+
GDB: <vMustReplyEmpty>
->GDB:
GDB: <Hg0>
->GDB:
GDB: <qTStatus>
->GDB:
GDB: <?>
->GDB: S05
GDB: <qfThreadInfo>
->GDB:
GDB: <qL1160000000000000000>
->GDB:
GDB: <Hc-1>
->GDB:
GDB: <qC>
->GDB:
GDB: <qAttached>
->GDB:
GDB: <qOffsets>
->GDB:
GDB: <g>
GDB: (Registers)Read 32 bytes from 0x800000
jtagRead
command "read memory" [0x12, 0x21]
0E 00 0B 00 12 21 00 20 00 00 00 00 20 00 00 00
read: 0e 00 2d 00 12 40 00 00 00 00 01 00 00 30
Event serial 0x002d
Got message seqno 65535 (command_sequence == 11)
got asynchronous event: 0x12, 0x40
Received 0x81 0x11 0x00 0x27 0x0e 0x0b
read: 0e 0b 00 12 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 ff 08 60 00 00
Got message seqno 11 (command_sequence == 11)
response: 12 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 FF 08 60 00 00
jtagRead
command "read memory" [0x12, 0x21]
0E 00 0C 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x0c
read: 0e 0c 00 12 84 00 ff 08 00 00
Got message seqno 12 (command_sequence == 12)
response: 12 84 00 FF 08 00 00
command "read PC" [0x12, 0x35]
0E 00 0D 00 12 35 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x0d
read: 0e 0d 00 12 83 00 00 00 00 00
Got message seqno 13 (command_sequence == 13)
response: 12 83 00 00 00 00 00
PC = 0
->GDB:
00000000000000000000000000000000000000000000000000000000ff08600000ff0800000000
GDB: <qL1160000000000000000>
->GDB:
GDB: <qSymbol::>
->GDB:
GDB: <qXfer:memory-map:read::0,18a>
->GDB: l<memory-map>
<memory type="ram" start="0x800000" length="0x20000" />
<memory type="flash" start="0" length="0x8000">
<property name="blocksize">0x80</property>
</memory>
</memory-map>
GDB: <m82,2>
GDB: Read 2 bytes from 0x82
jtagRead
command "read memory" [0x12, 0x21]
0E 00 0E 00 12 21 00 B0 80 00 00 00 80 00 00 00
Received 0x81 0x11 0x00 0x87 0x0e 0x0e
read: 0e 0e 00 12 84 00 3d 9a 45 9a 00 00 45 98 00 00 fb cf f8 94 ff cf ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff 00
Got message seqno 14 (command_sequence == 14)
response: 12 84 00 3D 9A 45 9A 00 00 45 98 00 00 FB CF F8 94 FF CF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF 00
->GDB: 459a
GDB: <m86,2>
GDB: Read 2 bytes from 0x86
jtagRead ->GDB: 4598
GDB: <Z1,82,2>
BP ADD type: 1 addr: 0x82 ->GDB: OK
GDB: <Z1,86,2>
BP ADD type: 1 addr: 0x86 ->GDB: OK
GDB: <vCont?>
->GDB:
GDB: <Hc0>
->GDB:
GDB: <c>
Breakpoint added in ICE. slot: 0 type: 1 addr: 0x82
command "set BP" [0x12, 0x43]
0E 00 0F 00 12 43 00 82 00 00 00
Received 0x81 0x11 0x00 0x06 0x0e 0x0f
read: 0e 0f 00 12 80 00
Got message seqno 15 (command_sequence == 15)
response: 12 80 00
Breakpoint added in ICE. slot: 0 type: 1 addr: 0x86
command "set BP" [0x12, 0x43]
0E 00 10 00 12 43 00 86 00 00 00
Received 0x81 0x11 0x00 0x06 0x0e 0x10
read: 0e 10 00 12 80 00
Got message seqno 16 (command_sequence == 16)
response: 12 80 00
command "go" [0x12, 0x32]
0E 00 11 00 12 32 00
Received 0x81 0x11 0x00 0x07 0x0e 0x11
read: 0e 11 00 12 a0 00 10
Got message seqno 17 (command_sequence == 17)
response: 12 A0 00 10
command "go" [0x12, 0x32]
0E 00 12 00 12 32 00
Received 0x81 0x11 0x00 0x06 0x0e 0x12
read: 0e 12 00 12 80 00
Got message seqno 18 (command_sequence == 18)
response: 12 80 00
Waiting for input.
interrupted by GDB
command "stop" [0x12, 0x31]
0E 00 13 00 12 31 00 01
Received 0x81 0x11 0x00 0x06 0x0e 0x13
read: 0e 13 00 12 80 00
Got message seqno 19 (command_sequence == 19)
response: 12 80 00
read: 0e 00 2e 00 12 40 44 00 00 00 01 00 00 45
Event serial 0x002e
ignoring break event
jtagRead
command "read memory" [0x12, 0x21]
0E 00 14 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x14
read: 0e 14 00 12 84 00 fd 08 00 00
Got message seqno 20 (command_sequence == 20)
response: 12 84 00 FD 08 00 00
->GDB: T0220:00;21:fd08;22:00000000;
GDB: <qL1160000000000000000>
->GDB:
GDB: <z1,82,2>
BP DEL type: 1 addr: 0x82 DISABLED
->GDB: OK
GDB: <z1,86,2>
BP DEL type: 1 addr: 0x86 DISABLED
->GDB: OK
GDB: <Z1,82,2>
BP ADD type: 1 addr: 0x82 ENABLED
->GDB: OK
GDB: <Z1,86,2>
BP ADD type: 1 addr: 0x86 ENABLED
->GDB: OK
GDB: <s>
command "single-step" [0x12, 0x34]
0E 00 15 00 12 34 00 01 01
Received 0x81 0x11 0x00 0x06 0x0e 0x15
read: 0e 15 00 12 80 00
Got message seqno 21 (command_sequence == 21)
response: 12 80 00
read: 0e 00 2f 00 12 40 45 00 00 00 01 00 00 45
Event serial 0x002f
ignoring break event
command "read PC" [0x12, 0x35]
0E 00 16 00 12 35 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x16
read: 0e 16 00 12 83 00 45 00 00 00
Got message seqno 22 (command_sequence == 22)
response: 12 83 00 45 00 00 00
jtagRead
command "read memory" [0x12, 0x21]
0E 00 17 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x17
read: 0e 17 00 12 84 00 fd 08 00 00
Got message seqno 23 (command_sequence == 23)
response: 12 84 00 FD 08 00 00
->GDB: T0520:00;21:fd08;22:8a000000;
GDB: <m80,a>
GDB: Read 10 bytes from 0x80
jtagRead ->GDB: 3d9a459a000045980000
GDB: <m8008fe,2>
GDB: Read 2 bytes from 0x8008FE
jtagRead
command "read memory" [0x12, 0x21]
0E 00 18 00 12 21 00 20 FE 08 00 00 02 00 00 00
Received 0x81 0x11 0x00 0x09 0x0e 0x18
read: 0e 18 00 12 84 00 00 3c 00
Got message seqno 24 (command_sequence == 24)
response: 12 84 00 00 3C 00
->GDB: 003c
GDB: <m68,10>
GDB: Read 16 bytes from 0x68
jtagRead
command "read memory" [0x12, 0x21]
0E 00 19 00 12 21 00 B0 00 00 00 00 80 00 00 00
Received 0x81 0x11 0x00 0x87 0x0e 0x19
read: 0e 19 00 12 84 00 0c 94 34 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c
94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94
3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e
00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 0c 94 3e 00
0c 94 3e 00 0c 94 3e 00 0c 94 3e 00 11 24 1f be cf ef d8 e0 de bf cd bf 0e
94 40 00 0c 94 46 00 0c 94 00 00 00
Got message seqno 25 (command_sequence == 25)
response: 12 84 00 0C 94 34 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E
00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00
0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C
94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94 3E 00 0C 94
3E 00 0C 94 3E 00 0C 94 3E 00 11 24 1F BE CF EF D8 E0 DE BF CD BF 0E 94 40
00 0C 94 46 00 0C 94 00 00 00
->GDB: 11241fbecfefd8e0debfcdbf0e944000
GDB: <qL1160000000000000000>
->GDB:
GDB: <z1,82,2>
BP DEL type: 1 addr: 0x82 DISABLED
->GDB: OK
GDB: <z1,86,2>
BP DEL type: 1 addr: 0x86 DISABLED
->GDB: OK
GDB: <Z1,82,2>
BP ADD type: 1 addr: 0x82 ENABLED
->GDB: OK
GDB: <Z1,86,2>
BP ADD type: 1 addr: 0x86 ENABLED
->GDB: OK
GDB: <s>
command "single-step" [0x12, 0x34]
0E 00 1A 00 12 34 00 01 01
Received 0x81 0x11 0x00 0x06 0x0e 0x1a
read: 0e 1a 00 12 80 00
Got message seqno 26 (command_sequence == 26)
response: 12 80 00
read: 0e 00 30 00 12 40 41 00 00 00 01 00 00 3e
Event serial 0x0030
ignoring break event
command "read PC" [0x12, 0x35]
0E 00 1B 00 12 35 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x1b
read: 0e 1b 00 12 83 00 41 00 00 00
Got message seqno 27 (command_sequence == 27)
response: 12 83 00 41 00 00 00
jtagRead
command "read memory" [0x12, 0x21]
0E 00 1C 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x1c
read: 0e 1c 00 12 84 00 fd 08 00 00
Got message seqno 28 (command_sequence == 28)
response: 12 84 00 FD 08 00 00
->GDB: T0520:00;21:fd08;22:82000000;
GDB: <m80,2>
GDB: Read 2 bytes from 0x80
jtagRead
command "read memory" [0x12, 0x21]
0E 00 1D 00 12 21 00 B0 80 00 00 00 80 00 00 00
Received 0x81 0x11 0x00 0x87 0x0e 0x1d
read: 0e 1d 00 12 84 00 3d 9a 45 9a 00 00 45 98 00 00 fb cf f8 94 ff cf ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff 00
Got message seqno 29 (command_sequence == 29)
response: 12 84 00 3D 9A 45 9A 00 00 45 98 00 00 FB CF F8 94 FF CF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF 00
->GDB: 3d9a
GDB: <qL1160000000000000000>
->GDB:
GDB: <z1,82,2>
BP DEL type: 1 addr: 0x82 DISABLED
->GDB: OK
GDB: <z1,86,2>
BP DEL type: 1 addr: 0x86 DISABLED
->GDB: OK
GDB: <Z1,86,2>
BP ADD type: 1 addr: 0x86 ENABLED
->GDB: OK
GDB: <Hc0>
->GDB:
GDB: <s>
command "single-step" [0x12, 0x34]
0E 00 1E 00 12 34 00 01 01
Received 0x81 0x11 0x00 0x06 0x0e 0x1e
read: 0e 1e 00 12 80 00
Got message seqno 30 (command_sequence == 30)
response: 12 80 00
read: 0e 00 31 00 12 40 42 00 00 00 01 00 00 45
Event serial 0x0031
ignoring break event
command "read PC" [0x12, 0x35]
0E 00 1F 00 12 35 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x1f
read: 0e 1f 00 12 83 00 42 00 00 00
Got message seqno 31 (command_sequence == 31)
response: 12 83 00 42 00 00 00
jtagRead
command "read memory" [0x12, 0x21]
0E 00 20 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x20
read: 0e 20 00 12 84 00 fd 08 00 00
Got message seqno 32 (command_sequence == 32)
response: 12 84 00 FD 08 00 00
->GDB: T0520:00;21:fd08;22:84000000;
GDB: <m80,4>
GDB: Read 4 bytes from 0x80
jtagRead ->GDB: 3d9a459a
GDB: <Z1,82,2>
BP ADD type: 1 addr: 0x82 ENABLED
->GDB: OK
GDB: <Hc0>
->GDB:
GDB: <c>
command "go" [0x12, 0x32]
0E 00 21 00 12 32 00
Received 0x81 0x11 0x00 0x06 0x0e 0x21
read: 0e 21 00 12 80 00
Got message seqno 33 (command_sequence == 33)
response: 12 80 00
Waiting for input.
interrupted by GDB
command "stop" [0x12, 0x31]
0E 00 22 00 12 31 00 01
Received 0x81 0x11 0x00 0x06 0x0e 0x22
read: 0e 22 00 12 80 00
Got message seqno 34 (command_sequence == 34)
response: 12 80 00
read: 0e 00 32 00 12 40 44 00 00 00 01 00 00 45
Event serial 0x0032
ignoring break event
jtagRead
command "read memory" [0x12, 0x21]
0E 00 23 00 12 21 00 20 5D 00 00 00 03 00 00 00
Received 0x81 0x11 0x00 0x0a 0x0e 0x23
read: 0e 23 00 12 84 00 fd 08 00 00
Got message seqno 35 (command_sequence == 35)
response: 12 84 00 FD 08 00 00
->GDB: T0220:00;21:fd08;22:84000000;
GDB: <m80,4>
GDB: Read 4 bytes from 0x80
jtagRead ->GDB: 3d9a459a
GDB: <qL1160000000000000000>
->GDB:
GDB: <z1,82,2>
BP DEL type: 1 addr: 0x82 DISABLED
->GDB: OK
GDB: <z1,86,2>
BP DEL type: 1 addr: 0x86 DISABLED
->GDB: OK
GDB: <vKill;a410>
->GDB:
GDB: <k>
gdb exited.
command "cleanup" [0x12, 0x45]
0E 00 24 00 12 45 00
Received 0x81 0x11 0x00 0x06 0x0e 0x24
read: 0e 24 00 12 80 00
Got message seqno 36 (command_sequence == 36)
response: 12 80 00
command "go" [0x12, 0x32]
0E 00 25 00 12 32 00
Received 0x81 0x11 0x00 0x07 0x0e 0x25
read: 0e 25 00 12 a0 00 10
Got message seqno 37 (command_sequence == 37)
response: 12 A0 00 10
command "go" [0x12, 0x32]
0E 00 26 00 12 32 00
Received 0x81 0x11 0x00 0x06 0x0e 0x26
read: 0e 26 00 12 80 00
Got message seqno 38 (command_sequence == 38)
response: 12 80 00
command "stop debugging" [0x12, 0x14]
0E 00 27 00 12 14 00
Received 0x81 0x11 0x00 0x06 0x0e 0x27
read: 0e 27 00 12 80 00
Got message seqno 39 (command_sequence == 39)
response: 12 80 00
command "AVR sign-off" [0x12, 0x11]
0E 00 28 00 12 11 00
Received 0x81 0x11 0x00 0x06 0x0e 0x28
read: 0e 28 00 12 80 00
Got message seqno 40 (command_sequence == 40)
response: 12 80 00
command "sign-off" [0x01, 0x11]
0E 00 29 00 01 11 00
Received 0x81 0x11 0x00 0x06 0x0e 0x29
read: 0e 29 00 01 80 00
Got message seqno 41 (command_sequence == 41)
response: 01 80 00
*******************************************************************
AVR-GDB output
*******************************************************************
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from LCD.elf...done.
(gdb) target remote :4242
Remote debugging using :4242
0x00000000 in __vectors ()
(gdb) list
1 #ifndef F_CPU
2 #define F_CPU 8000000UL
3 #endif
4
5 #include <avr/io.h>
6 #include <util/delay.h>
7
8 #define _NOP() asm("nop")
9
10 __attribute__((noreturn)) int main(void) {
(gdb)
11 DDRC |= (1<<PC5);
12
13 for(;;) {
14 PORTC |= (1<<PC5);
15 _NOP();
16 PORTC &= ~(1<<PC5);
17 _NOP();
18 }
19 }
(gdb) break 14
Breakpoint 1 at 0x82: file main.c, line 14.
(gdb) hb 16
Hardware assisted breakpoint 2 at 0x86: file main.c, line 16.
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000082 in main at main.c:14
2 hw breakpoint keep y 0x00000086 in main at main.c:16
(gdb) cont
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
^C
Program received signal SIGINT, Interrupt.
0x00000000 in __vectors ()
(gdb) info line
Line number 19 is out of range for "main.c".
(gdb) ni
0x0000008a in main () at main.c:17
17 _NOP();
(gdb) ni
Breakpoint 1, main () at main.c:14
14 PORTC |= (1<<PC5);
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
main () at main.c:15
15 _NOP();
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be killed.
Quit anyway? (y or n) y
Thanks a lot,
Alberto
|
|
From: Wolfgang R. <wr...@ti...> - 2017-03-19 09:11:47
|
Hi Knut,
have you relized my mail 10 minute after yours?
- it works now
- "load timer.elf" command was the culprit.
I still do not understand why and if it is desired / acceptable
behaviur. Still newbie in gdb.
I know from simulavr that "load timer.elf" transfers the binary to the
target which presumably is not required / desired / possible in avarice
setups.
"file timer.elf" suffices to get the source displayed in gdb.
So maybe we can stop here?
If not, I'll provide the infos you requested:
Am Sat, 18 Mar 2017 21:26:25 +0100
schrieb Knut Schwichtenberg <ks...@we...>:
> Hi Wolfgang,
>
> which version of avarice are you using?
This is from debian:
...$ avarice --version
AVaRICE version 2.11, Dec 22 2013 18:22:47
...$ apt-cache policy avarice
avarice:
Installiert: 2.11-1.1
Installationskandidat: 2.11-1.1
Versionstabelle:
*** 2.11-1.1 0
500 http://ftp5.gwdg.de/pub/linux/debian/debian/ jessie/main
amd64 Packages 100 /var/lib/dpkg/status
this I built from sourceforge sources, declared as "last"
(I didn't manage to display the svn source tree, but I did not try
hard.)
https://sourceforge.net/projects/avarice/files/avarice/avarice-2.13/avarice-2.13.tar.bz2/download
...$ avarice-2_13 --version
AVaRICE version 2.13, Mar 17 2017 16:54:25
> Check if version 2.13 is more appropriate.
Both version show the same behaviour
> Please decribe the Linux versions you are using of avr-gcc, avr-gdb,
> avrdude and avr-libc.
$ cat /etc/debian_version
8.4
...$ avr-gcc --version
avr-gcc (GCC) 4.8.1
...$ avr-gdb --version
GNU gdb (GDB) 7.7.1
$ dpkg --list | grep avr
avrdude 6.1-2
avr-libc 1:1.8.0+Atmel3.4.4-1
gcc-avr 1:4.8.1+Atmel3.4.4-2
gdb-avr 7.7-2
....
-------------------
HÄ???
avr-gdb displays a different version than dpkg?
$ which avr-gdb
/usr/bin/avr-gdb
$ dpkg --listfiles gdb-avr
....
/usr/bin/avr-gdb
... weird...
anyway, I consider to build avr-gdb myself.
With python.
Best place to start?
> Your AVR Studio is quite old if you upgrade to a studio 6. Studio 7
> provides a new debug protocol, which is implemented in avarice but not
> very functional.
So it was no mistake being afraid of regression bugs?
I tried the most recent Studio 7, called for a windows upgrade, windows
upgrade stalled.
Is it really necessary / helpful / improvement from 4.19 to 6?
I hate to risk screwing a computer just for the opaqe extraction of
some binary firmware I cannot even get a version number of.
(well, I hate Win anyway, you may just realize...)
Habedieehre :-)
Wolfgang
>
> Cheers,
> Knut
>
> Am 18.03.2017 um 20:30 schrieb Wolfgang Rosner:
> > Hi,
> >
> > further test results:
> > - Problem persists after dragon firmware update with AVR Studio 4.19
> > - JTAG debug works with AVR Studio 4.19, dragon and AT90CAN32
> > - I think the LED flash speed of the dragon is much faster on AVR
> > Studio
> >
> > So I can exclude dragon hardware, dragon firmware and my minimum
> > breadboard system as cause.
> >
> > Looks like the problems are in the linux tool chain for avr.
> >
> > Wolfgang
> >
> >
> > Am Fri, 17 Mar 2017 21:04:13 +0100
> > schrieb Wolfgang Rosner <wr...@ti...>:
> >
> >> Hello,
> >>
> >> I'd like to debug on an AT90CAN32 target on a bread board assembly.
> >> My cheap chinese jtag did not accept this.
> >>
> >> The avarice manpage says
> >> at90can32 (o)
> >> o - Only supported by the JTAG ICE mkII and AVR Dragon device.
> >>
> >> So I purchased one of the famous dragon boards.
> >>
> >>
> >> But still debug does not work.
> >> I can connect, read, flash, fuse with avrdude and at least connect
> >> and flash with avarice.
> >>
> >> But when it goes to debug, it takes alread quite long (~ 20 sec)
> >> for avr-gdb to come up. Dragon's LED keep flashing during most of
> >> start up time.
> >>
> >> When I try to run my code, it stucks in an endless loop:
> >>
> >> ======8<==================================
> >> (gdb) ni
> >> 0x00000000 in __vectors ()
> >> 3: x/i $pc
> >> => 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors>
> >> 2: /t $SREG = 0
> >> 1: /x *$PORTD = 0x4
> >> (gdb) ni
> >> 0x00000000 in __vectors ()
> >> 3: x/i $pc
> >> ....
> >> ======8<==================================
> >>
> >> Anything else than ni single stepping lets hang both avr-gdb and
> >> avarice.
> >> avr-gdb does not accept ctrl-C any more (at least not within
> >> reasonable time).
> >> Dragon LED's keep blinking at ~~ 2 Hz.
> >> Looks like the endless loop is processed tremendously slow and
> >> stuff is accumulated in some large buffer.
> >>
> >> I can stop avarice with ctrl-C and avr-gdb dies with it.
> >> I have to reset OCDEN fuse manually, if I want to run code on the
> >> device after that.
> >> But I assume that's a symptom related to the forceful break, not
> >> related to the root cause.
> >>
> >>
> >>
> >> When I compare the code from my elf file, I see different code at
> >> 0x000 than a rjmp .-2
> >>
> >>
> >> ======8<==================================
> >>
> >> :~/test/AVR/hello/timer$ avr-objdump -d timer.elf
> >>
> >> timer.elf: file format elf32-avr
> >>
> >>
> >> Disassembly of section .text:
> >>
> >> 00000000 <__vectors>:
> >> 0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end>
> >> 4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> >> 8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> >> c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> >> .....
> >> ======8<==================================
> >>
> >>
> >>
> >> So from a beginners educated guess, the debugging machine seems to
> >> write this endless loop code at the device start address but does
> >> not complete other steps to setup successful debugging???
> >>
> >> The behaviour is the same with avarice 2.11 shipped with debian
> >> jessie and with avarice 2.13 built from sourceforge sources.
> >>
> >>
> >>
> >> For a refernce point, I tried the dragon setup on an Atmega32
> >> target attached to a simple pollin board.
> >> It still displays the slow setup and the slow single steps. But
> >> after the first ni command, I get assembler and source code
> >> displayed in my gdb as configured and the code is executed in
> >> normal sequence.
> >>
> >> I also have the sticky OCDEN fuse after (regular) shutdown.
> >>
> >>
> >> Compared to my first experience, a cheap 7€ chinese dongle on the
> >> same target debugs at least 10 times faster than the genuine part.
> >>
> >> Google led me to
> >> http://www.avrfreaks.net/comment/241039#comment-241039
> >> "I think there's no debugging option except for the JTAGICE mkII
> >> for those units..."
> >>
> >> But this statement conflicts the avarice man page compatibility
> >> list.
> >>
> >>
> >> Have I been trapped by some AVR marketing "feature"?
> >> "Thou shalt not use cheap stuff where AVR does not make money
> >> from"? Is it a silly beginners error?
> >> Can it be an electric / EMC issue on my bread board assembly?
> >> Or have I encountered a real bug?
> >>
> >>
> >> Any help or hints are appreciated :-)
> >>
> >>
> >
> >
>
--
Wolfgang Rosner
|
|
From: Wolfgang R. <wr...@ti...> - 2017-03-18 20:18:18
|
Hi,
coming closer - basically works now
short story:
thou shalt not load your elf file with dragon
long story:
==============================
avr-gdb -x gdb.cmd
$ cat gdb.cmd
file timer.elf
target remote localhost:1212
# load timer.elf
layout split
# layout asm
# tui reg general
define ppio
x/64bx 0x800020
end
set $PIND=(char *)0x800029
set $PORTD=(char *)0x80002b
displ /x *$PORTD
displ /t $SREG
display /i $pc
break main
break __vector_15
==============================
the culprit was the third line
load timer.elf
which I uncommented now.
I inherited this gdb-command file from trials with simulavr, and it did
not cause any trouble with my debug sessions on atmega32 - neither over
dragon nor over chinese clone.
what still does not work is "info io_registers"
gdb appears to enter an endless loop, no signs of activity on dragon's
leds. I know I can inspect any IO register manually, but for a first
view "what's going on", some overall symbolic listing still would be
nice.
Am Sat, 18 Mar 2017 20:30:13 +0100
schrieb Wolfgang Rosner <wr...@ti...>:
> Hi,
>
> further test results:
> - Problem persists after dragon firmware update with AVR Studio 4.19
> - JTAG debug works with AVR Studio 4.19, dragon and AT90CAN32
> - I think the LED flash speed of the dragon is much faster on AVR
> Studio
>
> So I can exclude dragon hardware, dragon firmware and my minimum
> breadboard system as cause.
>
> Looks like the problems are in the linux tool chain for avr.
>
> Wolfgang
>
>
> Am Fri, 17 Mar 2017 21:04:13 +0100
> schrieb Wolfgang Rosner <wr...@ti...>:
>
> > Hello,
> >
> > I'd like to debug on an AT90CAN32 target on a bread board assembly.
> > My cheap chinese jtag did not accept this.
> >
> > The avarice manpage says
> > at90can32 (o)
> > o - Only supported by the JTAG ICE mkII and AVR Dragon device.
> >
> > So I purchased one of the famous dragon boards.
> >
> >
> > But still debug does not work.
> > I can connect, read, flash, fuse with avrdude and at least connect
> > and flash with avarice.
> >
> > But when it goes to debug, it takes alread quite long (~ 20 sec) for
> > avr-gdb to come up. Dragon's LED keep flashing during most of start
> > up time.
> >
> > When I try to run my code, it stucks in an endless loop:
> >
> > ======8<==================================
> > (gdb) ni
> > 0x00000000 in __vectors ()
> > 3: x/i $pc
> > => 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors>
> > 2: /t $SREG = 0
> > 1: /x *$PORTD = 0x4
> > (gdb) ni
> > 0x00000000 in __vectors ()
> > 3: x/i $pc
> > ....
> > ======8<==================================
> >
> > Anything else than ni single stepping lets hang both avr-gdb and
> > avarice.
> > avr-gdb does not accept ctrl-C any more (at least not within
> > reasonable time).
> > Dragon LED's keep blinking at ~~ 2 Hz.
> > Looks like the endless loop is processed tremendously slow and stuff
> > is accumulated in some large buffer.
> >
> > I can stop avarice with ctrl-C and avr-gdb dies with it.
> > I have to reset OCDEN fuse manually, if I want to run code on the
> > device after that.
> > But I assume that's a symptom related to the forceful break, not
> > related to the root cause.
> >
> >
> >
> > When I compare the code from my elf file, I see different code at
> > 0x000 than a rjmp .-2
> >
> >
> > ======8<==================================
> >
> > :~/test/AVR/hello/timer$ avr-objdump -d timer.elf
> >
> > timer.elf: file format elf32-avr
> >
> >
> > Disassembly of section .text:
> >
> > 00000000 <__vectors>:
> > 0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end>
> > 4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > 8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
> > .....
> > ======8<==================================
> >
> >
> >
> > So from a beginners educated guess, the debugging machine seems to
> > write this endless loop code at the device start address but does
> > not complete other steps to setup successful debugging???
> >
> > The behaviour is the same with avarice 2.11 shipped with debian
> > jessie and with avarice 2.13 built from sourceforge sources.
> >
> >
> >
> > For a refernce point, I tried the dragon setup on an Atmega32 target
> > attached to a simple pollin board.
> > It still displays the slow setup and the slow single steps. But
> > after the first ni command, I get assembler and source code
> > displayed in my gdb as configured and the code is executed in
> > normal sequence.
> >
> > I also have the sticky OCDEN fuse after (regular) shutdown.
> >
> >
> > Compared to my first experience, a cheap 7€ chinese dongle on the
> > same target debugs at least 10 times faster than the genuine part.
> >
> > Google led me to
> > http://www.avrfreaks.net/comment/241039#comment-241039
> > "I think there's no debugging option except for the JTAGICE mkII
> > for those units..."
> >
> > But this statement conflicts the avarice man page compatibility
> > list.
> >
> >
> > Have I been trapped by some AVR marketing "feature"?
> > "Thou shalt not use cheap stuff where AVR does not make money from"?
> > Is it a silly beginners error?
> > Can it be an electric / EMC issue on my bread board assembly?
> > Or have I encountered a real bug?
> >
> >
> > Any help or hints are appreciated :-)
|
|
From: Wolfgang R. <wr...@ti...> - 2017-03-18 19:30:21
|
Hi, further test results: - Problem persists after dragon firmware update with AVR Studio 4.19 - JTAG debug works with AVR Studio 4.19, dragon and AT90CAN32 - I think the LED flash speed of the dragon is much faster on AVR Studio So I can exclude dragon hardware, dragon firmware and my minimum breadboard system as cause. Looks like the problems are in the linux tool chain for avr. Wolfgang Am Fri, 17 Mar 2017 21:04:13 +0100 schrieb Wolfgang Rosner <wr...@ti...>: > Hello, > > I'd like to debug on an AT90CAN32 target on a bread board assembly. > My cheap chinese jtag did not accept this. > > The avarice manpage says > at90can32 (o) > o - Only supported by the JTAG ICE mkII and AVR Dragon device. > > So I purchased one of the famous dragon boards. > > > But still debug does not work. > I can connect, read, flash, fuse with avrdude and at least connect and > flash with avarice. > > But when it goes to debug, it takes alread quite long (~ 20 sec) for > avr-gdb to come up. Dragon's LED keep flashing during most of start > up time. > > When I try to run my code, it stucks in an endless loop: > > ======8<================================== > (gdb) ni > 0x00000000 in __vectors () > 3: x/i $pc > => 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors> > 2: /t $SREG = 0 > 1: /x *$PORTD = 0x4 > (gdb) ni > 0x00000000 in __vectors () > 3: x/i $pc > .... > ======8<================================== > > Anything else than ni single stepping lets hang both avr-gdb and > avarice. > avr-gdb does not accept ctrl-C any more (at least not within > reasonable time). > Dragon LED's keep blinking at ~~ 2 Hz. > Looks like the endless loop is processed tremendously slow and stuff > is accumulated in some large buffer. > > I can stop avarice with ctrl-C and avr-gdb dies with it. > I have to reset OCDEN fuse manually, if I want to run code on the > device after that. > But I assume that's a symptom related to the forceful break, not > related to the root cause. > > > > When I compare the code from my elf file, I see different code at > 0x000 than a rjmp .-2 > > > ======8<================================== > > :~/test/AVR/hello/timer$ avr-objdump -d timer.elf > > timer.elf: file format elf32-avr > > > Disassembly of section .text: > > 00000000 <__vectors>: > 0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end> > 4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> > 8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> > c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> > ..... > ======8<================================== > > > > So from a beginners educated guess, the debugging machine seems to > write this endless loop code at the device start address but does not > complete other steps to setup successful debugging??? > > The behaviour is the same with avarice 2.11 shipped with debian jessie > and with avarice 2.13 built from sourceforge sources. > > > > For a refernce point, I tried the dragon setup on an Atmega32 target > attached to a simple pollin board. > It still displays the slow setup and the slow single steps. But after > the first ni command, I get assembler and source code displayed in my > gdb as configured and the code is executed in normal sequence. > > I also have the sticky OCDEN fuse after (regular) shutdown. > > > Compared to my first experience, a cheap 7€ chinese dongle on the same > target debugs at least 10 times faster than the genuine part. > > Google led me to > http://www.avrfreaks.net/comment/241039#comment-241039 > "I think there's no debugging option except for the JTAGICE mkII for > those units..." > > But this statement conflicts the avarice man page compatibility list. > > > Have I been trapped by some AVR marketing "feature"? > "Thou shalt not use cheap stuff where AVR does not make money from"? > Is it a silly beginners error? > Can it be an electric / EMC issue on my bread board assembly? > Or have I encountered a real bug? > > > Any help or hints are appreciated :-) > > -- Wolfgang Rosner |
|
From: Wolfgang R. <wr...@ti...> - 2017-03-17 20:32:19
|
Hello,
I'd like to debug on an AT90CAN32 target on a bread board assembly.
My cheap chinese jtag did not accept this.
The avarice manpage says
at90can32 (o)
o - Only supported by the JTAG ICE mkII and AVR Dragon device.
So I purchased one of the famous dragon boards.
But still debug does not work.
I can connect, read, flash, fuse with avrdude and at least connect and
flash with avarice.
But when it goes to debug, it takes alread quite long (~ 20 sec) for
avr-gdb to come up. Dragon's LED keep flashing during most of start
up time.
When I try to run my code, it stucks in an endless loop:
======8<==================================
(gdb) ni
0x00000000 in __vectors ()
3: x/i $pc
=> 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors>
2: /t $SREG = 0
1: /x *$PORTD = 0x4
(gdb) ni
0x00000000 in __vectors ()
3: x/i $pc
....
======8<==================================
Anything else than ni single stepping lets hang both avr-gdb and
avarice.
avr-gdb does not accept ctrl-C any more (at least not within reasonable
time).
Dragon LED's keep blinking at ~~ 2 Hz.
Looks like the endless loop is processed tremendously slow and stuff is
accumulated in some large buffer.
I can stop avarice with ctrl-C and avr-gdb dies with it.
I have to reset OCDEN fuse manually, if I want to run code on the device
after that.
But I assume that's a symptom related to the forceful break, not related
to the root cause.
When I compare the code from my elf file, I see different code at 0x000
than a rjmp .-2
======8<==================================
:~/test/AVR/hello/timer$ avr-objdump -d timer.elf
timer.elf: file format elf32-avr
Disassembly of section .text:
00000000 <__vectors>:
0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end>
4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt>
.....
======8<==================================
So from a beginners educated guess, the debugging machine seems to
write this endless loop code at the device start address but does not
complete other steps to setup successful debugging???
The behaviour is the same with avarice 2.11 shipped with debian jessie
and with avarice 2.13 built from sourceforge sources.
For a refernce point, I tried the dragon setup on an Atmega32 target
attached to a simple pollin board.
It still displays the slow setup and the slow single steps. But after
the first ni command, I get assembler and source code displayed in my
gdb as configured and the code is executed in normal sequence.
I also have the sticky OCDEN fuse after (regular) shutdown.
Compared to my first experience, a cheap 7€ chinese dongle on the same
target debugs at least 10 times faster than the genuine part.
Google led me to
http://www.avrfreaks.net/comment/241039#comment-241039
"I think there's no debugging option except for the JTAGICE mkII for
those units..."
But this statement conflicts the avarice man page compatibility list.
Have I been trapped by some AVR marketing "feature"?
"Thou shalt not use cheap stuff where AVR does not make money from"?
Is it a silly beginners error?
Can it be an electric / EMC issue on my bread board assembly?
Or have I encountered a real bug?
Any help or hints are appreciated :-)
--
Wolfgang Rosner
|
|
From: Stephan M. <mey...@we...> - 2016-09-22 20:39:16
|
Jörg Wunsch wrote: > Response code 0x50 is listed as: > AVR8_FAILURE_NO_OCD_CONTROL = 0x50, //! Device is not under control > > in the Atmel documentation. > Whatever that might mean ... It means that reset seems to be held low by a hardware design problem of my circuit :) I need some investigation how this could happen and will response here about the reason. Thanks for the hint Stephan |
|
From: Joerg W. <j...@ur...> - 2016-09-22 20:00:23
|
As Stephan Meyer wrote: > command "reset" [0x12, 0x30] > 0E 00 0D 00 12 30 00 01 > Received 0x81 0x11 0x00 0x07 0x0e 0x0d > read: 0e 0d 00 12 a0 00 50 > > Got message seqno 13 (command_sequence == 13) > response: 12 A0 00 50 > retrying reset ... > > command "reset" [0x12, 0x30] > 0E 00 0E 00 12 30 00 01 > Received 0x81 0x11 0x00 0x07 0x0e 0x0e > read: 0e 0e 00 12 a0 00 50 > > Got message seqno 14 (command_sequence == 14) > response: 12 A0 00 50 It fails to reset the target, that's why it terminates subsequently. Response code 0x50 is listed as: AVR8_FAILURE_NO_OCD_CONTROL = 0x50, //! Device is not under control in the Atmel documentation. Whatever that might mean ... -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Stephan M. <mey...@we...> - 2016-09-22 19:49:10
|
Hello, first of all I would say thanks to Joerg for all the work he is doing in this project. I built the latest avarice (2.13svn20160229) with libhidapi support on Linux. I tried to get a JTAGICE3 (edbg) working on an ATMEGA644 but it is not waiting for avr-gdb to connect. Instead it is terminating without complaining. Btw. AVRDUDE is properly working with this debugger-HW. avarice --edbg -d :4242 prints out following: AVaRICE version 2.13svn20160229, Sep 18 2016 18:08:24 Defaulting JTAG bitrate to 250 kHz. Found HID PID:VID 0x03eb:0x2140, serno J30200020302 Probing for HID max. packet size Setting max. packet size to 512 from DAP_Info HID thread started JTAG config starting. command "sign-on" [0x01, 0x10] 0E 00 00 00 01 10 00 Received 0x81 0x11 0x00 0x06 0x0e 0x00 read: 0e 00 00 01 80 00 Got message seqno 0 (command_sequence == 0) response: 01 80 00 command "get info (serial number)" [0x00, 0x00] 0E 00 01 00 00 00 00 81 Received 0x81 0x11 0x00 0x12 0x0e 0x01 read: 0e 01 00 00 81 00 4a 33 30 32 30 30 30 32 30 33 30 32 Got message seqno 1 (command_sequence == 1) response: 00 81 00 4A 33 30 32 30 30 30 32 30 33 30 32 Found a device, serial number: J30200020302 command "get parameter" [0x01, 0x02] 0E 00 02 00 01 02 00 00 00 05 Received 0x81 0x11 0x00 0x0c 0x0e 0x02 read: 0e 02 00 01 84 01 02 03 31 6f 00 00 Got message seqno 2 (command_sequence == 2) response: 01 84 01 02 03 31 6F 00 00 ICE hardware version: 2 ICE firmware version: 3.49 (rel. 111) command "set parameter" [0x12, 0x01] 0E 00 03 00 12 01 00 00 00 01 02 Received 0x81 0x11 0x00 0x06 0x0e 0x03 read: 0e 03 00 12 80 00 Got message seqno 3 (command_sequence == 3) response: 12 80 00 command "set parameter" [0x12, 0x01] 0E 00 04 00 12 01 00 00 01 01 02 Received 0x81 0x11 0x00 0x06 0x0e 0x04 read: 0e 04 00 12 80 00 Got message seqno 4 (command_sequence == 4) response: 12 80 00 command "set parameter" [0x12, 0x01] 0E 00 05 00 12 01 00 01 00 01 04 Received 0x81 0x11 0x00 0x06 0x0e 0x05 read: 0e 05 00 12 80 00 Got message seqno 5 (command_sequence == 5) response: 12 80 00 command "AVR sign-on" [0x12, 0x10] 0E 00 06 00 12 10 00 00 Received 0x81 0x11 0x00 0x0b 0x0e 0x06 read: 0e 06 00 12 84 00 3f 90 60 29 00 Got message seqno 6 (command_sequence == 6) response: 12 84 00 3F 90 60 29 00 AVR sign-on responded with device ID = 0x2960903F : Ver = 0x2 : Device = 0x9609 : Manuf = 0x1f Reported device ID: 0x9609 Configured for device ID: 0x9609 atmega644 Automatic device detection: command "set parameter" [0x12, 0x01] 0E 00 07 00 12 01 00 02 00 1F 00 01 00 00 01 00 00 00 00 00 00 7E 00 00 00 01 00 08 08 03 01 00 00 00 31 22 21 1F 20 57 46 Received 0x81 0x11 0x00 0x06 0x0e 0x07 read: 0e 07 00 12 80 00 Got message seqno 7 (command_sequence == 7) response: 12 80 00 JTAG config complete. Preparing the target device for On Chip Debugging. command "set parameter" [0x12, 0x01] 0E 00 08 00 12 01 00 01 21 02 FA 00 Received 0x81 0x11 0x00 0x06 0x0e 0x08 read: 0e 08 00 12 80 00 Got message seqno 8 (command_sequence == 8) response: 12 80 00 jtagRead command "enter progmode" [0x12, 0x15] 0E 00 09 00 12 15 00 Received 0x81 0x11 0x00 0x06 0x0e 0x09 read: 0e 09 00 12 80 00 Got message seqno 9 (command_sequence == 9) response: 12 80 00 command "read memory" [0x12, 0x21] 0E 00 0A 00 12 21 00 B2 00 00 00 00 03 00 00 00 Received 0x81 0x11 0x00 0x0a 0x0e 0x0a read: 0e 0a 00 12 84 00 60 11 ff 00 Got message seqno 10 (command_sequence == 10) response: 12 84 00 60 11 FF 00 command "leave progmode" [0x12, 0x16] 0E 00 0B 00 12 16 00 Received 0x81 0x11 0x00 0x06 0x0e 0x0b read: 0e 0b 00 12 80 00 Got message seqno 11 (command_sequence == 11) response: 12 80 00 command "set parameter" [0x12, 0x01] 0E 00 0C 00 12 01 00 03 00 01 00 Received 0x81 0x11 0x00 0x06 0x0e 0x0c read: 0e 0c 00 12 80 00 Got message seqno 12 (command_sequence == 12) response: 12 80 00 command "reset" [0x12, 0x30] 0E 00 0D 00 12 30 00 01 Received 0x81 0x11 0x00 0x07 0x0e 0x0d read: 0e 0d 00 12 a0 00 50 Got message seqno 13 (command_sequence == 13) response: 12 A0 00 50 retrying reset ... command "reset" [0x12, 0x30] 0E 00 0E 00 12 30 00 01 Received 0x81 0x11 0x00 0x07 0x0e 0x0e read: 0e 0e 00 12 a0 00 50 Got message seqno 14 (command_sequence == 14) response: 12 A0 00 50 command "stop debugging" [0x12, 0x14] 0E 00 0F 00 12 14 00 Received 0x81 0x11 0x00 0x06 0x0e 0x0f read: 0e 0f 00 12 80 00 Got message seqno 15 (command_sequence == 15) response: 12 80 00 command "AVR sign-off" [0x12, 0x11] 0E 00 10 00 12 11 00 Received 0x81 0x11 0x00 0x06 0x0e 0x10 read: 0e 10 00 12 80 00 Got message seqno 16 (command_sequence == 16) response: 12 80 00 command "sign-off" [0x01, 0x11] 0E 00 11 00 01 11 00 Received 0x81 0x11 0x00 0x06 0x0e 0x11 read: 0e 11 00 01 80 00 Got message seqno 17 (command_sequence == 17) response: 01 80 00 Then it comes back to the shell without waiting. Where is the screw to turn for getting things to work ? Thanks Stephan |
|
From: Joerg W. <j...@ur...> - 2016-09-06 22:17:50
|
As Olaf Dreyer wrote: > But the resulting binary tells me, that it was build without usb support. > Do I have to make some settings during the configure step? You need to have a libusb around, including the required headers to compile against it. On most Linux distributions, this means you'd have to have the respective "-dev" or "-devel" package installed. AVRDUDE's configure script auto-detects the environment, and prints a summary like this: Configuration summary: ---------------------- DO HAVE libelf DO HAVE libusb DO HAVE libusb_1_0 DO HAVE libftdi1 DON'T HAVE libftdi DON'T HAVE libhid DO HAVE libhidapi DO HAVE pthread DISABLED doc ENABLED parport DISABLED linuxgpio Make sure libusb has a "DO HAVE" there. Note that libhid there is Windows-only, and only relates to USBasp. In order to get support for the recent Atmel tools that are als HIDs, libhidapi support is needed. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Olaf D. <ol...@dr...> - 2016-09-06 21:10:09
|
Hello, I'm trying to build avarice on gentoo linux to work with a JTAG ICE mkII via usb. But the resulting binary tells me, that it was build without usb support. Do I have to make some settings during the configure step? My configure command is like that: configure --enable-target-programming --prefix=$PREFIX It would be great, if someone could help me. Regards Olaf |
|
From: Sven S. <sve...@ar...> - 2016-09-03 09:27:39
|
Hi all, I just compiled and installed the latest avarice version from SVN. First I didn't have the hidapi library installed when I compiled the tool. When I then tried to open my JTAGICE3 using the --edbg option avarice just terminated returning 1 without printing an error message. Even enabling debug output (--debug) didn't give an appropriate message. When I looked online I found a forum post by Jörg (http://www.mikrocont roller.net/topic/391609#4495736) where he said that hidapi is required which I then installed. I recompiled and reinstalled avarice and now it works great. It would be great if you could include a message when the user tries to use --edbg without hidapi. Thanks for your great work, Sven |
|
From: Brian <bh...@ch...> - 2016-05-18 13:57:21
|
Ho Joerg,
Thanks for the great and informative (and speedy!) response! I'll toss
in a few more tidbits of what's going on in case it sheds more light:
The target device is part of a project that features some status lights
that start blinking right after power up. When programming with Atmel
Studio in Windows, all the lights go out and stay out during programming
(which makes sense; the core is busy receiving the image). However,
when programming with avrdude on Debian, the lights blink strangely, as
though the device were being reset repeatedly. It's as though the AVR
Dragon is either not holding the device in reset correctly, or is not
sending it the correct commands somehow. avrdude also likes to hang or
spit out errors a lot, and even if it makes it to 100% on a write, the
automatic verify fails, and a second verify confirms that the prevous
image is still on the chip. So for some reason, the Dragon is just
behaving differently under all circumstances on Linux. :-(
Now on to some things you said:
I'd more suspect the actual debugWIRE connection at first though.
You can try experiment with pullup resistors on /RESET. I've seen
target working more reliably with 4.7 kΩ or 10 kΩ pullups, but
I've also seen target working best without any additional component
between the ICE (i.e. your Dragon) and the /RESET line.
Also make sure to use at most the standard STK500 cable length between
the Dragon and the target (about 15 cm), as the Dragon's line drivers
are known to be quite weak.
I'd agree completely except the exact same physical setup works fine
with Atmel Studio. So yeah, the connection is a problem, but Atmel
Studio can make the Dragon work with it. There actually is a 10k pullup
on that line on my project.
Then the only way to find out is (unfortunately) to trace Atmel
Studio's actions when initializing the AVR Dragon, and compare it
to what AVaRICE does.
Indeed. Can you point me to some resources so I can learn how to do
that? Can it be done without additional equipment (e.g. a USB sniffer)?
Btw., when debugging an 8 KiB device (ATmega8U2), better pick another
8 KiB device for -P, like the ATmega88.
Very useful, thank you. I'll use that.
Hm, here's a thought out of left field: Is it possible that the Linux
USB driver is somehow not letting the Dragon draw enough power from the
USB port? Not so much that it resets itself, but perhaps enough that it
can't drive the /RESET line strongly enough? I think I remember reading
somewhere that there was some low-level USB thing about moderating how
much power the connected device is allowed to draw. When I get back to
my workbench, I'll try powering the Dragon externally and see if that
changes anything.
Thanks!
-Brian
On 05/18/2016 01:45 AM, Joerg Wunsch wrote:
> As Brian wrote:
>
>> got asynchronous event: 0xf7
>> recv: timeout
> This is an
>
> #define EVT_ERROR_PHY_RECEIVE_TIMEOUT 0xF7
>
> meaning the debugWIRE transport timed out (between the Dragon
> and the target).
>
>> So...is this something to do with telling AVaRICE it's an atmega48 when
>> it's really an atmega8u2?
> Very unlikely.
>
> <snip>
|
|
From: Joerg W. <j...@ur...> - 2016-05-18 05:45:34
|
As Brian wrote: > got asynchronous event: 0xf7 > recv: timeout This is an #define EVT_ERROR_PHY_RECEIVE_TIMEOUT 0xF7 meaning the debugWIRE transport timed out (between the Dragon and the target). > So...is this something to do with telling AVaRICE it's an atmega48 when > it's really an atmega8u2? Very unlikely. Btw., when debugging an 8 KiB device (ATmega8U2), better pick another 8 KiB device for -P, like the ATmega88. > Suffice it to mention that using Atmel Studio > under Windows works flawlessly. Then the only way to find out is (unfortunately) to trace Atmel Studio's actions when initializing the AVR Dragon, and compare it to what AVaRICE does. I'd more suspect the actual debugWIRE connection at first though. You can try experiment with pullup resistors on /RESET. I've seen target working more reliably with 4.7 kΩ or 10 kΩ pullups, but I've also seen target working best without any additional component between the ICE (i.e. your Dragon) and the /RESET line. Also make sure to use at most the standard STK500 cable length between the Dragon and the target (about 15 cm), as the Dragon's line drivers are known to be quite weak. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Brian <bh...@ch...> - 2016-05-18 05:20:25
|
Hello,
I'm trying desperately to cut all ties with the Windows desktop, and I'm
down to getting a working debugging environment set up for my projects
based around the AtMEGAXXU2 line of processors, which AVaRICE 2.13 does
not appear to directly support.
I found one thread on AVRFreaks[1] from 2010 where some fellow describes
almost exactly the problem I'm having, and his avarice command used
"--part atmega48" -- he does not describe how he came to select atmega48
as the device to force. More importantly, there is not a single
response to that thread! :-( So there's no help to be had.
Anyway, it boils down to this: AVaRICE will start and seem happy,
avr-gdb will connect to it and seem happy, but once I actually start
execution (by issuing "continue" command) AVaRICE very quickly starts to
complain about receive timeouts:
got asynchronous event: 0xf7
recv: timeout
command[0x00, 7]: 00
recv: 0x1b
recv: 0xff
recv: 0xff
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: f7
recv: 0xc6
recv: 0x79
CRC OK
Got message seqno 65535 (command_sequence == 16)
This sequence of messages is emitted repeatedly, with the values in the
square brackets of "command[0x00, 7]: 00" changing/incrementing until
eventually this message arrives:
got asynchronous event: 0xf7
recv: timeout
terminate called after throwing an instance of 'jtag_exception'
what(): JTAG communication failed
Aborted
..at which point AVaRICE exits and of course avr-gdb tells me the remote
connection is closed.
So...is this something to do with telling AVaRICE it's an atmega48 when
it's really an atmega8u2? Suffice it to mention that using Atmel Studio
under Windows works flawlessly.
AVaRICE v 2.13, built from source
avr-gdb 7.7.1
Debian Jessie x64
AVRDragon firmware revision 7.39
Thanks in advance for any help!
Regards,
-Brian
|
|
From: Joerg W. <j...@ur...> - 2016-03-07 22:07:46
|
As Tomek wrote: > It works ok, avarice is running after this, but then it shows > no_source.png Sorry, I have no idea about Eclipse on that. You probably have to convince Eclipse that the firmware present in the microcontroller indeed matches your project's output, even though they were not allowed to reprogram it. Btw., -gdwarf-4 would be the debugging format most suitable for recent versions of GDB. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Tomek <sq...@gm...> - 2016-03-07 21:59:34
|
Joerg, I do this - no_flashing.png It works ok, avarice is running after this, but then it shows no_source.png 73! Tom On 07 Mar 2016, at 21:19, Joerg Wunsch <j...@ur...> wrote: As Tomasz Wawer wrote: >> Please have a look, maybe you could help with this: > Well, I told you that code downloading through debugWIRE > currently doesn't work, neither in AVRDUDE nor in AVaRICE > through GDB's "load" command. > > Sorry, I have no real idea so far *why* it fails. It pretends > to write the first data block, but it never gets written, and > then the AVR communication with the ICE is lost it seems. > > I have USB traces that show what Atmel Studio is doing, and > need quite some time to compare them to what AVRDUDE does (the > Studio trace is really huge). > > 73! |
|
From: Joerg W. <j...@ur...> - 2016-03-07 21:30:04
|
As sq5rix wrote: > Hmm, I know that - that's why I load code to processor before > debugging - then I manually change debugWire fuse. I miss something > here.... But it seems your Eclipse always wants to (re-)load it anyway: (From the avrfreaks thread:) > buffering data, 48 bytes @ 0x19e0 > buffering data, 48 bytes @ 0x1a10 > buffering data, 48 bytes @ 0x1a40 > buffering data, 48 bytes @ 0x1a70 > buffering data, 24 bytes @ 0x1aa0 > committing to flash > Failed to write target memory space: debugWIRE failed > When I start avr-dbg manually like > > avr-dbg Enkoder.elf > > I see the source code in list command and I can debug. OK, that's expected. ;-) It might even work from inside Eclipse, provided you can tell it to not reload the flash first. 73 es 55! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: sq5rix <sq...@gm...> - 2016-03-07 21:26:01
|
Hmm, I know that - that's why I load code to processor before debugging - then I manually change debugWire fuse. I miss something here.... When I start avr-dbg manually like avr-dbg Enkoder.elf I see the source code in list command and I can debug. Ok, I keep my fingers crossed :) 73! Tomasz Wawer On 07 Mar 2016, at 21:19, Joerg Wunsch <j...@ur...> wrote: As Tomasz Wawer wrote: > Please have a look, maybe you could help with this: Well, I told you that code downloading through debugWIRE currently doesn't work, neither in AVRDUDE nor in AVaRICE through GDB's "load" command. Sorry, I have no real idea so far *why* it fails. It pretends to write the first data block, but it never gets written, and then the AVR communication with the ICE is lost it seems. I have USB traces that show what Atmel Studio is doing, and need quite some time to compare them to what AVRDUDE does (the Studio trace is really huge). 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Tomasz W. <waw...@gm...> - 2016-03-07 21:22:54
|
Hmm, I know that - that's why I load code to processor before debugging - then I manually change debugWire fuse. I miss something here.... When I start avr-dbg manually like avr-dbg Enkoder.elf I see the source code in list command and I can debug. Ok, I keep my fingers crossed :) 73! Tomasz Wawer On 07 Mar 2016, at 21:19, Joerg Wunsch <j...@ur...> wrote: As Tomasz Wawer wrote: > Please have a look, maybe you could help with this: Well, I told you that code downloading through debugWIRE currently doesn't work, neither in AVRDUDE nor in AVaRICE through GDB's "load" command. Sorry, I have no real idea so far *why* it fails. It pretends to write the first data block, but it never gets written, and then the AVR communication with the ICE is lost it seems. I have USB traces that show what Atmel Studio is doing, and need quite some time to compare them to what AVRDUDE does (the Studio trace is really huge). 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Joerg W. <j...@ur...> - 2016-03-07 20:19:50
|
As Tomasz Wawer wrote: > Please have a look, maybe you could help with this: Well, I told you that code downloading through debugWIRE currently doesn't work, neither in AVRDUDE nor in AVaRICE through GDB's "load" command. Sorry, I have no real idea so far *why* it fails. It pretends to write the first data block, but it never gets written, and then the AVR communication with the ICE is lost it seems. I have USB traces that show what Atmel Studio is doing, and need quite some time to compare them to what AVRDUDE does (the Studio trace is really huge). 73! -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Tomasz W. <waw...@gm...> - 2016-03-07 19:40:22
|
Hi guys, Please have a look, maybe you could help with this: http://www.avrfreaks.net/forum/atmel-ice-avarice-eclipse-and-debugging-ubuntu I hit a wall :( Greetings, Tomasz Wawer SQ5RIX |
|
From: Joerg W. <j...@ur...> - 2016-03-07 12:55:18
|
As Philip Mulrane wrote: > I don't actually have a PC-based Linux installation (would avarice run > on a Raspberry Pi? If so, then I could try this tomorrow). There doesn't appear to be an easy way, alas. Raspbian has most of what's needed, but for the libusb 0.1 API wrapper, they only ship libusb-0.1.so.4, but no "-dev" package (static library, header file), so configure does not find anything. As the current src/jtag2usb.cc depends on the availability of the 0.1 libusb API in order to compile anything at all, this is fatal. With a little bit of cleanup, it might be possible to allow for just the --edbg functionality (which doesn't need libusb at all) without libusb 0.1 being present, but that needs to be sorted out. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
|
From: Joerg W. <j...@ur...> - 2016-03-06 12:37:26
|
As Philip Mulrane wrote: > I don't actually have a PC-based Linux installation (would avarice run > on a Raspberry Pi? I never tried it, but I think it might run there, provided libusb and libhidapi are available. In addition, the only resources AVaRICE is using are pipes and Posix threads, which I think won't be a problem on the RPi. I've got an older RPi around, where I could try that as well. > Are there any recommended > Virtual PC solutions that are better from the point of view that the USB > will also be virtual? I've always made the best experiences regarding USB using VMware. I've got a couple of Windows guests running on Linux hosts that way, and e.g. even firmware upgrades from within Atmel Studio do work. The VMware Player (without "plus") is free of charge, but pretty well hidden on the VMware website. ;-) It's main missing feature compared to the pay version is that it cannot handle snapshots. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
13 messages has been excluded from this view by a project administrator.
