AVR Downloader/UploaDEr - Bugs: bug #43898, atmega644p remains stopped after...
You are not allowed to post comments on this tracker with your current authentication level.
bug #43898: atmega644p remains stopped after JTAG transaction
Submitter: | Craig Leres <leres> | ||
Submitted: | Sun 28 Dec 2014 07:42:04 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | None |
Status: | None | Privacy: | Public |
Assigned to: | None | Originator Name: | leres |
Open/Closed: | Open | Release: | None |
Programmer hardware: | Device type: |
Attached Files
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2014-12-28 | leres | Attached File | - | Added patch-jtagmkII.c, #32725 |
Powered by Savane 3.13-f8d8.
Corresponding source code
Back when I upgraded from 5.11 to 6.0.1 I noticed that my atmega644p did not resume after programming or reading. I'm using an AVR Dragon.
I've tracked this down to revisions 1070 and 1071 of jtagmkII.c. From the commit messages there appears to be an issue with the xmega. The old code issued the CMND_GO when device_descriptor_length was set. The current code only isses a CMND_GO when AVRPART_HAS_PDI is set.
Attached is a patch vs 1353 that changes jtagmkII_close() to also issue CMND_GO when PGM_FL_IS_JTAG is set which gives me 5.X behavior however is likely wrong for the xmega case. I suspect the correct fix is to just avoid issuing a GO when the target is an xmega.