Linux, avrdude, bootloader and Xmegas (128a3u)

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

Hi

 

I have been struggling with programming the xmega bootloader section lately using avrdude (version 6.2)

The case is that when verifying the content it always read back as 0xff and it is the same behaviour on two different HW.

The code is compiled with base address 0x20000, and the boot  reset flag is programmed. I also tried to both set and unset all lock bits to no help.

 

All scenarios was tried on both HW. I have used xmegas before, but never with an bootloader so this is first time I try to program xmega bootloader section via avrdude. I am able to load the application code via avrdude (into regular flash), and this executes perfectly on both hardwares. Worth to mention probably is that I use the pdi interface.

 

The following shows avrdude output after adding -v option aswell.

I find it a bit strange that all the fuses and the lockbits are readback as 0x00.

(Note that the following avrdude command and options is only one of the many attempts with different settings for lockbits and fuses which I have tried, but the result is the same at the end. Verification of fist byte at 0x20000 fails.)

 

Hope someone may share some light on this my problem

$ avrdude -c jtag2pdi -p x128a3u -e -Ulock:w:0xff:m -Ufuse2:w:0xbf:m -Uflash:w:Xmega_Bootloader.hex -v

avrdude: Version 6.2
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/micro/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : jtag2pdi
avrdude: usbdev_open(): Found JTAGICE mkII, serno: 00B0000044DD
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              0
S_MCU:
  boot-loader FW version:        255
  firmware version:              7.39
  hardware version:              1
Serial number:                   00:b0:00:00:44:dd
Device ID:                       JTAGICEmkII
         AVR Part                      : ATxmega128A3U
         Chip Erase delay              : 0 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 0
         StabDelay                     : 0
         CmdexeDelay                   : 0
         SyncLoops                     : 0
         ByteDelay                     : 0
         PollIndex                     : 0
         PollValue                     : 0x00
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           prodsig        0     0     0    0 no         50   50      0     0     0 0x00 0x00
           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00
           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00
           eeprom         0     0     0    0 no       2048   32      0     0     0 0x00 0x00
           application    0     0     0    0 no     131072  512      0     0     0 0x00 0x00
           apptable       0     0     0    0 no       8192  512      0     0     0 0x00 0x00
           boot           0     0     0    0 no       8192  512      0     0     0 0x00 0x00
           flash          0     0     0    0 no     139264  512      0     0     0 0x00 0x00
           usersig        0     0     0    0 no        512  512      0     0     0 0x00 0x00
           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00

         Programmer Type : JTAGMKII_PDI
         Description     : Atmel JTAG ICE mkII PDI mode
         M_MCU hardware version: 0
         M_MCU firmware version: 7.39
         S_MCU hardware version: 1
         S_MCU firmware version: 7.39
         Serial number:          00:b0:00:00:44:dd
         Vtarget         : 3.4 V

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9742 (probably x128a3u)
avrdude: erasing chip
avrdude: reading input file "0xff"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xff:
avrdude: load data lock data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xbf"
avrdude: writing fuse2 (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of fuse2 written
avrdude: verifying fuse2 memory against 0xbf:
avrdude: load data fuse2 data from input file 0xbf:
avrdude: input file 0xbf contains 1 bytes
avrdude: reading on-chip fuse2 data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of fuse2 verified
avrdude: reading input file "Xmega_Bootloader.hex"
avrdude: input file Xmega_Bootloader.hex auto detected as Intel Hex
avrdude: writing flash (136216 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 136216 bytes of flash written
avrdude: verifying flash memory against Xmega_Bootloader.hex:
avrdude: load data flash data from input file Xmega_Bootloader.hex:
avrdude: input file Xmega_Bootloader.hex auto detected as Intel Hex
avrdude: input file Xmega_Bootloader.hex contains 136216 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x20000
         0xff != 0x0d
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Sun. Jul 24, 2016 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I presume the boot loader does verify reads using ELPM? How are you handling the upper bits of the address? 

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

eeh... what has this to do with writing the bootloader to the bootloader section using avrdude?

 

Nevertheless, my blunt answer  for your question is I do not know. The bootloader is based on the xmega_bootloader from https://github.com/bandtank/Xmeg...

I have not gone into depth of it yet.

 

But, my problem is related to avrdude. But i noticed the following "

avrdude: input file Xmega_Bootloader.hex contains 136216 bytes

"

The hex file should not be detected as 128kB large, or more correctly, the size of the code to be flashed should not be 128kB.

The address offset is correct though pointing to 0x20000 which is the beginning of the bootloader section.

 

This is the build output when building the bootloader. It shows the .text section to be app. 5kB

 

There is something weird here

 

   text	   data	    bss	    dec	    hex	filename
   5122	     22	      0	   5144	   1418	Xmega_Bootloader.elf
Xmega_Bootloader.elf  :
section                      size       addr
.text                      0x13c8    0x20000
.BOOT                        0x3a    0x213c8
.data                        0x16   0x802000
.comment                     0x30        0x0
.note.gnu.avr.deviceinfo     0x40        0x0
.debug_aranges               0xd0        0x0
.debug_info                0x5a8f        0x0
.debug_abbrev              0x38af        0x0
.debug_line                0x1301        0x0
.debug_frame                0x368        0x0
.debug_str                 0x2b5d        0x0
.debug_loc                  0xde2        0x0
.debug_ranges                0x38        0x0
Total                      0xf876

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Sun. Jul 24, 2016 - 09:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a long shot... Since I have not used the debugger (jtagice mk2) for quite some time, the firmware is rather old. I therefore wonder if there could be some problems when flashing the boot section since the bootsection flash is, as I believe it, separated from the regular application flash on Xmega devices. But, since I have flipped the coin for the last time, and ended up running linux I do not have studio (and do not want' it either). However. I found som posts saying that one could use AVR32studio for this in linux to upgrade the debugger. But, this has not been updated since 2010 as far as I can see, stuck on version 2.6. I guess that was the day when Atmel Studio came alive and made the world a worse place to live.

 

Question is therefore then, are there any Linux alternatives left for upgrading the jtagice mk2 firmware?

 

EDIT:

PS... Is it possible to download the latest jtagice mk2 firmware from Atmel.com somehow? Or, maybe someone could PM it to me.

AVR32Studio contains a litle command line based tool named avrfwupgrade. It seems to be usable for the task but the fw that comes with the downloadable avr32 studio is very old.
I could download the atmel studio bloatware, but its size tells me that if you could avoid it, you do.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Wed. Jul 27, 2016 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zainka wrote:

 

 

But, my problem is related to avrdude. But i noticed the following "

avrdude: input file Xmega_Bootloader.hex contains 136216 bytes

"

 

This seems to be normal for avrdude, at least when dealing with bootloaders.

 

I have a somewhat similar bootloader and a somewhat similar AVR chip and I see this:

avrdude: input file cdc_bootloader.hex contains 138606 bytes

 

 

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

zainka wrote:

 

   text	   data	    bss	    dec	    hex	filename
   5122	     22	      0	   5144	   1418	Xmega_Bootloader.elf
Xmega_Bootloader.elf  :
section                      size       addr
.text                      0x13c8    0x20000
.BOOT                        0x3a    0x213c8
.data                        0x16   0x802000
.comment                     0x30        0x0
.note.gnu.avr.deviceinfo     0x40        0x0
.debug_aranges               0xd0        0x0
.debug_info                0x5a8f        0x0
.debug_abbrev              0x38af        0x0
.debug_line                0x1301        0x0
.debug_frame                0x368        0x0
.debug_str                 0x2b5d        0x0
.debug_loc                  0xde2        0x0
.debug_ranges                0x38        0x0
Total                      0xf876

 

How do you get this display?  I should know, I forgot.

 

I'm pretty sure my build has .text but not .BOOT.

 

That doesn't mean having both is necessarily wrong.

 

When I use avr-size I get only this displayed:

 

   text    data     bss     dec     hex filename
   7462      72      46    7580    1d9c CDC_bootloader.elf

Last Edited: Sat. Jul 30, 2016 - 12:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should add that I don't have your setup.  I program my bootloaders with Atmel Studio and the JTAGICE2.

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

steve17 wrote:

 

I have a somewhat similar bootloader and a somewhat similar AVR chip and I see this:

avrdude: input file cdc_bootloader.hex contains 138606 bytes

 

Hmmm.  I've only proven that this absurd size is normal for avrdude.  I haven't proven that this is not the problem, because I don't use avrdude to program the bootloader.  To get the above avrdude output I ran a verify, which failed actually.  The verify failure may not mean much because I can't be sure the bootloader hex file hasn't changed since I installed it on the chip. 

 

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x20000
         0x2f != 0xfe
avrdude: verification error; content mismatch

Last Edited: Sat. Jul 30, 2016 - 08:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve17

 

The .BOOT section is a requirement in the XMEGA Self-programming driver assembly source file which is written by Atmel and used by this bootloader. It contains a note which says the followin.

 

;*      If any SPM instructions are used, the linker file must define
;*      a segment named bootloader which must be located in the device Boot section.
;*      This can be done by passing "-Wl,--section-start=.BOOT=0x020000" to the

;*      linker with the correct address for the boot section.

 

That is all I know about that

-----

 

Now, to my problem, there is a difference between word addresses and byte addresses. I know that Atmel defines the address map in the datasheet using word addresses. This means that the bootloader  section is starting at address 0x10000. It confuses me a bit and I start wondering if avrdude inteprets the addresses as word addresses or byte addresses?, Where is it trying to write the code?

 

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Hmmm. Why did I not try this before... Really have no answer to that

I attached a debugger!, and codeblocks had no issues loading the bootloader and break at main() entry. The program counter tells me that am indeed executing from within the bootloader section.

So WHY can't I program the device from commandline using avrdude?

 

I have a first generation Atmel Xplained board using an xmega128A1. This I am able to load the very same bootloader into. So avrdude is capable of doing this. But why not on the A3U? And I have the same issue on two HW. And the debugger is able to load the firmware to the bootloader section and execute from it so the HW seems fine to me. Looks like an avrdude bug now...

 

I will try to build avrdude myself to be able to gain control over it but the autoconf reports

configure.ac:33: error: possibly undefined macro: AM_INIT_AUTOMAKE

 

Must solve that onefirst if you do not know what to do.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

The 0x20000 is correct.  That's what I have.

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

The fact that it works with the 128a1 makes it a real puzzler.  When you put the bootloader on the 128a1 does avrdude report the absurdly big file size?

 

I guess there could be something wrong with the avrdude.conf file for the 128a3u.    

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

One difference between the a1 and the a4u, and probably the a3u, is the flash page size.  The a1 has 256 word pages.  The a4u has 128 word pages.

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

a3u has 256 word/pages or 512 bytes pr. page.

If you look at the definitions in the Xmega_Bootloader below, you see the values used (defined in the makefile) and which seems correct to me.
 

ifeq ($(MCU), atxmega128a1)
    BOOT_SECTION_START_IN_BYTES = 0x20000
    BOOT_PAGE_SIZE = 512
    APP_PAGE_SIZE = 512
endif
ifeq ($(MCU), atxmega128a1u)
    BOOT_SECTION_START_IN_BYTES = 0x20000
    BOOT_PAGE_SIZE = 512
    APP_PAGE_SIZE = 512
endif
ifeq ($(MCU), atxmega128a3)
    BOOT_SECTION_START_IN_BYTES = 0x20000
    BOOT_PAGE_SIZE = 512
    APP_PAGE_SIZE = 512
endif
ifeq ($(MCU), atxmega128a3u)
    BOOT_SECTION_START_IN_BYTES = 0x20000
    BOOT_PAGE_SIZE = 512
    APP_PAGE_SIZE = 512
endif
ifeq ($(MCU), atxmega128a4u)
    BOOT_SECTION_START_IN_BYTES = 0x20000
    BOOT_PAGE_SIZE = 256
    APP_PAGE_SIZE = 256
endif

 

I will check the conf file. Seems to be the best clue so far. Thanks for the tip

 

 

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"