dwire-debug
dwire-debug copied to clipboard
dcwbrown
Atmega88: device not found
Hi, I got my ft232 converter finally.I give it a try but unfortunately I get the following error. I enabled the debug-wire on my device (lfuse:0xE2 hfuse:0x9F)
sudo ./dwdebug verbose,device
Trying ttyUSB0, baud rate 150000, break length 0050, skipping [00], received 00000000, scale 20%
Trying ttyUSB0, baud rate 030000, break length 0050, skipping [00], received 00000000, scale 20%
Trying ttyUSB0, baud rate 006000, break length 0050, warning, byte read after break is non-zero., skipping [], received 00011100: 8 001200000, scale 60%
Trying ttyUSB0, baud rate 003600, break length 0050, warning, byte read after break is non-zero., skipping [], received 00110010: 8 023000000, scale 85%
Trying ttyUSB0, baud rate 003060, break length 0050, warning, byte read after break is non-zero., skipping [], received 11011010: 6 041000000, scale 95%
Trying ttyUSB0, baud rate 002907, break length 0050, warning, byte read after break is non-zero., skipping [], received 01011010: 8 061000000, scale 95%
Trying ttyUSB0, baud rate 002761, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001011: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002622, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001001: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002490, break length 0050, warning, byte read after break is non-zero., skipping [], received 00001001: 8 021010000, scale 95%
Trying ttyUSB0, baud rate 002365, break length 0050, warning, byte read after break is non-zero., skipping [], received 10101101: 7 051000000, scale 95%
Trying ttyUSB0, baud rate 002246, break length 0050, warning, byte read after break is non-zero., skipping [], received 00010101: 8 050100000, scale 95%
Trying ttyUSB0, baud rate 002133, break length 0050, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000, scale 95%
Trying ttyUSB0, baud rate 002026, break length 0050, warning, byte read after break is non-zero., skipping [], received 01010101: expected result.
Finding upper bound.
Trying ttyUSB0, baud rate 002066, break length 0049, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000
Finding lower bound.
Trying ttyUSB0, baud rate 001985, break length 0049, warning, byte read after break is non-zero., skipping [], received 00000101: 8 030001000
, warning, byte read after break is non-zero.Couldn't find a DebugWIRE device.
Backtrace:
ConnectSerialPort+0x7e
DeviceCommand+0xca
HandleCommand+0x99
ParseAndHandleCommand+0x9b
UI+0xc5
Some update: I have a custom (DIY) devboard with pl2303 onboard for serial port. I removed the DTR line and avr RESET link.I get the following:
sudo ./dwdebug verbose,device
Trying ttyUSB0, baud rate 150000, break length 0050, skipping [0], received 11000000: 6 000000100, scale 60%
Trying ttyUSB0, baud rate 090000, break length 0050, skipping [0], received 11011010: 6 041000000, scale 95%
Trying ttyUSB0, baud rate 085500, break length 0050, skipping [0], received 01011010: 8 061000000, scale 95%
Trying ttyUSB0, baud rate 081225, break length 0050, skipping [0], received 01001011: 8 042000000, scale 85%
Trying ttyUSB0, baud rate 069041, break length 0050, skipping [0], received 10100101: 7 051000000, scale 95%
Trying ttyUSB0, baud rate 065588, break length 0050, skipping [0], received 01010101: expected result.
Finding upper bound.
Trying ttyUSB0, baud rate 066899, break length 0002, skipping [0], received 10010101: 7 051000000
Finding lower bound.
Trying ttyUSB0, baud rate 064276, break length 0002, skipping [0], received 01010101: expected result.
Trying ttyUSB0, baud rate 062990, break length 0002, skipping [0], received 01010101: expected result.
Trying ttyUSB0, baud rate 061730, break length 0002, skipping [0], received 01010101: expected result.
Trying ttyUSB0, baud rate 060495, break length 0002, skipping [0], received 01010101: expected result.
Trying ttyUSB0, baud rate 059285, break length 0002, skipping [0], received 01010101: expected result.
Trying ttyUSB0, baud rate 058099, break length 0002, skipping [0], received 11010101: 6 060000000
Connected to DebugWIRE device on USB serial port ttyUSB0 at baud rate 62436
WriteDebug, byte 1 of 1: Read 00 expected f3
Backtrace:
DwExpect+0x164
DwWrite+0x31
DwConnect+0x36
TryConnectSerialPort+0x178
ConnectSerialPort+0x88
DeviceCommand+0xca
HandleCommand+0x99
ParseAndHandleCommand+0x9b
UI+0xc5
Couldn't find a DebugWIRE device.
Backtrace:
ConnectSerialPort+0x7e
DeviceCommand+0xca
HandleCommand+0x99
ParseAndHandleCommand+0x9b
UI+0xc5
The successful speed negotiation means that the dwire protocol has (repeatedly) managed to transfer one byte (0x55) from the atmega to the ft232 without issue.
That 'WriteDebug' message happens if, when writing data to the debugwire pin, the same data doesn't also show up on the ft232 receive pin. This implies that the reset line is being pulled hard low by something else.
0xF3 is sent by dwdebug during connection - it is the command to read back the device signature so dwdebug can configure device specific details like memory size.
0xF3 isn't the first thing sent. Before that dwdebug reads the PC, r30 and r31. It is a good sign that these have complete successfully.
So, it is as if something has pulled reset low a short while after connection. Is there anything still connected to your atmega88 reset pin?
I've not used an atmega88 myself, so have ordered one to try here. It'll be a few days coming.
-- Dave.
dw_atmega88.logicdata.zip I tried to pull low and high by a 10K resistor and it is worked. I captured some traffic between ft232 and the atmega88. You can open it by saleae logic(after unzipping):https://www.saleae.com/
After issuing the following command I get:
sudo ./dwdebug 0 625000
b - Set breakpoint
bc - Clear breakpoint
d - Dump data bytes
dw - Dump data words
f - Dump flash bytes
fw - Dump flash words
l - Load file
g - Go
p - PC set / query
q - Quit
r - Display registers
s - Stack
t - Trace
te - Timer enable
td - Timer disable
u - Unassemble
h - Help
reset - Reset processor
qdd - Quit and temporarily disable debugWIRE
help - Help
device - Device connection port
verbose - Set verbose mode
gdbserver - Start server for GDB
Unconnected. > r
ttyUSB0 ................
Connected to DebugWIRE device on USB serial port ttyUSB0 at baud rate 61935
WriteDebug, byte 1 of 1: Read 00 expected f3
Backtrace:
DwExpect+0x164
DwWrite+0x31
DwConnect+0x36
TryConnectSerialPort+0x178
ConnectSerialPort+0x88
HandleCommand+0x77
ParseAndHandleCommand+0x9b
UI+0xc5
Couldn't find a DebugWIRE device.
Backtrace:
ConnectSerialPort+0x7e
HandleCommand+0x77
ParseAndHandleCommand+0x9b
UI+0xc5
Unconnected. > ^C
I sniffed and decoded the traffic The byte stream is the following:
0x00 0x55 0xF0 0x11 0x35
Baudrate setup and set PC reg. to 0x1135
0x66 0xD0 0x00 0x1E
Prepare to Reading/Writing memory: set PC to 0x001E (Read from 0x001E)
0xD1 0x00 0x20
Set the HW BreakPoint to 0x0020 (Read to 0x0020 [2 byte])
0xC2 0x01 0x20 0x61 0x00
Read registers [R30 and R31] and GO. Get from target: 0x61 0x00
0x00 0x00 0x12 0x4D 0xA0 0xB8
I am lost here :| Maybe set baudrate to 125kbps (0xA0)
0x51 0x55
A no more traffic...
Thanks for the sniff.
After the 0xC2 0x01 0x20 0x61 0x00 the next thing you should have seen was the 0xF3 that dwdebug sends to read the signature.
Therefore I think the 0x00 0x00 0x12 0x4D 0xA0 0xB8 you see instead of 0xF3 is coming from the avr. The first 0x00 is the one that overrides the F3 and causes dwdebug to report the WriteDebug error.
This is worrying - it seems the breakpoint at 0x20 hasn't worked like it does on the attinys, and the read has kept going.
It suggests that the debugWIRE interface on the atmegX8's is different. Maybe it has been tweaked to allow for more features. Larger memories?
I don't know how much effort you would like to put in :-). This could be time consuming:
If you would like to look further, and you have atmel debugwire hardware to hand, perhaps the next step would be to sniff the communication between the atmel hardware and avr at debugger startup. The atmel debugger should use similar sequences, and we can see if there is a difference in how for example the breakpoint setting is achieved. Or maybe the 'start read' command (0xC2) is different.
I have an atmega88 coming next week so I can look into this, but I'm not promising a quick result :-).
Cheers -- Dave.
Thanks for your help. Sandy I dont have Atmel debugWire hardware so I think I cant do more research. I hope you can find the way to figure out how was implemented the debugwire on atmega series. If i can do anything plesa let me known. Best Regards.
Hi, I have one atmega88, it's detected as atmega88a by dwdebug, but debug don't work. With one atmega328P dwdebug work without problem. Apparently the protocol (or the speed of transactions) are different for the atmega88. The DwSync in the DwReset and DwWait in the DwGo always return less bytes than the ones written. Using a terminal the commands reset (0x07) and ISP mode (0x06) work without problem in atmega88. With this it is possible to reprogram the atmega88 fuses with a ISP programmer.
Example of output with atmega328p
./dwdebug device t0 7839
Connected to ATmega328P on /dev/ttyUSB0 at 7839 baud.
7e10: ffff
and with atmega88
./dwdebug device t0 7839
Connected to ATmega88A on /dev/ttyUSB0 at 7839 baud.
SerialRead expected 23 bytes, received 19 bytes
00 00 00 00 01 00 00 00 01 00 00 00 00 01 00 00 00 00 55
Best Regards.
