Replies: 6 comments 1 reply
-
Sorry, long time no reply from me. Did you solve some of the problems? I am currently working againon dw-link. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I haven't worked on dwlink/AVR for a while either as I was so stumped by
it's sudden failure - I kind of gave up on the whole thing.
The hardware has been stored in a box since then if you're wanting test
results, etc. Happy to help in that regard, and if we're productive, I'm
eager to get back into it.
surge
…On Sat, 28 Dec 2024 at 18:09, Bernhard ***@***.***> wrote:
Sorry, long time no reply from me. Did you solve some of the problems? I
am currently working againon dw-link.
—
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACRCWNDHNI5VHLZ2VZUVX6L2HZISBAVCNFSM6AAAAABNNUSY32VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRYGMZTEOA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Berhard,
I will try your suggestions shortly, thanks.
One thing I was particularly suspicious of is the version of avr-gdb I'm
using as I seem to remember when I was setting it up that some (one?)
versions didn't work. Can I ask what version you use/know for sure works?
I have tried so many different versions I forgot what I had when it was
working!
Viel spass,
surge
…On Thu, 27 Feb 2025 at 01:33, Bernhard ***@***.***> wrote:
Hi surge,
currently, I am into the 'software' side again and program a Python script
that interfaces with all the EDBG-based Microchip debuggers. It is already
quite stable and has been tested with a large number of debugWIRE MCUs and
different debuggers. One of them sticks out: MPLAB SNAP is a hardware
debugger you can get for $15 at, e.g., DigiKey. The only problem is that it
seems to be sold out almost everywhere. BTW: If you have Python 3.9 or more
recent, you can install the script with pipx install dwgdbserver.
Coming back to your questions:
1. Could you try it with the new version of dw-link?
2. Leave out the transistor and source the ATtiny externally. The
debugger will then ask you to power-cycle manually.
Ah, and a suggestion: Buy a cheap Logic Analyzer. They are called
something like "Logic Analyzer, 8 Channel, 24MHz" and cost less than $20.
You can use the Saleae software or sigrok/pulseview to view the signals.
Without an LA, I would not have been able to build the debugger.
Cheers
Bernhard
—
Reply to this email directly, view it on GitHub
<#14 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACRCWNGXFEEEUHTERW6YFJT2RXJUPAVCNFSM6AAAAABNNUSY32VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZSG4YTIOI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
So far, I had only problems with pre-10.1. And this was only in connection with extended-remote.Best,BernhardVon meinem iPhone gesendetAm 26.02.2025 um 22:55 schrieb surge9000 ***@***.***>:
Hi Berhard,
I will try your suggestions shortly, thanks.
One thing I was particularly suspicious of is the version of avr-gdb I'm
using as I seem to remember when I was setting it up that some (one?)
versions didn't work. Can I ask what version you use/know for sure works?
I have tried so many different versions I forgot what I had when it was
working!
Viel spass,
surge
On Thu, 27 Feb 2025 at 01:33, Bernhard ***@***.***> wrote:
Hi surge,
currently, I am into the 'software' side again and program a Python script
that interfaces with all the EDBG-based Microchip debuggers. It is already
quite stable and has been tested with a large number of debugWIRE MCUs and
different debuggers. One of them sticks out: MPLAB SNAP is a hardware
debugger you can get for $15 at, e.g., DigiKey. The only problem is that it
seems to be sold out almost everywhere. BTW: If you have Python 3.9 or more
recent, you can install the script with pipx install dwgdbserver.
Coming back to your questions:
1. Could you try it with the new version of dw-link?
2. Leave out the transistor and source the ATtiny externally. The
debugger will then ask you to power-cycle manually.
Ah, and a suggestion: Buy a cheap Logic Analyzer. They are called
something like "Logic Analyzer, 8 Channel, 24MHz" and cost less than $20.
You can use the Saleae software or sigrok/pulseview to view the signals.
Without an LA, I would not have been able to build the debugger.
Cheers
Bernhard
—
Reply to this email directly, view it on GitHub
<#14 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACRCWNGXFEEEUHTERW6YFJT2RXJUPAVCNFSM6AAAAABNNUSY32VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZSG4YTIOI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Bernhard,
Here's an update:
I rebuilt the target circuit as specified for breadboard in the
quick start guide thus removing the PNP transistor.
I updated to version dw-link version 4.5.0.
In both cases it's still blinking the system led indicating an error
and `monitor lasterror` returns 1, but with the new version, the warning
is different:
avr-gdb -b 115200 -ex "target remote /dev/ttyACM0" Fade_attiny85.elf
GNU gdb (GDB) 11.2
Copyright (C) 2022 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://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 Fade_attiny85.elf...
Remote debugging using /dev/ttyACM0
warning: unrecognized item
"O2a2a2a43616e6e6f7420636f6e6e6563743a20436f756c64206e6f7420636f6d6d756e6963617465206279204953503b20636865636b20776972696e672a2a2a0A"
in "qSupported" response
0x00000000 in __vectors ()
(gdb) monitor lasterror
Last fatal error: 1
(gdb)
I still need to do some other tests as these attiny chips have been
sitting around gathering dust too, but maybe this new warning is
informative somehow?
While I was at it, I made a patch against 4.5.0 that fixes a few
things, see below. It includes my pin configurations so that you can check
there are no conflicts with other features I'm not using. I note
there could be a situation that damages the ATmega328/controller chip.
e.g. setting LEDGND to the same pin as some of the others that are set
high could result in overcurrent on the pin. (I recommend removing LEDGND
actually - there are plenty of grounds on arduino boards).
You'll want to remove/restore these before putting it into production.
Please note, as I obviously can't test these changes yet, you'll need
to.
Notes for diff:
-Bug for STUCKAT1PC #define fixed.
-Added PNPSUPPLY #define for PNP power supply transistor option.
-Fixed many warnings. Also, use -Wall for production code! C/C++ and
especially arduino have very poor typeing.
Please check the remaining warning in gdbParseMonitorPacket() as I
wasn't sure of the intention in the code. This could be responsible
for seemingly nonsense warnings?
Lastly, I've ordered a thing called a "Bus Pirate". I heard they're
pretty good at logic analysing but it will take several weeks to arrive.
It does defeat the whole point of this as dw-link was supposed to be a
way to get an attiny debugger without spending any money! I'll probably
find a use for it in other projects later though.
surge
…On Thu, 27 Feb 2025 at 20:23, Bernhard ***@***.***> wrote:
So far, I had only problems with pre-10.1. And this was only in connection with extended-remote.Best,BernhardVon meinem iPhone gesendetAm 26.02.2025 um 22:55 schrieb surge9000 ***@***.***>:
Hi Berhard,
I will try your suggestions shortly, thanks.
One thing I was particularly suspicious of is the version of avr-gdb I'm
using as I seem to remember when I was setting it up that some (one?)
versions didn't work. Can I ask what version you use/know for sure works?
I have tried so many different versions I forgot what I had when it was
working!
Viel spass,
surge
On Thu, 27 Feb 2025 at 01:33, Bernhard ***@***.***> wrote:
> Hi surge,
>
> currently, I am into the 'software' side again and program a Python script
> that interfaces with all the EDBG-based Microchip debuggers. It is already
> quite stable and has been tested with a large number of debugWIRE MCUs and
> different debuggers. One of them sticks out: MPLAB SNAP is a hardware
> debugger you can get for $15 at, e.g., DigiKey. The only problem is that it
> seems to be sold out almost everywhere. BTW: If you have Python 3.9 or more
> recent, you can install the script with pipx install dwgdbserver.
>
> Coming back to your questions:
>
> 1. Could you try it with the new version of dw-link?
> 2. Leave out the transistor and source the ATtiny externally. The
> debugger will then ask you to power-cycle manually.
>
> Ah, and a suggestion: Buy a cheap Logic Analyzer. They are called
> something like "Logic Analyzer, 8 Channel, 24MHz" and cost less than $20.
> You can use the Saleae software or sigrok/pulseview to view the signals.
> Without an LA, I would not have been able to build the debugger.
>
> Cheers
> Bernhard
>
> —
> Reply to this email directly, view it on GitHub
> <#14 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACRCWNGXFEEEUHTERW6YFJT2RXJUPAVCNFSM6AAAAABNNUSY32VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZSG4YTIOI>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi surge, I think it is not a good idea to "fix" unrelated things in a program while you try to get things working. So, let's postpone the patch until we have found why the debugger cannot communicate with the ATtiny. Can you send me a sketch (Fritzing, drawing, schematic) of your setup so I can build an exact replicate? A photo would also be good. Also, you said that you have a scope. Is it a DSO with two channels? We do not need it to decode things, but to see whether there is the right kind of activity on the RESET line. It seems that the UNO tries to establish a debugWIRE connection, fails, and then tries to start ISP programming in order to set the DWEN fuse. Could you reset the fuse and try again? Best, |
Beta Was this translation helpful? Give feedback.
-
Greetings,
Having some problems with dw-link as follows. It must surely be some really stupid thing I've forgotten to do as I had this working some months ago (around April). I would like to say I haven't changed anything. Obviously I have! so I don't want o report a bug just yet. This is necessarily long I guess, so grab a coffee before you start...
The problem: avr-gdb cant seem to talk to the target properly. Output is as follows:
Retrying acts as if it worked, but doesn't:
Using a HVSP programmer, Ive confirmed the DWEN fuse is set, disabled it and we go through the cycle again.
According to the manual, both errors indicate a problem with the serial port. Notice the -b option provided to avr-gdb. I haven't tried forcing stop bits etc., they should be default. Is it worth a look? To what/how should they be set?
From the LED activity, it looks a bit like the dwire sync process is getting interrupted. I have a LED connected on the target chip (MISO). I realise dw-link needs to use ICSP (and that pin) to turn on the DWEN fuse, but it shouldn't be flashing crazily? The system LED flashes pretty randomly too. I've tried removing the MISO LED in case it's load is causing problems. It still fails.
My oscilloscope isn't good enough to see the full output on the RESET line (and decode whats happening), but I can tell the signal is nice and clean.
The current setup: Linux and an Arduino Uno connected to a breadboard with the target ATtiny chip. There is a 800mA PNP transistor for supplying controllable VCC to the target. It is sourced from the 5V pin on the Uno (max. 200mA minus what the Uno uses?).
Things that may or may not be relevant:
I'm sure I had a setup with this system working at some point. It worked so reliably I even made a little module that accomodates different ATtinys.
It was a while ago, but I'm pretty sure the Uno used to connect as a proper serial device (/dev/ttyUSB0), not /dev/ttyACM0. Not sure why it changed, but from my limited knowledge, ACM/CDC devices don't really have a baud rate. Could this be the problem? I have no idea how to get ttyUSB0 back.
The Uno is a "Funduino". As far as I can tell, it's functionally identical to a "real" one. The reset link has not been severed, I use a 10µF capacitor instead.
I have modified dw-link slightly. Mostly just changing pin assignments and inversing the VSUP references for the PNP supply.
My HVSP programmer is self-designed and built. Some functions are not fully tested or dont work yet (which is why I prefer to use dw-link for programming). This is the reason I started trying to use dw-link again - I wanted to check and debug it!
I vaguely remember going through various versions of avr-gdb to find one that I liked. Is 11.2 broken somehow?
With the mass deletion of the Internet by cloudflare/google/whoever lately, this is the only place I could find related to dw-link. I hope it's still active!
Any ideas?
surge
Beta Was this translation helpful? Give feedback.
All reactions