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...> - 2022-01-23 19:14:42
|
Hello everyone, I just migrated the SVN repository to Github. New location is: https://github.com/avrdudes/avarice I have disabled developer write access to the SVN repo, so it remains merely as a reference for the existing code base (even though I believe the Git repository to contain everything that used to be in SVN). I'm still about to investigate how to / how many migrate issue trackers there as well. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Joerg W. <j...@ur...> - 2021-12-30 22:50:48
|
As AVaRICE SVN repository wrote: > Support code formatting using clang-format While I agree it's good to have some code formatting rules, please do not apply code formatting onto arbitrary files just for the purpose of changing the formatting. Gratuitously changing just the formatting of some files generates a bunch of irrelevant diffs if you are going to traverse that change later on, thus potentially hiding the actual code changes. (FreeBSD did this mistake once, more than 25 years ago, by removing all trailing white space throughout the entire tree.) -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Joerg W. <j...@ur...> - 2021-10-24 13:55:44
|
As Matthias B. wrote: > I don't know if the output *IDR dirty:... *does have any negative > effects or how to solve it!? I've just seen this the very first debug > session, might be not relevant. It's just an event posted by the ICE, and AVaRICE translates it. Probably not relevant. > Starting a debug session now often fails after "Preparing the target > device for On Chip Debugging." and a second call of avarice --jtag usb > --edbg :4242 mostly succeeds. That's a bit strange. The entire CMSIS-DAP related code leaves quite a bit to be desired. However, changing it would basically require a full rewrite since many of the underlying concepts and ideas do not match 1:1 to the way the CMSIS-DAP protocol is working. I don't have the time and energy to do this, alas. (OpenOCD definitely got that handling better, debugging ARMs with the Atmel-ICE works flawlessly.) > Another thing I've never seen before are lots of *Target went to sleep > *and *Target went out of sleep *prints in the shell during debugging. Likewise, events posted by the ICE. I'm not quite sure, I think the -E option might help you. -E, --event <eventlist> List of events that do not interrupt. JTAG ICE mkII and AVR Dragon only. Default is "none,run,target_power_on,target_sleep,target_wakeup" Just experiment a bit with that. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Matthias B. <mat...@po...> - 2021-10-23 14:22:18
|
Hi Marian, that was a good hint, thanks to solve the main problem! _To document the needed steps if anyone else runs into this problem:_ sudo apt-get install libhidapi* (libhidapi-hidraw0, libhidapi-hidraw0 and libhidapi-libusb0) Checkout r392 ( https://sourceforge.net/p/avarice/code/HEAD/tree/trunk/avarice/ ). (!392! not the current avarice-2.14 (==r388) because of compile problems!) ./Bootstrap ./automake ./configure make sudo make install Remember to update the udev rules for your device (thanks Istvan Retaller for the hint!). Now you can start avarice (no need to start it from gdb, use a standard linux shell): *avarice --jtag usb --edbg :4242* (remember to use sudo here if no udev rules are defined for your USB device) It should output something like this: *AVaRICE version 2.14svn20200906, Oct 23 2021 14:58:21** ** Defaulting JTAG bitrate to 250 kHz.** ** JTAG config starting.** ** Found a device, serial number: J42700041897** ** Reported device ID: 0x9705** ** Configured for device ID: 0x9705 atmega1284p** ** JTAG config complete.** ** Preparing the target device for On Chip Debugging.** ** IDR dirty: 0x80** ** Waiting for connection on port 4242. *And if you then connect with eclipse you'll see * * *Connection opened by host 127.0.0.1, port 55730.** ** IDR dirty: 0x01** * I don't know if the output *IDR dirty:... *does have any negative effects or how to solve it!? I've just seen this the very first debug session, might be not relevant. Starting a debug session now often fails after "Preparing the target device for On Chip Debugging." and a second call of avarice --jtag usb --edbg :4242 mostly succeeds. That's a bit strange. Another thing I've never seen before are lots of *Target went to sleep *and *Target went out of sleep *prints in the shell during debugging. Yes, I'm excessively using different power down states for this project, but I'm not interested to get this state printed because I might miss relevant output. Is there a possibility to turn this off? At the moment it feels like debugging with my mkII was somehow easier and worked directly. But in the end I'm really glad that I'm now able to use the new debugger! :-) So thanks for your help and kind regards, Matthias On 10/23/21 2:32 PM, Marian Buschsieweke wrote: > Hi Matthias, > > the new Atmel ICE is the first debugger using hidapi if I recall > correctly. Maybe you didn't compile AVaRICE without hidapi headers > installed? This would also explain why it works fine with older debuggers. > > I remember having had the same issue and there was no error message or > similar to indicate the cause of the issue, which resulted in some > time spent debugging until I figured out the cause. > > Kind regards, > Marian > > On 23 October 2021 14:19:22 CEST, "Matthias B." <mat...@po...> > wrote: > > Hi, > > I had problems with flash programming with my old MKII and > therefore bought a new Atmel-ICE. > My PC is running on linux and I can use this new debugger with > your version Version 6.3-20171130 for programming but somehow not > for debugging. > > So at the moment I can use my mkII for debugging and the Atmel-ICE > for programming - it's somehow weird and I need to solve this > problem for the Atmel-ICE ;-) > > For the MKII I use the sequence > * avarice --jtag usb --mkII :4242* > and was afterwards able to start debugging via eclipse. Very simple. > > If I adapt this sequence for the new debugger > *avarice --jtag usb --edbg :4242* > just nothing happens, which means the output is > * AVaRICE version 2.14svn20200906, Sep 28 2021 > 21:09:28** > ** Defaulting JTAG bitrate to 250 kHz.* > and it ends. > > I read (https://sourceforge.net/p/avarice/bugs/29/ , Joerg > Wunsch) I might have to use this out of a gdb session like > *gdb avrice* > and then > *(gdb) run -1 -j usb :4242 > *the output is* > Starting program: /usr/local/bin/avarice -1 -j > usb :4242 > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 > Defaulting JTAG bitrate to 250 kHz. > did not find any USB device "usb" > [Inferior 1 (process 260701) exited with code 01] > *Looking up the atmel-ice usb device: > *(gdb) run -1 -j /dev/bus/usb/001/048 :4242** > *the output is* > Starting program: /usr/local/bin/avarice -1 -j > /dev/bus/usb/001/048 :4242 > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 > Defaulting JTAG bitrate to 250 kHz. > [Inferior 1 (process 260758) exited with code 01] > > *So in summary I got stuck somehow and don't really know how to go on. > Can someone point me into the right direction how to initiate a > debug session with avarice and the Atmel-ICE? > > Kind regards, > Matthias > > > > -- Via smartphone. |
From: Marian B. <mar...@ov...> - 2021-10-23 13:48:19
|
Hi Matthias, the new Atmel ICE is the first debugger using hidapi if I recall correctly. Maybe you didn't compile AVaRICE without hidapi headers installed? This would also explain why it works fine with older debuggers. I remember having had the same issue and there was no error message or similar to indicate the cause of the issue, which resulted in some time spent debugging until I figured out the cause. Kind regards, Marian On 23 October 2021 14:19:22 CEST, "Matthias B." <mat...@po...> wrote: >Hi, > >I had problems with flash programming with my old MKII and therefore >bought a new Atmel-ICE. >My PC is running on linux and I can use this new debugger with your >version Version 6.3-20171130 for programming but somehow not for debugging. > >So at the moment I can use my mkII for debugging and the Atmel-ICE for >programming - it's somehow weird and I need to solve this problem for >the Atmel-ICE ;-) > >For the MKII I use the sequence > * avarice --jtag usb --mkII :4242* >and was afterwards able to start debugging via eclipse. Very simple. > >If I adapt this sequence for the new debugger > *avarice --jtag usb --edbg :4242* >just nothing happens, which means the output is > * AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28** >** Defaulting JTAG bitrate to 250 kHz.* >and it ends. > >I read (https://sourceforge.net/p/avarice/bugs/29/ , Joerg Wunsch) I >might have to use this out of a gdb session like > *gdb avrice* >and then > *(gdb) run -1 -j usb :4242 >*the output is* > Starting program: /usr/local/bin/avarice -1 -j usb :4242 > [Thread debugging using libthread_db enabled] > Using host libthread_db library >"/lib/x86_64-linux-gnu/libthread_db.so.1". > AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 > Defaulting JTAG bitrate to 250 kHz. > did not find any USB device "usb" > [Inferior 1 (process 260701) exited with code 01] >*Looking up the atmel-ice usb device: > *(gdb) run -1 -j /dev/bus/usb/001/048 :4242** >*the output is* > Starting program: /usr/local/bin/avarice -1 -j >/dev/bus/usb/001/048 :4242 > [Thread debugging using libthread_db enabled] > Using host libthread_db library >"/lib/x86_64-linux-gnu/libthread_db.so.1". > AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 > Defaulting JTAG bitrate to 250 kHz. > [Inferior 1 (process 260758) exited with code 01] > >*So in summary I got stuck somehow and don't really know how to go on. >Can someone point me into the right direction how to initiate a debug >session with avarice and the Atmel-ICE? > >Kind regards, >Matthias >** > -- Via smartphone. |
From: Matthias B. <mat...@po...> - 2021-10-23 12:19:34
|
Hi, I had problems with flash programming with my old MKII and therefore bought a new Atmel-ICE. My PC is running on linux and I can use this new debugger with your version Version 6.3-20171130 for programming but somehow not for debugging. So at the moment I can use my mkII for debugging and the Atmel-ICE for programming - it's somehow weird and I need to solve this problem for the Atmel-ICE ;-) For the MKII I use the sequence * avarice --jtag usb --mkII :4242* and was afterwards able to start debugging via eclipse. Very simple. If I adapt this sequence for the new debugger *avarice --jtag usb --edbg :4242* just nothing happens, which means the output is * AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28** ** Defaulting JTAG bitrate to 250 kHz.* and it ends. I read (https://sourceforge.net/p/avarice/bugs/29/ , Joerg Wunsch) I might have to use this out of a gdb session like *gdb avrice* and then *(gdb) run -1 -j usb :4242 *the output is* Starting program: /usr/local/bin/avarice -1 -j usb :4242 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 Defaulting JTAG bitrate to 250 kHz. did not find any USB device "usb" [Inferior 1 (process 260701) exited with code 01] *Looking up the atmel-ice usb device: *(gdb) run -1 -j /dev/bus/usb/001/048 :4242** *the output is* Starting program: /usr/local/bin/avarice -1 -j /dev/bus/usb/001/048 :4242 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". AVaRICE version 2.14svn20200906, Sep 28 2021 21:09:28 Defaulting JTAG bitrate to 250 kHz. [Inferior 1 (process 260758) exited with code 01] *So in summary I got stuck somehow and don't really know how to go on. Can someone point me into the right direction how to initiate a debug session with avarice and the Atmel-ICE? Kind regards, Matthias ** |
From: Joerg W. <j...@ur...> - 2021-06-26 20:52:02
|
As Istvan Retaller wrote: > > /usr/bin/avr-objcopy -j .text \ -j .data > > \ -O ihex testburst.out testburst.hex /usr/bin/avrdude -F -c jtag2isp > > -P usb -B 10 -b 115200 -p t45 -e -U flash:w:testburst.hex -U > lfuse:w:0x62:m -U hfuse:w:0x9f:m -U efuse:w:0xff:m avrdude: Only as a side note: you can do all of this straight from the ELF file, no need to objcopy into an Intel hex file. As another side note, since you are already in debugWIRE mode: fuses cannot be programmed at all in this mode. (Technically, debugWIRE is a kind of ROM-based monitor program, so it can only access those resources the CPU can reach. Fuses and lock bits don't belong to that.) In your case, the fuse "programming" just passes since they are not changed at all. > *I start avr-gdb in a new terminal** > **The gdbinit content is_as follows:* > /target remote localhost:4242// > //break main// > //continue/ Well, for a first test, you'd better leave out the gdbinit file. > Pressing ^C I get a prompt and now gdb accepts commands. > However I do not know how got to this point and what was done to get there. > > > > Program received signal SIGINT, Interrupt. 0x00000194 in __vector_3 () > > at testburst.c:122 122 } (gdb) Your gdbinit doesn't only attach to AVaRICE, but sets a breakpoint on main and tries proceeding there. As that breakpoint is never reached, you have to manually stop it with ^C, and then it is presumably inside the timer 1 compare A interrupt vector. Something appears to not really match here: if main() really hasn't ever been reached, how would interrupts become enabled so it could hit an ISR? Maybe the actual flashing by AVRDUDE didn't work, so you are debugging an entirely different firmware? What you could try: target remote :4242 display/i $pc then repeatedly use the si (step CPU instruction) command, and watch the CPU instructions passing by, comparing them with you disassemble file. Also, you could use the "disas" GDB instruction, or "x" the hexdump the flash contents, and compare it to what you think ought to be there. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Istvan R. <ret...@gm...> - 2021-06-26 15:31:40
|
Hi all, here is a weird thing I cannot overcome: avr-gdb connects, but there is no prompt. Pressing ^C I get a prompt and now gdb accepts commands. However I do not know how got to this point and what was done to get there.Here is what I do: *steve@Apa:~/projects/avr/testburst$ make* /usr/bin/avr-gcc -D F_CPU=8000000 -I. -ggdb -mmcu=attiny45 -Os -fpack-struct -fshort-enums -gdwarf-2 -std=gnu99 -funsigned-bitfields -funsigned-char -Wall -Wstrict-prototypes -Wa,-ahlms=testburst.lst -c testburst.c -o testburst.o /usr/bin/avr-gcc -D F_CPU=8000000 -Wl,--no-undefined,-Map,testburst.out.map -mmcu=attiny45 -L -lm -o testburst.out testburst.o *Flash program and enable debugwire:* *steve@Apa:~/projects/avr/testburst$ make dwflash* > /usr/bin/avr-objcopy -j .text \ -j .data > \ -O ihex testburst.out testburst.hex /usr/bin/avrdude -F -c jtag2isp > -P usb -B 10 -b 115200 -p t45 -e -U flash:w:testburst.hex -U lfuse:w:0x62:m -U hfuse:w:0x9f:m -U efuse:w:0xff:m avrdude: > jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED > avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire > avrdude: Target prepared for ISP, signed off. avrdude: Now retrying > without power-cycling the target. > > avrdude: AVR device initialized and ready to accept instructions > > Reading | ################################################## | 100% > 0.02s > > avrdude: Device signature = 0x1e9206 (probably t45) avrdude: erasing > chip avrdude: reading input file "testburst.hex" avrdude: input file > testburst.hex auto detected as Intel Hex avrdude: writing flash (482 > bytes): > > Writing | ################################################## | 100% > 0.30s > > avrdude: 482 bytes of flash written avrdude: verifying flash memory > against testburst.hex: avrdude: load data flash data from input file > testburst.hex: avrdude: input file testburst.hex auto detected as > Intel Hex avrdude: input file testburst.hex contains 482 bytes > avrdude: reading on-chip flash data: > > Reading | ################################################## | 100% > 0.31s > > avrdude: verifying ... avrdude: 482 bytes of flash verified avrdude: > reading input file "0x62" avrdude: writing lfuse (1 bytes): > > Writing | ################################################## | 100% > 0.02s > > avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory > against 0x62: avrdude: load data lfuse data from input file 0x62: > avrdude: input file 0x62 contains 1 bytes avrdude: reading on-chip > lfuse data: > > Reading | ################################################## | 100% > 0.01s > > avrdude: verifying ... avrdude: 1 bytes of lfuse verified avrdude: > reading input file "0x9f" avrdude: writing hfuse (1 bytes): > > Writing | ################################################## | 100% > 0.02s > > avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory > against 0x9f: avrdude: load data hfuse data from input file 0x9f: > avrdude: input file 0x9f contains 1 bytes avrdude: reading on-chip > hfuse data: > > Reading | ################################################## | 100% > 0.01s > > avrdude: verifying ... avrdude: 1 bytes of hfuse verified avrdude: > reading input file "0xff" avrdude: writing efuse (1 bytes): > > Writing | ################################################## | 100% > 0.02s > > avrdude: 1 bytes of efuse written avrdude: verifying efuse memory > against 0xff: avrdude: load data efuse data from input file 0xff: > avrdude: input file 0xff contains 1 bytes avrdude: reading on-chip > efuse data: > > Reading | ################################################## | 100% > 0.01s > > avrdude: verifying ... avrdude: 1 bytes of efuse verified > > avrdude: safemode: Fuses OK (E:FF, H:9F, L:62) > > avrdude done. Thank you. *Trying debug* *steve@Apa:~/projects/avr/testburst$ avarice -w -P attiny45 --jtag usb:24cf --mkII :4242 &* > AVaRICE version 2.14, Sep 17 2020 16:15:33 > > JTAG config starting. Found a device: JTAGICEmkII Serial number: > 00:b0:00:00:24:cf Reported debugWire device ID: 0x9206 Configured for > device ID: 0x9206 attiny45 -- Matched with attiny45 JTAG config > complete. Preparing the target device for On Chip Debugging. Waiting > for connection on port 4242. *I start avr-gdb in a new terminal** **The gdbinit content is_as follows:* /target remote localhost:4242// //break main// //continue/ *steve@Apa:~/projects/avr/testburst$ avr-gdb testburst.out -x gdbinit* > GNU gdb (GDB) 10.1.90.20210103-git Copyright (C) 2021 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-linux-gnu --target=avr". > Type "show configuration" for configuration details. For bug reporting > instructions, please see: <https://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 testburst.out... 0x00000000 > in __vectors () Breakpoint 1 at 0x198: file testburst.c, line 62. > Note: automatically using hardware breakpoints for read-only > addresses. *At this point I get no gdb prompt, commands are not accepted.** **c** **n** **^C* Pressing ^C I get a prompt and now gdb accepts commands. However I do not know how got to this point and what was done to get there. > Program received signal SIGINT, Interrupt. 0x00000194 in __vector_3 () > at testburst.c:122 122 } (gdb) What is wrong? |
From: Joerg W. <j...@ur...> - 2020-09-05 21:57:44
|
Hello * this is just to inform you that I finally rolled a new release of AVaRICE, 2.14. Not much has been done to the code base during the recent four (or so) years, unfortunately. I've never been fully confident with the state of EDBG handling (i.e., Atmel-ICE and the EDBG versions found on a number of demo boards by Atmel/Microchip). The code handling it (activated by option "-4", as it logically succeeds the earlier JTAGICE3 protocol, even though JTAGICE3 now also runs EDBG protocol) has always been a bit fragile to me. However, changing this requires so much reorganization of the code, I never found the time and energy for that. I also contemplated moving everything to OpenOCD (which seems to be able to handle the Atmel-ICE flawlessly for Cortex-M devices), but adding the AVR debugging support there is likely going to be not less work. So here we are now, EDBG is at the very least there (and has been in the tree for many years now). I picked all the patches and bug reports from the respective trackers that could be applied without risking any breakage or incompatibilities. Thanks to everyone involved there, this is much appreciated! I'm particularly happy to see some documentation updates that came in - an area that is often neglected a bit. So enjoy, I'm sorry I did not find time to make more improvements, but I hope the new release will be quite an improvement to many AVR developers anyway. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Andrew B. <pro...@gm...> - 2020-08-17 16:40:59
|
Hi, Just wanted to say a big thank you to everyone involved in this awesome project and it's more recent revival! Thanks to you (and other online resources), I'm currently debugging an Atmega1284p via JTAG with my Atmel ICE using AVaRICE and GDB in PlatformIO (in Visual Studio Code) - see this screenshot. Debugging the Atmega1284p in PlatformIO <https://prominimicros.com/wp-content/uploads/2020/08/PlatformIO-Debugging-the-Atmega1284p-Show-GDB-Version.jpg> and this is my setup (Atmel ICE underneath a similarly-sized breakout board <https://jacoburge.co.uk/atmel-ice-breakout>): JTAG Debugging the Atmega1284p with an Atmel ICE <https://prominimicros.com/wp-content/uploads/2020/08/JTAG-Debugging-the-Atmega1284p-with-an-Atmel-ICE.jpg> Following various people's advice, I was able to compile the r375 code in a Cygwin environment (which was lots of... er... "fun" to set up and get working..!) I hacked some bits of the code to get programming/verifying working so I could upload and set fuses, etc. - using the bits from the jtag2 source seemed to work fine for me. Uploading to the Atmega1284p via JTAG using AVaRICE <https://prominimicros.com/wp-content/uploads/2020/08/PlatformIO-Uploading-to-the-Atmega1284p.jpg> This meant I didn't need to use Zadig or libusb filters or anything like that, I could use the same tool (AVaRICE) to upload, set fuses and debug. I also ended up recompiling the latest GDB (9.2 right now) since the one in my version of PlatformIO didn't support XML memory maps. I did need to manually fix this bug <https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=13519> to make it disassemble the code at the correct address, but that wasn't too much hassle. So, in short: Thank you! And, is there anything I can do to help? I'm very much still learning about all things JTAG debugging and GDB, etc. But if there's anything I could do/try/write-up, just let me know. Thanks! Andy |
From: Joerg W. <j...@ur...> - 2019-11-13 10:44:50
|
As Marian Buschsieweke wrote: > the SVN server is now again operational. Confirmed (as well as the outage before). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Marian B. <mar...@ov...> - 2019-11-13 10:19:40
|
Hi, the SVN server is now again operational. Kind regards, Marian On Wed, 13 Nov 2019 10:29:21 +0100 Marian Buschsieweke <mar...@ov...> wrote: > Hi, > > currently the SVN repo can not be reached. > > > svn: E170013: Unable to connect to a repository at URL 'http://svn.code.sf.net/p/avarice/code/trunk' > > svn: E175002: Unexpected HTTP status 503 'Service Unavailable' on '/p/avarice/code/trunk' > > > Is this just a technical issue? Is there an official mirror of the code? > > Maybe this is a good time to suggested moving the code away from sourceforge, > which has basically become the graveyard of dead open source projects? > > Some alternatives (from more open to less open, from less users to more > users): > > - https://codeberg.org/ > - https://about.gitlab.com/ > - https://github.com/ > > Kind regards, > Marian |
From: Marian B. <mar...@ov...> - 2019-11-13 09:29:33
|
Hi, currently the SVN repo can not be reached. > svn: E170013: Unable to connect to a repository at URL 'http://svn.code.sf.net/p/avarice/code/trunk' > svn: E175002: Unexpected HTTP status 503 'Service Unavailable' on '/p/avarice/code/trunk' Is this just a technical issue? Is there an official mirror of the code? Maybe this is a good time to suggested moving the code away from sourceforge, which has basically become the graveyard of dead open source projects? Some alternatives (from more open to less open, from less users to more users): - https://codeberg.org/ - https://about.gitlab.com/ - https://github.com/ Kind regards, Marian |
From: Joerg W. <j...@ur...> - 2018-12-07 06:20:00
|
As Vasily Kartashov wrote: > Interestingly, when I try to connect to ATMEL-ICE through hidapi > testgui I consistently get “Unable To Connect to Device”. That probably explains it. In that case, it's out of AVaRICE's scope - if it doesn't see a HID it cannot do anything. Try debugging it using a syscall tracer on your OS (e.g. strace on Linux). I just tested it here on my FreeBSD: % ./src/avarice --edbg --debugwire --ignore-intr :4242 AVaRICE version 2.13svn20160229, Oct 28 2018 22:29:00 JTAG config starting. Found a device, serial number: J41800000136 initJtagBox() failed: No target power present j@uriah 77% ./src/avarice --edbg --debugwire --ignore-intr --debug :4242 AVaRICE version 2.13svn20160229, Oct 28 2018 22:29:00 Found HID PID:VID 0x03eb:0x2141, serno J41800000136 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 34 31 38 30 30 30 30 30 31 33 36 Got message seqno 1 (command_sequence == 1) response: 00 81 00 4A 34 31 38 30 30 30 30 30 31 33 36 Found a device, serial number: J41800000136 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 16 41 00 00 Got message seqno 2 (command_sequence == 2) response: 01 84 01 00 01 16 41 00 00 ICE hardware version: 0 ICE firmware version: 1.22 (rel. 65) 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 0x07 0x0e 0x06 read: 0e 06 00 12 a0 00 22 Got message seqno 6 (command_sequence == 6) response: 12 A0 00 22 initJtagBox() failed: No target power present command "sign-off" [0x01, 0x11] 0E 00 07 00 01 11 00 Received 0x81 0x11 0x00 0x06 0x0e 0x07 read: 0e 07 00 01 80 00 Got message seqno 7 (command_sequence == 7) response: 01 80 00 I don't have a target handy to really test debugging, so "No target power present" is expected. Still, I think this is going way past what you are seeing. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Vasily K. <in...@ka...> - 2018-12-07 00:24:34
|
Hi Fabian, Yep. And I tried it both on Mac OS X and Fedora to the same effect. Interestingly, when I try to connect to ATMEL-ICE through hidapi testgui I consistently get “Unable To Connect to Device”. > On 7 Dec 2018, at 9:51 am, Fabian Bläse <fa...@bl...> wrote: > > Hi, > > do you have libhidapi installed? > If I remember correctly AVaRICE did not output an error message, when I didn't have it installed. > > Fabian > > On 06.12.18 13:48, Vasily Kartashov wrote: >> Hello, >> >> When compiling and executing latest code from trunk I get the following: >> >> ➜ Arduino avarice --edbg --debugwire --ignore-intr :4242 >> AVaRICE version 2.13svn20160229, Dec 6 2018 16:53:24 >> >> and then the program exits. >> >> Any ideas? >> >> Thanks, >> V. >> >> _______________________________________________ >> avarice-user mailing list >> ava...@li... >> https://lists.sourceforge.net/lists/listinfo/avarice-user >> > |
From: Fabian B. <fa...@bl...> - 2018-12-06 23:11:15
|
Hi, do you have libhidapi installed? If I remember correctly AVaRICE did not output an error message, when I didn't have it installed. Fabian On 06.12.18 13:48, Vasily Kartashov wrote: > Hello, > > When compiling and executing latest code from trunk I get the following: > > ➜ Arduino avarice --edbg --debugwire --ignore-intr :4242 > AVaRICE version 2.13svn20160229, Dec 6 2018 16:53:24 > > and then the program exits. > > Any ideas? > > Thanks, > V. > > _______________________________________________ > avarice-user mailing list > ava...@li... > https://lists.sourceforge.net/lists/listinfo/avarice-user > |
From: Vasily K. <in...@ka...> - 2018-12-06 13:03:59
|
Hello, When compiling and executing latest code from trunk I get the following: ➜ Arduino avarice --edbg --debugwire --ignore-intr :4242 AVaRICE version 2.13svn20160229, Dec 6 2018 16:53:24 and then the program exits. Any ideas? Thanks, V. |
From: Joerg W. <j...@ur...> - 2018-10-15 21:49:08
|
As Fabian Bläse via avarice-user wrote: > > As far as I can tell, ucAllowFullPageBitstream is a bit that must only > > be set for JTAG debugging on very old devices (ATmega16, ATmega128 > > etc.). > This value is not listed in Atmels EDBG documentation for debugWIRE > targets [1], so I'm not shure if this value is used. Setting > Breakpoints did work regardless of this value, if I remember > correctly. It is probably simply ignored. Anyway, to keep the actual diff minimal, I removed that change, and then, extended the respective changes to the entire families affected (ATtiny24, ATtiny44, ATtiny84, ATmega48P, ATmega88P, ATmega168P, ATmega328P). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Fabian B. <fa...@bl...> - 2018-09-28 12:54:19
|
Hi Joerg, sorry for the late reply.. It has been a busy week. On 20.09.18 14:08, Joerg Wunsch wrote: > > Basically OK, but: > >> @@ -4132,7 +4132,7 @@ jtag_device_def_type deviceDefinitions[] = { >> fill_b2(32768 / 128), // uiFlashpages >> 0x31, // ucDWDRAddress >> 0x00, // ucDWBasePC >> - 0x00, // ucAllowFullPageBitstream >> + 0x01, // ucAllowFullPageBitstream >> fill_b2(0x3F00), // uiStartSmallestBootLoaderSection >> 1, // EnablePageProgramming >> 0, // ucCacheType > > Are you totally sure about this one? > > As far as I can tell, ucAllowFullPageBitstream is a bit that must only > be set for JTAG debugging on very old devices (ATmega16, ATmega128 > etc.). This value is not listed in Atmels EDBG documentation for debugWIRE targets [1], so I'm not shure if this value is used. Setting Breakpoints did work regardless of this value, if I remember correctly. I captured Atmel Studios behaviour via usbmon, with which this byte was set to 0x01. However the target has been the Xplained Mini with an ATmega328PB on it, so it might be specific for this combination. I'm going to try it with the JTAGICE3 and an ATmega328P next week, if I have the time. Best regards Fabian [1] https://www.microchip.com/webdoc/protocoldocs/section_avr8_setget_params.html#N11DCA |
From: Joerg W. <j...@ur...> - 2018-09-20 12:08:39
|
As Fabian Bläse via avarice-user wrote: > Because of wrong values for SPMCR and IDR adresses, > the debugger is unable to write software breakpoints into flash. Basically OK, but: > @@ -4132,7 +4132,7 @@ jtag_device_def_type deviceDefinitions[] = { > fill_b2(32768 / 128), // uiFlashpages > 0x31, // ucDWDRAddress > 0x00, // ucDWBasePC > - 0x00, // ucAllowFullPageBitstream > + 0x01, // ucAllowFullPageBitstream > fill_b2(0x3F00), // uiStartSmallestBootLoaderSection > 1, // EnablePageProgramming > 0, // ucCacheType Are you totally sure about this one? As far as I can tell, ucAllowFullPageBitstream is a bit that must only be set for JTAG debugging on very old devices (ATmega16, ATmega128 etc.). -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) |
From: Fabian B. <fa...@bl...> - 2018-09-20 10:44:52
|
Because of wrong values for SPMCR and IDR adresses, the debugger is unable to write software breakpoints into flash. The attached patch fixes those values based on Atmel Studios behavior for ATmega328p and ATtiny24. |
From: Joerg W. <j...@ur...> - 2018-07-12 20:55:33
|
As Marian Buschsieweke wrote: > first: Thank you for your contribution to AVaRICE and maintaining it. It seems > you took offense in my previous email, which was never my intention. I'm sorry > for that. No offense taken, not at all. > As you said, AVaRICE would greatly profit from attracting new contributors. In > order to increase the chance that other contribute the choice of a hosting > platform (and also VCS, as you brought that up) can have a huge impact. According to > 25 years of opensource contributions by myself, I don't think just changing the environment would get anyone to step forward. People only come by if 1) they really need any particular feature in a certain software, and 2) they have the time and skills to do so. Once someone is there who really wants to dedicate the required time for maintenance, migrating to some different environment could certainly be arranged. > Regarding the search of a new maintainer of AVaRICE you mentioned: Maybe the > OpenOCD guys are willing to adopt AVaRICE? As someone who contributed minor additions to OpenOCD as well: I don't think there's anyone around in the OpenOCD community interested and knowledgable about AVRs. It would certainly be interesting to migrate the AVR debugging part there, as they've got a good and versatile framework for many different platforms. I already contemplated to at least handle the AtmelICE + EDBG part there (as these tools are already working well on OpenOCD for ARM targets, so the part that is currently not working well in AVaRICE is already available there), and then just keep AVaRICE as it is for the historic JTAGICE, JTAGICEmkII, AVR Dragon, and JTAGICE3 (early firmware) where it works well enough. However, see my previous mail: I lack the time for it (and partly now also the motivation). > However, I am willing to contribute any bugfix and > improvement that I program in order to keep AVaRICE running for the OCD of the > platforms I'm working with. Maybe, if others do the same those minor > contributions add up. Surely, minor contributions like that are always welcome, but they do not solve the major headache I currently have about handling the AtmelICE & co. -- 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-12 16:27:38
|
Dear Jörg Wunsch, first: Thank you for your contribution to AVaRICE and maintaining it. It seems you took offense in my previous email, which was never my intention. I'm sorry for that. A new release would be greatly appreciated. The one-liner patch I posted does not apply to the current SVN head and the bug is already fixed there. So a new release would solve that issue and other issues and I would be really grateful for that. I still believe I have a point in both suggestions (Fixing indentation by running astyle/uncrustify/clang-format/... and moving AVaRICE to a different code hosting platform). Let me elaborate on why the code hosting platform is more relevant than it seems: As you said, AVaRICE would greatly profit from attracting new contributors. In order to increase the chance that other contribute the choice of a hosting platform (and also VCS, as you brought that up) can have a huge impact. E.g. let's assume AVaRICE would move to GitHub: - About 6.5 times more coders already have an account there [1], so it's more likely that they stumble upon AVaRICE by chance and end up using it and hopefully contributing to it - Most of the computer science students that attend one of our courses already have experience in using git, but few have experience using subversion - The effort to contribute is quite low on platforms like GitHub, GitLab, ... - Also, the effort to maintain is quite low on those platforms and the burden of maintenance can be distributed Summing up: The project would be more public and visible, so that more people get the chance to contribute. Also, the bar to contribute would be significantly lowered, as potential contributors are more likely to already know the tools and the process of contribution is more streamlined there. So while changing the code hosting platform does not address any of the actual issues, it might lead to others contributing important improvements. Regarding the search of a new maintainer of AVaRICE you mentioned: Maybe the OpenOCD guys are willing to adopt AVaRICE? They would have the expertise required to maintain it. Also maybe integrating the code of AVaRICE into OpenOCD could be an interesting long term goal, which would solve the problem of too few active contributors, as OpenOCD seem to have an active community. (And OpenOCD is hosted on SourceForge, so no code migration would be required.) Another suggestion regarding the maintainer is to ask big users of AVaRICE. E.g. RIOT OS is using it to debug the Arduino Mega 2560. They might not have the same expertise regarding debuggers as OpenOCD (as their main competence is writing an IoT operating system), but they certainly have the infrastructure and expertise required for maintaining open source projects. And for users of AVaRICE (RIOT OS or others) have a natural interest in keeping AVaRICE running. I'm really interested in having an open source tool for OCD of AVR MCUs. Sadly, I neither have the expertise regarding debuggers nor the time to provide significant contributions. However, I am willing to contribute any bugfix and improvement that I program in order to keep AVaRICE running for the OCD of the platforms I'm working with. Maybe, if others do the same those minor contributions add up. Kind regards, Marian [1]: https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Popularity ------------------------------------------------------------- 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 ------------------------------------------------------------- On Tue, 10 Jul 2018 22:08:46 +0200 Joerg Wunsch <j...@ur...> wrote: > As Marian Buschsieweke wrote: > > > My point is: SourceForge.net is a platform that really scares me away from > > an open source project, no matter how cool it is. Other coders and potential > > contributors may feel the same way about it. Maybe with teahub.io a good > > alternative will (hopefully) emerge some day in the (hopefully) not too > > distant future. Maybe that is worth for AVaRICE to look into, when it > > becomes available? > > Seriously, AVaRICE has bigger problems but its hosting platform or > indentation style (or VCS, in case anyone's asking for Git now ...). > Sourceforge hasn't been my decision, I merely inherited the project > that way, but for just distributing the software, it doesn't matter > much anyway which platform it is lying on. > > So far, there are *zero* active developers, plus a number of things > that require a rewrite of larger portions of the code. Namely, the > entire handling of the AtmelICE (and JTAGICE-3 in HID mode, as well as > all the embedded debuggers of the various Xplained boards) is just > alpha quality, and could be considered flakey at best. This is way > more important than stylistic things (as important as they might be to > you personally), because it affects the core functionality of the tool > for the only existing current Atmel debugging hardware. > > I don't have the time to do anything on it, sorry. I can probably > merge the current patch (which is a trivial one), and I could also be > willing to just roll out a new release if needed, but that's it. > > If there's anyone going to jump in, who wants to *seriously* (and > long-term) maintain AVaRICE, it would be their decision where to host > the project (or just keep it on SF.net). They are then also free to > migrate to the VCS they feel most comfortable with, and to fix > stylistic issues. |
From: Joerg W. <j...@ur...> - 2018-07-10 20:08:56
|
As Marian Buschsieweke wrote: > My point is: SourceForge.net is a platform that really scares me away from an > open source project, no matter how cool it is. Other coders and potential > contributors may feel the same way about it. Maybe with teahub.io a good > alternative will (hopefully) emerge some day in the (hopefully) not too distant > future. Maybe that is worth for AVaRICE to look into, when it becomes available? Seriously, AVaRICE has bigger problems but its hosting platform or indentation style (or VCS, in case anyone's asking for Git now ...). Sourceforge hasn't been my decision, I merely inherited the project that way, but for just distributing the software, it doesn't matter much anyway which platform it is lying on. So far, there are *zero* active developers, plus a number of things that require a rewrite of larger portions of the code. Namely, the entire handling of the AtmelICE (and JTAGICE-3 in HID mode, as well as all the embedded debuggers of the various Xplained boards) is just alpha quality, and could be considered flakey at best. This is way more important than stylistic things (as important as they might be to you personally), because it affects the core functionality of the tool for the only existing current Atmel debugging hardware. I don't have the time to do anything on it, sorry. I can probably merge the current patch (which is a trivial one), and I could also be willing to just roll out a new release if needed, but that's it. If there's anyone going to jump in, who wants to *seriously* (and long-term) maintain AVaRICE, it would be their decision where to host the project (or just keep it on SF.net). They are then also free to migrate to the VCS they feel most comfortable with, and to fix stylistic issues. -- 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 16:04:32
|
Dear Jörg Wunsch, thanks for the quick reply. > See bug report #24 (filed just recently) Actually I had a look into the bug tracker and before writing the email and couldn't find it. I also wanted to add a bug, but I really don't want to create an account on SourceForge. Every time I click on something there a huge "we value your privacy" banner is jumping in my face. And I only need to click on "More Options" to see the provide that this is a lie... My point is: SourceForge.net is a platform that really scares me away from an open source project, no matter how cool it is. Other coders and potential contributors may feel the same way about it. Maybe with teahub.io a good alternative will (hopefully) emerge some day in the (hopefully) not too distant future. Maybe that is worth for AVaRICE to look into, when it becomes available? > Changing whitespace just for the purpose of changing it is generally > not a good idea. It potentially obfuscates real code changes later on. (Sorry for writing a quite emotional rant about it, but inconsistent indent is one of my pet peeves:) I cannot disagree more on that. I see a VCS log as a tool to tweak the code - not writing code as a tool to tweak the VCS log. Inconsistent coding style makes reading and understanding the code harder. It increases the barrier to get other people to contribute code and identifying bugs harder. E.g. the CVE-2013-1266 (a.k.a. goto fail) [1] would most likely be detected sooner when correct code indentation would have been used. This even lead to the new "-Wmisleading-indentation" warning option in GCC [2]. So getting code indentation consistent (no matter if you prefer tabs, spaces or smart tabs) has a huge impact on code quality, even if this only changes white space. Kind regards, Marian Buschsieweke [1]: https://nvd.nist.gov/vuln/detail/CVE-2014-1266 [2]: https://developers.redhat.com/blog/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/ ------------------------------------------------------------- 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 ------------------------------------------------------------- On Tue, 10 Jul 2018 12:21:58 +0200 Joerg Wunsch <j...@ur...> wrote: > 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. |