Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ATmega48PA AddrFlag #44

rokiden opened this issue Aug 4, 2019 · 1 comment

ATmega48PA AddrFlag #44

rokiden opened this issue Aug 4, 2019 · 1 comment


Copy link

@rokiden rokiden commented Aug 4, 2019

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?


This comment has been minimized.

Copy link

@dcwbrown dcwbrown commented Aug 4, 2019

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.