Debugging ATXMega256A3 with avarice

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi list. is there a way to have debug support for atxmega256a3 with avarice + MKII Jtag ICE ?

I patched avarice 2.10 and was able to read fuse bits and run/stop code execution. I managed to see where the code execution stopped but when I display the value of a variable it appears to be wrong (e.g.: I have "int a = 0x22;" at the beginning of my main and "display a" reports "a" as being NULL (0x0)).

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

riccardomanfrin wrote:
Hi list. is there a way to have debug support for atxmega256a3 with avarice + MKII Jtag ICE ?

I patched avarice 2.10 and was able to read fuse bits and run/stop code execution. I managed to see where the code execution stopped but when I display the value of a variable it appears to be wrong (e.g.: I have "int a = 0x22;" at the beginning of my main and "display a" reports "a" as being NULL (0x0)).

I developed a patch to erase and reprogram atxmega256a3.. it works great.. except for the fact that the flash page size declared in doc8068 is WRONG! its 128 words (256 KB).. I assume that pages should be 1024 instead of 512... (hopefully).

Patch follows:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please file them as bug/patch tracker items on the sourceforge.net
project.

I tried replying you by email (and telling you just the above), but
it seems my email never reached you.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Btw., your second patch contains a lot of unrelated stuff (like, a
full "config.log"). Also, it is very invasive, and thus not
acceptable as it is. For example, you are redefining the ELF file's
address range offsets (0x800000 for SRAM) to something else, which
will completely break AVaRICE for anything else but your own change.
It also contains gratuitous stylistic changes, and changes like
unnecessarily turning a const char * into a char *.

I'd love it if you subscribed to the avarice-user mailinglist, and
discuss the changes needed to debug your Xmega there, so we could
eventually come up with a patch that doesn't break anything.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
Btw., your second patch contains a lot of unrelated stuff (like, a
full "config.log"). Also, it is very invasive, and thus not
acceptable as it is. For example, you are redefining the ELF file's
address range offsets (0x800000 for SRAM) to something else, which
will completely break AVaRICE for anything else but your own change.
It also contains gratuitous stylistic changes, and changes like
unnecessarily turning a const char * into a char *.

I'd love it if you subscribed to the avarice-user mailinglist, and
discuss the changes needed to debug your Xmega there, so we could
eventually come up with a patch that doesn't break anything.

Yes I know, that patch is a big work around.. not acceptable as mainstream patch.

I'm preparing a new patch as the previous had several issues.

I've now fixed erase and flash with avarice and I've also modified avr-gdb to support on-chip debug.. I'm on the way to provide appropriate patches.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So .. here is a clean patch for supporting atxmega256a3 with avarice 2.10.
I got rid of those things that break support for older MCU, whether I don't have any atmega or older to check compatibility.
The patch adds a description of the xmega256a3 and a couple of conditions in the main function to force alternate commands for erasing/reprogramming when dealing with the xmega (erase is now "0x34" and XMEGA has different MEMORY_TYPE associated to each segment - if I'm recall it right - .
I also removed some "const" here and there which gave me troubles with my libc.

The second patch is for avr-gdb 6.8-1 which is available to build from avrfreaks scripts @ this link:

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=download&id=17480

Again I didn't test gdb with other micros so I'm not sure about compatibility.. nevertheless it's a good starting point to make a good one.
By applying the patch, you are now able to perform on-chip-debug via the jtag interface of the mkII jtag ice.
Basically the patch adds the stack pointer offset to the address that avr-gdb is going to request avarice for.

Note that avrfreaks scripts shall download insight 6.8, while this patch works on 6.8-1.
To force 6.8-1 you need to edit package-versions file and change version from "6.8" to "6.8-1".

Then follow the instructions and apply this patch (after the others). By having a look at buildinsight.sh I see it should be ok to place the patch in the patches/insight-6.8-1 folder and build. The script should be able to pick it up.

I'm going to add it to sourceforge as suggested or I'll wait for your feedback before... let me know.

@ dl8dtl Strange you didn't reach me.. my email is name surname at gmail.. I've also checked the spam.. did you get a notification or something?

Regards,
Riccardo

Attachment(s):