Git Product home page Git Product logo

avarice's People

Contributors

canyonbliss avatar colinoflynn avatar eweddington avatar friggeri avatar jputcu avatar maxgerhardt avatar troth avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

avarice's Issues

[bug #21] Deprecated feature used as example of Avarice use

bradachj
2015-10-16 17:10:40.413000

Very minor cleanup: Programming via Avarice is depreciated and the option has been removed from the usage text on the command line. However, the example given of how to start avarice is:

e.g. avarice --erase --program --file test.bin --jtag /dev/ttyS0 :4242

Which when used an example will cause Avarice to spit out:

AVaRICE has not been configured for target programming
through the --program option. Target programming in
AVaRICE is a deprecated feature; use AVRDUDE instead.

avarice_bug21.patch

This issue was migrated from https://sourceforge.net/p/avarice/bugs/21/

[patch #11] Add option to print list of known devices

rmann
2008-04-21 19:37:46

Enclosed is a patch to avarice-2.7 that adds a -k/--known-devices option to print a list of AVR devices known to AVaRICE:

$ src/avarice --known-devices
AVaRICE version 2.7, Apr 18 2008 15:09:15

List of known AVR devices:

Device Name Device ID Flash EEPROM


atmega16 0x9403 16 KiB 0 KiB
atmega162 0x9404 16 KiB 0 KiB
atmega169 0x9405 16 KiB 0 KiB
atmega323 0x9501 32 KiB 1 KiB
atmega32 0x9502 32 KiB 1 KiB
atmega64 0x9602 64 KiB 2 KiB
atmega128 0x9702 128 KiB 4 KiB
at90can128 0x9781 128 KiB 4 KiB
atmega164p 0x940A 16 KiB 0 KiB
atmega324p 0x9508 32 KiB 1 KiB
atmega644 0x9609 64 KiB 2 KiB
atmega325 0x9505 32 KiB 1 KiB
atmega3250 0x9506 32 KiB 1 KiB
atmega645 0x9605 64 KiB 2 KiB
atmega6450 0x9606 64 KiB 2 KiB
atmega329 0x9503 32 KiB 1 KiB
atmega3290 0x9504 32 KiB 1 KiB
atmega649 0x9603 64 KiB 2 KiB
atmega6490 0x9604 64 KiB 2 KiB
atmega640 0x9608 64 KiB 4 KiB
atmega1280 0x9703 128 KiB 4 KiB
atmega1281 0x9704 128 KiB 4 KiB
atmega2560 0x9801 256 KiB 4 KiB
atmega2561 0x9802 256 KiB 4 KiB
at90usb1287 0x9782 128 KiB 4 KiB
atmega48 0x9205 4 KiB 0 KiB
atmega88 0x930A 8 KiB 0 KiB
atmega168 0x9406 16 KiB 0 KiB
attiny13 0x9007 1 KiB 0 KiB
attiny2313 0x910A 2 KiB 0 KiB
at90pwm2 0x9381 8 KiB 0 KiB
at90pwm3 0x9381 8 KiB 0 KiB
at90pwm2b 0x9383 8 KiB 0 KiB
at90pwm3b 0x9383 8 KiB 0 KiB
attiny24 0x910B 2 KiB 0 KiB
attiny44 0x9207 4 KiB 0 KiB
attiny25 0x9108 2 KiB 0 KiB
attiny45 0x9206 4 KiB 0 KiB
attiny261 0x910C 2 KiB 0 KiB
attiny461 0x9208 4 KiB 0 KiB
attiny861 0x930D 8 KiB 0 KiB

patch.txt

This issue was migrated from https://sourceforge.net/p/avarice/patches/11/

[bug #27] address of array will always evaluate to 'true'

ryandesign
2020-07-09 22:00:54.262000

I see these warnings when compiling avarice 2.13 (on macOS 10.13):

devdescr.cc:2251:2: warning: address of array 'atmega32m1_io_registers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        atmega32m1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
devdescr.cc:2375:2: warning: address of array 'atmega32c1_io_registers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        atmega32c1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

I don't know what the correct fix is.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/27/

[bug #12] No configuration available for device ID: ffff

l07
2008-02-18 09:30:47

I use avarice 2.6 on Linux 2.6.24-gentoo-r2.
I have a JTAGICEmkII and ATmega64. In Windows and AvrStudio4 I can upload and download flash/eep and etc. (Fuse bit JTAGEN = 1).
But in avarice I have:

$ avarice -2 -jusb

JTAG config starting.
Found a device: JTAGICEmkII
Serial number: 00:b0:00:00:37:2d
Reported JTAG device ID: 0xFFFF
No configuration available for device ID: ffff

In debug mode I see:
Automatic device detection:
response: 81 FF FF FF FF
JTAG id = 0xFFFFFFFF : Ver = 0xf : Device = 0xffff : Manuf = 0x7ff
No configuration available for device ID: ffff
(see attach file).

If I try to set -P atmega64 in command line, avarice say:
Reported JTAG device ID: 0xFFFF
Configured for device ID: 0x9602 atmega64 -- FORCED with atmega64
JTAG config complete.
JTAG ICE: Cannot synchronise

Thank you.

avarice-2.6-my2.log

This issue was migrated from https://sourceforge.net/p/avarice/bugs/12/

[bug #33] Problem with "info io_registers"?

gatk555
2021-04-21 18:20:44.572000

This is an odd bug report as I do not have any hardware to demonstrate that there actually is a bug. But my story strongly suggests that there is.

The background is that I was trying to implement support for this command in an AVR simulator, simavr. It seemed straightforward, but when tested, I found that gdb would endlessly repeat the initial command, which is supposed to return the number of I/O registers. Trying to understand that, I looked for a working implementation and downloaded the source code. I was surprised to find code in Avarice very like my own.

After some digging in current gdb source, I was able to make it work. The command uses a gdb function that seems intended to retrieve data of indefinite length, perhaps the contents of a file. It repeats the command, concatenating the replies, until it receives an empty reply, which it treats as end-of-file. So the way to make this work is to reply normally and then send an empty packet on the first repetition.

I found no such code in Avarice, making me think there is probably a bug with this command. I hope this proves useful.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/33/

[bug #20] Detach starting with shell from avr-gdb - communication error

frexgj
2014-10-23 20:07:38.181000

When starting AVaRICE from avr-gdb with the shell command and detach parameter the communication doesn't work.
From my understanding the avr-gdb <-> AVaRICE (TCP) connection is okay. But the pipes that are used to communicate with the backend (AVR Dragon in my case) somehow don't seem to work anymore.
When moving the point where the detach is actually done a bit higher in main it works (for me).
I'm using Code::Blocks for Debugging and am running on XUbuntu 14.4, AVaRICE is from SVN. Debugging hardware is an AVR Dragon with 7.38 Firmware.
I'm also using AVaRICE for programming although this is not recommended anymore (but when using avrdude the usb is blocked for some time afer it is done and i would have to add an delay), maybe that's also contributing to the problem?

This issue was migrated from https://sourceforge.net/p/avarice/bugs/20/

[bug #16] Avarice dies with timeout upon memory read

svenq
2012-11-16 09:57:50

Avarice dies with a receive timeout when reading memory from an ATMega32u4 via JTAG, after apparently correct initialization.

MCU: ATMEGA32U4
Tools: AVR JTAG ICE mkII, FW 7.28 or FW 6.x
Avarice 2.10, 2.12 or 2.13 on Gentoo Linux or Debian Linux
avr-gdb 7.2 or 7.6

Same setup works with AVR Studio 6

avarice-debugging.txt
atmelstudio6-debug-dump.pcapng.gz
avarice-debugging-02.txt

This issue was migrated from https://sourceforge.net/p/avarice/bugs/16/

[bug #13] build failed with gcc 4.4.0

vladablack
2009-06-25 08:58:22

Build failed on:
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT jtag2usb.o -MD -MP -MF .deps/jtag2usb.Tpo -c -o jtag2usb.o jtag2usb.cc
jtag2usb.cc: In function ‘usb_dev_handle* opendev(const char*, emulator, int&)’:
jtag2usb.cc:98: error: invalid conversion from ‘const char*’ to ‘char*’

I'm using gcc 4.4.0.
Same problem is in 2.10 and current cvs version.

config.log

This issue was migrated from https://sourceforge.net/p/avarice/bugs/13/

[bug #23] program fuse bits through avr-gdb, avarice and debugwire

seplog
2016-03-11 21:06:41.971000

Hey,

there exist a problem with avarice with the program loading within the avr-gdb.
If there are fuse bits defined in the source code, then it is not possible to load the program with avr-gdb.
Here is a short example code

#include <avr/io.h>

FUSES =
{
    .low = FUSE_CKSEL0 & FUSE_SUT1,
    .high = FUSE_BOOTSZ0 & FUSE_BOOTSZ1 & FUSE_EESAVE & FUSE_SPIEN,
    .extended = FUSE_BODLEVEL0 & FUSE_HWBE,
};

int __attribute__((OS_main)) main( void ) {
    while(1);
    return 0;
}

I compiled this with:

avr-gcc -mmcu=atmega32u2 -O0 -g -o firmware.elf main.c

For the ATmega32U2. Debugwire is enabled.
For debugging I use a Atmel JTAGICE mkII. To use avarice with th ATmega32U2 I used this patch.
I've started avarice with:

$ avarice -2 -P atmega32u2 -w -j usb -C :4242 -d

and avr-gdb:

$ avr-gdb firmware.elf 
GNU gdb (Gentoo 7.11 vanilla) 7.11
Copyright (C) 2016 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:
<https://bugs.gentoo.org/>.
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 firmware.elf...done.
(gdb) target remote :4242
Remote debugging using :4242
main () at main.c:11
11          while(1);
(gdb) load
Loading section .fuse, size 0x3 lma 0x820000
Load failed
(gdb) quit
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y

The avarice log file is attached.

Greetings sep

This issue was migrated from https://sourceforge.net/p/avarice/bugs/23/

[bug #9] bfd.h not used for checking of libbfd

kschwi
2008-01-06 16:54:52

While the configure script tries to determine if libbfd.a/.so is installed the prototype for the checking function bfd_init(); is created in the source. It would be more precise to use bfd.h to do this. At opensuse the libbfd is installed with the binutils while the header files are installed with the package binutil-devel. To find the absence of the header file at configuration time the usage of the header file should be preferred. Also the error message of the missing libbfd has to state that any libbfd is required not necessarily the AVR one and that bfd.h is also required.

Knut

This issue was migrated from https://sourceforge.net/p/avarice/bugs/9/

[bug #15] usblib timeouts does not work correctly on solaris platforms

mcerveny
2012-02-27 22:00:54

Hello.

There is problem with usb_bulk_read/usb_bulk_write timeouts in usblib( 0.1.8) on opensolaris/solaris platforms (probably on all <1.0 usblib versions).
I reprogrammed jtag2usb.cc to use thread model (instead of multiprocess) for read and write threads and use blocking calls (timeout = 0).

M.C>

avarice-2.12-30-usbthread.patch
svn297.diff

This issue was migrated from https://sourceforge.net/p/avarice/bugs/15/

[patch #6] IDR (OCDR) support

tsirc
2007-02-24 19:05:34

The attached short patch enables support for the I/O Debug Register
(IDR). The result is that any byte written to the On-chip Debug
Register (OCDR) will appear on stdout of the avarice process. Other
options exist, such as sending a `O' console-output packet to GDB, but
I prefer stdout. Following is an example of how to use this feature
with avr-libc.

Cheers,
Shaun

#include <avr/io.h>
#include <stdio.h>

static int ocd_putchar(char c, FILE *stream)
{
(void)stream;
while (OCDR & 1<<IDRD);
OCDR = c;
return 0;
}

int main()
{
static FILE ocdout = FDEV_SETUP_STREAM(ocd_putchar, NULL,
_FDEV_SETUP_WRITE);
stdout = &ocdout;
puts("Hello, world!");
return 0;
}

avarice-idr.diff

This issue was migrated from https://sourceforge.net/p/avarice/patches/6/

[bug #26] result of comparison of constant 0 with expression of type 'bool' is always false

ryandesign
2020-07-09 21:55:40.792000

I see this warning when compiling avarice 2.13 (on macOS 10.13):

jtagprog.cc:210:38: warning: result of comparison of constant 0 with expression of type 'bool' is always false [-Wtautological-constant-compare]
    if (doSimpleJtagCommand(0xa3, 1) < 0)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
jtagprog.cc:221:38: warning: result of comparison of constant 0 with expression of type 'bool' is always false [-Wtautological-constant-compare]
    if (doSimpleJtagCommand(0xa4, 1) < 0)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
jtagprog.cc:233:38: warning: result of comparison of constant 0 with expression of type 'bool' is always false [-Wtautological-constant-compare]
    if (doSimpleJtagCommand(0xa5, 1) < 0)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
3 warnings generated.

The attached patch fixes it for me.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/26/

[bug #18] Slow connection Using Dragon Jtag

zajc3w
2014-06-28 01:02:51.742000

Im runnin latestst avarice.
latest avrDragon frimware/hardware
Atmega 128 @ 8MHz
Jtag clock set to 1MHz
everything goes smooth untill first "step" command in GDB
it takes 10-15 seconds for single step over line: PORTA = 0xFF;
below part of avarive output
my guess is AVARICE is sending incorrect message ack response(but i'm just a noob ;P)

Got message seqno 51 (command_sequence == 51)
response: 84 52 00 00 00 
jtagRead 
command[0x05, 1]: 05 20 03 00 00 00 5D 00 00 00 
recv: 0x1b
recv: 0x33
recv: 0x00
recv: 0x05
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 5 bytes
read:  84 52 00 00 00
recv: 0xe1
recv: 0x1e
CRC OK
Got message seqno 51 (command_sequence == 52)

got wrong sequence number, 51 != 52
recv: timeout

command[0x05, 2]: 05 20 03 00 00 00 5D 00 00 00 
recv: timeout

command[0x05, 3]: 05 20 03 00 00 00 5D 00 00 00 
recv: timeout

command[0x05, 4]: 05 20 03 00 00 00 5D 00 00 00 
recv: timeout
Resetting EPs...

command[0x05, 5]: 05 20 03 00 00 00 5D 00 00 00 
recv: 0x1b
recv: 0x34
recv: 0x00
recv: 0x04
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 4 bytes
read:  82 fd 10 00
recv: 0xfe
recv: 0x66
CRC OK
Got message seqno 52 (command_sequence == 52)
response: 82 FD 10 00 

This issue was migrated from https://sourceforge.net/p/avarice/bugs/18/

[bug #6] --jtag option does not default to usb using dragon

klauweg
2007-11-13 22:20:28

According to the manual page the default value of the --jtag option should default to "usb" when using --dragon.
But it doesn't and one has to specify --jtag usb explicit.

Joerg Wunsch suggested it is related to this patch:

revision 1.39
date: 2007/03/21 17:06:54; author: c_oflynn; state: Exp; lines: +8 -1
Colin O'Flynn <coflynn@...>

*src/main.cc: Added patch 1121113 which adds JTAG_DEV env variable, no
longer need to use --jtag option if you want.
*doc/avarice.1: Documented above.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/6/

[patch #4] External Reset (JTAG nSRST)

*anonymous
2006-01-06 21:54:19

Hi, I am using a JTAG ICE compatible (ECROS TECH ICE
CUBE) with the ATmega162. When the reset vector points
directly to the bootloader section (0x3800) I found the
'x' command insufficient for proper system start/restart.
The attached patches solved my problem using the
External Reset command. Is this something unique to my
system?
I suggest to apply the External Reset as standard also
in the JTAG ICE MK II since it would also help in cases
where the JTAG gets disabled (through MCUCSR).

Thanks, Enoch.

hwexler -at- nj -dot- rr -dot- com

patches.tar.gz

This issue was migrated from https://sourceforge.net/p/avarice/patches/4/

[bug #17] Sleep event generates 4 lines

kschwi
2013-02-10 14:51:55.356000

Using Avarice for application that operates a sleep-instruction lead to messages in the Avarice dialog windows such. The messages are shown below.


Target went to sleep

Target went out of sleep


4 Lines for one event is too much. Please add a switch off function (either command line or via gdb command - e.g. "monitor messages off"). To reduce the empty lines put both events into one line.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/17/

[patch #7] set parameter command failed

skut
2007-07-09 07:54:01

avarice -r -2 -j usb -w :1212

however fails with the following message:
$ avarice -2 -j usb -w :1212
AVaRICE version 2.6.20070222, Apr 29 2007 11:16:28

Defaulting JTAG bitrate to 1 MHz. Make sure that the target
frequency is at least 4 MHz or you will likely encounter failures
controlling the target.

JTAG config starting.
Found a device: JTAGICEmkII
Serial number: 00:b0:00:00:16:01
Reported debugWire device ID: 0x9406
Configured for device ID: 0x9406 atmega168
JTAG config complete.
Preparing the target device for On Chip Debugging.
set paramater command failed

when I run with the -d option I see the following:

command[0x02, 10]: 02 09 00
recv: 0x1b
recv: 0x06
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a0
recv: 0xc1
recv: 0x3e
CRC OK
Got message seqno 6 (command_sequence == 6)
response: A0
set parameter command failed

Jorge's Patch

Using hack below, I got my local version working around it. Still,
it's not clear to me why the ICE reacts that allergic to the
combination of commands issed. My only guess so far is that after the
resetProgram(), we should rather expect the "break" event being
returned, and await that before trying to set parameters. So perhaps
it would suffice to just remove the first resetProgram() call (there's
a second afterwards anyway).

Index: src/jtag2io.cc

RCS file: /home/cvs/avarice/avarice/src/jtag2io.cc,v
retrieving revision 1.11
diff -u -u -r1.11 jtag2io.cc
--- src/jtag2io.cc 17 Feb 2007 22:41:46 -0000 1.11
+++ src/jtag2io.cc 7 May 2007 19:55:24 -0000
@@ -688,9 +688,9 @@
}

  • resetProgram();
  • uchar timers = 0; // stopped
  • setJtagParameter(PAR_TIMERS_RUNNING, &timers, 1);
    +// resetProgram();
    +// uchar timers = 0; // stopped
    +// setJtagParameter(PAR_TIMERS_RUNNING, &timers, 1);
    resetProgram();
    }

This issue was migrated from https://sourceforge.net/p/avarice/patches/7/

[bug #25] error: use of undeclared identifier 'bfd_get_section_name'

ryandesign
2020-07-09 21:40:04.347000

avarice 2.13 isn't compatible with binutils 2.34. The build fails with:

error: use of undeclared identifier 'bfd_get_section_name'

The developers of binutils removed bfd_get_secton_name. The replacement is bfd_section_name but it takes different parameters (you no longer supply the first parameter) bfd_get_section_size is gone too, replaced by bdf_section_size which takes the same parameters,

The attached patch works for me but may not be the correct patch for everyone; i.e. it may not be compatibile with binutils versions older than 2.34.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/25/

[patch #9] sync to xml from avrstudio 4.14 beta

dbc
2008-03-08 01:46:21

Scripto-maticly generated additions to devdescr.cc intended to bring avarice in sync with the xml included in AVR Studio 4.14 beta. This patch compiles w/o error, and had a very light visual inspection. It has not been tested on real silicon. Does not include ATmega32c1, nor ATmega32m1 since there is a separate patch for them, which should be applied before this patch.

devdescr.cc.patch

This issue was migrated from https://sourceforge.net/p/avarice/patches/9/

[bug #28] Fix build with llvm 11.0.0

leres
2020-08-29 20:13:44.043000

Here's a patch that unbreaks building on FreeBSD 13.0-CURRENT (r364847) with llvm 11.0.0:

--- devdescr.o ---
devdescr.cc:2251:2: error: type 'gdb_io_reg_def_type []' cannot be narrowed to 'bool' in initializer list [-Wc++11-narrowing]
        atmega32m1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
devdescr.cc:2251:2: note: insert an explicit cast to silence this issue
        atmega32m1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
        static_cast<bool>(     )
devdescr.cc:2375:2: error: type 'gdb_io_reg_def_type []' cannot be narrowed to 'bool' in initializer list [-Wc++11-narrowing]
        atmega32c1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
devdescr.cc:2375:2: note: insert an explicit cast to silence this issue
        atmega32c1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
        static_cast<bool>(     )
devdescr.cc:2375:2: warning: address of array 'atmega32c1_io_registers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        atmega32c1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
devdescr.cc:2251:2: warning: address of array 'atmega32m1_io_registers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        atmega32m1_io_registers,
        ^~~~~~~~~~~~~~~~~~~~~~~
2 warnings and 2 errors generated.

The problem appears to be two instances of static initialzation of the wrong field. These look like straight up bugs to me that the newer compiler with better warning detects.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/28/

[bug #31] Cannot compile avarice-2.14.tar.bz2 due to '__unused'

maxgerhardt
2021-02-12 17:25:15.846000

Downloading the latest version in on this page, unpacking, configuring and building it leads to the errors

jtag3io.cc:353:42: error: expected ‘,’ or ‘...’ before ‘__unused’
  353 | void jtag3::changeBitRate(int newBitRate __unused)
      |                                          ^~~~~~~~
jtag3io.cc: In member function ‘virtual void jtag3::changeBitRate(int)’:
jtag3io.cc:353:31: warning: unused parameter ‘newBitRate’ [-Wunused-parameter]
  353 | void jtag3::changeBitRate(int newBitRate __unused)
      |                           ~~~~^~~~~~~~~~
jtag3io.cc: At global scope:
jtag3io.cc:358:39: error: expected ‘,’ or ‘...’ before ‘__unused’
  358 | bool jtag3::synchroniseAt(int bitrate __unused)
      |                                       ^~~~~~~~

That's on Ubuntu 20.04 with GCC version 9.3.0. The __unused keyword seems to make problems here.

Doing a quick replace-with-nothing using

sed -i -e 's/__unused//g' src/jtag*.cc

makes the program compile after another make.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/31/

[bug #29] avarice segmentation fault

faeren03
2020-09-19 07:33:42.556000

Hello,

I have a problem using avr-gdb with avarice on an Atmega32.
Stopping, normal stepping, continuing without breakpoints works fine.
But when I add a breakpoint and continue the execution of the code then I receive this Segmentation fault (core dumped) error.
When I try to step out of a function then I also receive this Segmentation fault (core dumped) error.

See pictures attached.

Do you have any idea why?

Thank you very much!

Best regards,
Mate Varga

backtrace.png
output.txt
gdbbt.png
avarcompiled1.png
avarcompiled2.png
avariceownbuildoutput.png
gflag.png
fix_jtag1_breakpoints_crash.patch

This issue was migrated from https://sourceforge.net/p/avarice/bugs/29/

[bug #10] jtag daisy chain bits limitations

guerrier
2008-01-11 06:54:03

Hello

the limitations on the daisy chain parameters ( -c x,x,x,x option ) seem to be wrong. my guess is 255 for all four, or 7,7,255,255 instead of 255,255,7,7

i had this problem on a board with 2 devices and total 13 bits after the AVR.

I could not try to recompile without the limitation, because the nightly snapshot or release archive seem to be broken (or it is my tar which is broken ...)

http://avarice.cvs.sourceforge.net/avarice/avarice/src/main.cc?revision=1.40&view=markup

if (units_before > 255 || units_after > 255 ||
bits_before > 7 || bits_after > 7) {

This issue was migrated from https://sourceforge.net/p/avarice/bugs/10/

[patch #1] Adds --program-no-erase option

*anonymous
2004-01-07 21:11:45

Adds --program-no-erase, -n option. I use it to
program the EEPROM after programming the flash, as in:

avarice --jtag /dev/ttyS4 --part atmega128 --file
test.rom
avarice --jtag /dev/ttyS4 --part atmega128
--program-no-erase --file test.eeprom

The patch is against a CVS pull from this morning.

This may be unnecessary if there's already a way to
program the flash and eeprom in one step --- I didn't
know how.

Dean Ferreyra
[email protected]

patch.txt

This issue was migrated from https://sourceforge.net/p/avarice/patches/1/

[bug #14] Unable to build on Fedora x64 without -ldl

jescombe
2011-12-30 10:36:29

Building on Fedora 16 x64 results in the following error;

g++ -g -O2 -o avarice crc16.o devdescr.o ioreg.o jtag2bp.o jtag2io.o jtag2misc.o jtag2prog.o jtag2run.o jtag2rw.o jtag2usb.o jtagbp.o jtaggeneric.o jtagio.o jtagmisc.o jtagprog.o jtagrun.o jtagrw.o main.o remote.o utils.o gnu_getopt.o gnu_getopt1.o -lusb -lbfd -liberty -lz
/usr/lib64/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x3bb): undefined reference to `dlopen'
/usr/lib64/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x3da): undefined reference to `dlsym'
/usr/lib64/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x47b): undefined reference to `dlerror'
collect2: ld returned 1 exit status
make[2]: *** [avarice] Error 1

So it appears that libbfd on Fedora also requires libdl, adding LIBS="$LIBS -ldl" to the configure script results in a successful build.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/14/

[bug #2] Return address wrong

russell2020
2005-01-04 15:07:13

AVaRICE version 2.3

If i step into a call where the next address (its
return address) should be 0xf8, and examine the return
address stored on the stack using avr-gdb, i get 0x7c.
This is the real return address, but shifted right by
one bit.

If i step into a few nested functions then type bt
(backtrace), it returns corrupted data, probably
because of that bit shifting bug.

Using avr-gcc 3.4.3 and avr-gdb 6.1.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/2/

[bug #19] Debugging 4-page erase devices (tiny841, tiny1634, ...) - Change on device-descriptor

frexgj
2014-10-23 19:38:04.612000

Since the new tiny841 was very interesting to me I bought some and got exploring. But soon I found out that it was not supported by AVaRICE (at least not until now ;-).
First I tried making an device-descriptor by myself. But this didn't work out. Maybe I screwed up there. But in the end I simply traced the usb communication on a Windows-PC (at work) and then found out that there was a different format used for the device-descriptor as it is used in AVaRICE up-to now. I think this ist mostly due to the 4-Page Erase logic of the tiny841. I think this same method is also used on the tiny1634 and tiny441. Essentially an erase always erases 4 flash-pages so that the page-buffer has to be filled 4 times in order to write the the same amount as was erased before. (I guess the only advance is in saving some registers for holding that page-buffer).
So since breakpoints on those debugWire-devices is merely a break-instruction the flash has to be reprogrammed whenever a new breakpoint is set. For that the Debug-Hardware needs to now that the page-buffer doesn't cover the entire erase-window.

So I basically copied the raw-data of the usb-commands and inserted a device-specific command sequence in the setDeviceDescriptor function. This is very ugly and should probably be moved to somewhere else. But I think it should be somebody who has a deeper understanding of the software, as it might involve extending that device-descriptor-table.

Anyways that patch works for me.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/19/

[bug #3] avr-gdb and avarice chashing

*anonymous
2006-05-03 18:22:10

I use avarice 2.4 and avr-gdb 6.3
My hardware ist an AVR-Butterfly and a selfmade
evertool-light JTAG device.

Device programm works properly, so the evertool seems
o.k.

But if i try to debug all crash up:
$ avarice --debug [...]
Waiting for connection on port 4242.
Connection opened by host 127.0.0.1, port 4020.
GDB:
->GDB:
GDB:
->GDB:
GDB:
->GDB:
GDB: <?>
->GDB: S05
GDB:
->GDB:
GDB:
->GDB:
GDB:

GDB: (Registers)Read 32 bytes from 0x800000
jtagRead
command[R, 1]: 52 20 1F 00 00 00 20 20
response: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07
07 07 07 07 07
07 07 07 07 07 07 07 07 07 07
07 07 00 46
->GDB: E01
gdb exited.

command[G, 1]: 47 20 20
response:

What's wrong here?

regards
Bert

This issue was migrated from https://sourceforge.net/p/avarice/bugs/3/

[bug #11] AVR-Dragon needs libusb-dev

waynegramlich
2008-01-26 22:14:17

When I first compiled avarice, I accidentally did not
have libusb-dev installed on my system. ./configure worked just fine, but every time I tried to specify
"-g -j usb", I kept getting really strange error
messages. Of course the problem is the usb access
code is all protected by #ifdef LIBUSB clauses.
I would recommend adding a chunk of code with
basically the following structure:

#ifndef HAVE_LIBUSB
if (strncmp(jtagDeviceName, "usb", 3) == 0) {
(void)fprintf(stderr,
"avarice needs to be compiled with libusb-dev\n");
exit(1);
}
#endif /* HAVE_LIBUSB */

I basically wasted 2 hours tracking that little
nasty down.

This issue was migrated from https://sourceforge.net/p/avarice/bugs/11/

[patch #16] Added support for ATXMega256A3 MCU (avarice 2.10)

riccardomanfrin
2010-05-24 15:52:00

Patch for avarice 2.10 to support erase/program/on-chip-debug on atxmega256a3 via mkII jtag ice interface.

Changelog:

  • Added description for xmega256A3 in src/devdescr.cc
  • Added xmega mkII erase command support (avr067)
  • Added xmega mkII memory types support (avr067)
  • Removed some "const" attributes (that libc-2.10 complained about).

avarice-2.10_atxmega256a3_support.patch

This issue was migrated from https://sourceforge.net/p/avarice/patches/16/

[patch #5] decrease default bitrate

stsp
2006-10-30 18:32:12

Hi.

It looks like some (many?) AVR microcontrollers are
preconfigured to use an internal RC oscillator. Since
this oscillator is about 1MHz, the avarice can't work
reliably with them right now. Yes, it does issue the
warning on startup, but it seems to be not always
enough (wasn't in my case, at least :).
I think it would be good for avarice to handle those
controllers out of the box, for which the default
frequency must be reduced. The AVRStudio have no such
problem, so I guess it uses the lower bitrate by
default too.
The attached patch changes the default bitrate to 250KHz.

frq.diff

This issue was migrated from https://sourceforge.net/p/avarice/patches/5/

[bug #32] Compile failed on Ubuntu 20.04

joes1
2021-02-12 17:38:21.894000

Hi,
it is impossible to build avarice V2.14 successfully following the instructions in INSTALL.
./configure gives some warnings like:

configure: WARNING: arpa/inet.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: arpa/inet.h: proceeding with the compiler's result

and make some warnings and errors like:

jtag3io.cc:321:5: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
  321 |     throw (jtag_exception)
      |     ^~~~~
      :
jtag3io.cc: In member function ‘virtual void jtag3::changeBitRate(int)’:
jtag3io.cc:353:31: warning: unused parameter ‘newBitRate’ [-Wunused-parameter]
  353 | void jtag3::changeBitRate(int newBitRate __unused)
      |                           ~~~~^~~~~~~~~~
jtag3io.cc: At global scope:
jtag3io.cc:358:39: error: expected ‘,’ or ‘...’ before ‘__unused’
  358 | bool jtag3::synchroniseAt(int bitrate __unused)
      |                                       ^~~~~~~~

gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) was used. Are there more special environment settings necessary?

Regards,
Jörg

This issue was migrated from https://sourceforge.net/p/avarice/bugs/32/

[bug #7] cannot read program counter/Watchdog has expired

klauweg
2007-11-16 20:23:21

GDB shows the following error messages:

GNU gdb 6.4
Copyright 2005 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=i486-linux-gnu --target=avr"...
0x00000000 in __vectors ()
(gdb) cont
Continuing.
################### CTRL+C pressed!
Program received signal SIGINT, Interrupt.
0x000000f4 in main ()
at /usr/lib/gcc/avr/4.2.1/../../../../avr/include/util/delay_basic.h:105
105 asm volatile (
(gdb) next
8 for (i=0;i<50;i++) _delay_ms(10);
(gdb) next
################### CTRL+C pressed!
cannot read program counter
Watchdog has expired. Target detached.
(gdb)

avarice was the following version:
AVaRICE version 2.7.20071102, Nov 13 2007 18:08:30

Here comes the debugged program:
#include <util/delay.h>

int main(void)
{
int i;

while(1)
for (i=0;i<50;i++) _delay_ms(10);

return 0;
}

avarice start:
/usr/local/avr-toolchain/bin/avarice --debug --jtag usb --dragon --debugwire --part attiny44 -B 125kHz :6423

gdb start:
/usr/local/avr-toolchain/bin/ice-gdb dragontest.elf

The avarice debug output comes in attached file.

debug

This issue was migrated from https://sourceforge.net/p/avarice/bugs/7/

[bug #22] Unknown device is not clearly named

kschwi
2016-02-23 20:10:01.623000

Currently avarice shows not loud and clearly if a new / unknown device shall be debugged. As discussed with Jörg the following message block shall be shown:

============================
Device ID 0x9843 is not known to AVaRICE.
Please ask for it being added to the code, or use
-P to override the automatic decision.

Cheers,
Knut

This issue was migrated from https://sourceforge.net/p/avarice/bugs/22/

[bug #30] 2.14 compiling issues and atmel-ice usb not found

christian26
2020-11-17 15:01:37.474000

Hi,

Thank you for adding Atmel-ICE support to avarice, that is great news!

I was trying to compile 2.14 on a Ubuntu 18.04 machine. gcc version Ubuntu 7.5.0-3ubuntu1~18.04. packages binutils-dev libusb-dev installed for library support.

Compiled with command:

./configure
make -lusb

gcc breaks with this error:

g++ -DHAVE_CONFIG_H -I.  -Wall -Wextra   -g -O2 -MT devdescr.o -MD -MP -MF .deps/devdescr.Tpo -c -o devdescr.o devdescr.cc
devdescr.cc:36:51: error: _Pragma takes a parenthesized string literal
 PRAGMA_DIAG_IGNORED("-Wmissing-field-initializers")
                                                   ^
In file included from jtag.h:31:0,
                 from devdescr.cc:29:
pragma.h:33:38: error: ‘_Pragma’ does not name a type
 #      define PRAGMA_DIAG_IGNORED(x) _Pragma(GCC diagnostic ignored x)
                                      ^
devdescr.cc:36:1: note: in expansion of macro ‘PRAGMA_DIAG_IGNORED’
 PRAGMA_DIAG_IGNORED("-Wmissing-field-initializers")

By editing pragma.h such that it uses the pragmas for gcc version 4, it compiles, but then breaks again with this error:

jtagrw.cc: In member function ‘virtual uchar* jtag1::jtagRead(long unsigned int, unsigned int)’:
jtagrw.cc:134:13: error: cannot convert ‘bool’ to ‘uchar* {aka unsigned char*}’ in return
      return false;

Modifying this line to return NULL instead seems to solve the problem. This lead to a working binary. However, an AVR-ICE connected to the USB port is not recognized:

dev:avarice-2.12$ src/avarice --jtag usb
AVaRICE version 2.12, Nov 17 2020 09:54:27

Defaulting JTAG bitrate to 250 kHz.

did not find any USB device "usb"
USB device not found

Probably just something I am doing wrong... right?

Again, great work from you guys, keep it up!

-- Christian

This issue was migrated from https://sourceforge.net/p/avarice/bugs/30/

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.