dwire-debug icon indicating copy to clipboard operation
dwire-debug copied to clipboard

ATmega48PA AddrFlag

Open rokiden opened this issue 5 years ago • 2 comments

Hi! I'm using ATmega48PA + FT232R + diode. dwdebug f0 founds baud, correctly read signature but stucks at WriteDebug error. After debugging I found that it stucks at DwGetRegs(first=28,count=4) that produces cmd D0 10 1C D1 10 20 66 C2 01 20. I tried sent this cmd manualy and found that it forced my Atmega to stuck in forever loop with sending some data. I think that mcu cant reach BP 0x1020 and tries inifinitly. 0x10 is AddrFlag() result, after replacing it with 0x0 mcu replies with 4 bytes and program working. I can't find 0x10 bias in datasheet, can somebody explain me why it used?

rokiden avatar Aug 04 '19 14:08 rokiden

Gosh, well found!

It's a long time ago ...

Looking back through history the only relevant comment I found was'Refactor with 0x1000 PC and BP bias for atmega88'. I vaguely remember having problems with the atmega88 and that without the 0x10 high byte offset on both PC and BP, register reads didn't terminate.

None of this was documented when I was working on it, other than the good but cryptic notes from Rikus W at http://www.ruemohr.org/docs/debugwire.html.

Atmel didn't publish the dWire protocol. If I had to guess where oddities like this might have come from, I would expect that if a chip revision had bugs/quirks in its dwire implementation, Atmel would be more likely to work around them in their debugging and programming firmware than they would be to produce a new hardware revision.

This flag was a guess. Indeed I don't really understand it now: how can it still work for the atmega88 which is an 8k flash chip?

Great to hear that with AddrFlag() always returning 0, dwdebug is working correctly for you.

-- Dave.

dcwbrown avatar Aug 04 '19 19:08 dcwbrown

Hi guys! I have the similar situation with my ATmega48 chip. When I set the PC/BP to 0x0000/0x0020 or to 0x1000/0x1020 for reading all the registers - I get infinite loop when the chip transmits the registers' values. I have tried to set the PC by D0 to 0x0000 and to get it back immediately after that by F0 - as a result I got 0x1800. So it seems that the bias for my revision of ATmega48 is 0x1800 due to after issuing D0 18 00 D1 18 20 66 C2 01 20 the reading all the registers works fine for me (no more infinite loop). I have modified my local copy of dwdebug (AddrFlag() returns 0x18) and now it works.

oldvers avatar Feb 09 '21 17:02 oldvers