Problems on xmega32a4u and avrdude on windows

[Ian Barnes]

Hi everyone, hopefully someone can offer advice. I am trying to use
xboot on an xmega32a4u. I compiled under windows using the latest
Atmel toolchain, avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2.

I got the project to build after removing references to "sizebefore"
and "sizeafter" in the makefile. These cause errors under Windows and
aren't needed. I also changed the device to atxmega32a4u and the clock
to 32MHz in the makefile.

I was using a timed entry to the application, but as there was no app
programmed it remained in the bootloader (led flashing quickly). I
then used avrdude (Version 5.11-Patch#7610) to try and program and got
the following output:

----------------------------------------
C:\>avrdude.exe -p x32a4 -P com4 -c avr109 -b 115200 -U
flash:w:app.hex

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=256 bytes.

Programmer supports the following devices:
Device code: 0x7b

avrdude.exe: AVR device initialized and ready to accept instructions

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

avrdude.exe: Device signature = 0x1e9541
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle
will be perfo
rmed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "app.hex"
avrdude.exe: input file app.hex auto detected as Intel Hex
avrdude.exe: writing flash (3220 bytes):

Writing | ################################################ | 95%
0.48savrdude.
exe: error: programmer did not respond to command: write block

C:\>
----------------------------------------

Does anyone have ideas/suggestions as to what I should try next?
Obviously xboot is running and avrdude is able to talk to it, but the
programming fails for some reason.

Kind regards
Ian.

[Bradley Nelson]

What are you using as a link between your AVR and PC?

--
You received this message because you are subscribed to the Google Groups "avr-xboot" group.
To post to this group, send email to avr-...@googlegroups.com.
To unsubscribe from this group, send email to avr-xboot+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/avr-xboot?hl=en.

[Ian Barnes]

Hi Bradley,
I am using an FTDI FT232RL. I am pretty sure it's okay, as I've used
it extensively in my application code.
Cheers,
Ian.

[Alex Forencich]

How did you burn xboot onto the chip? And did you try it at 2 MHz?

Alex Forencich

[Ian Barnes]

Exactly the same result at 2MHz, I am using an Atmel Dragon combined
with Atmel Studio 6 to do the programming. Boot fuse is enabled.

[Alex Forencich]

And I'm assuming that xboot is being written into the proper location in
the boot block? (wrote xboot.hex to address 0 or xboot-boot.hex with
the correct offset)

[Ian Barnes]

Yes I dumped the contents of the flash memory after programming. The
application area is blank 0x0 - 0x7fff.
I can also see the interrupt vector table starting at 0x8000 and the
boot loader code taking up to approx 0x8FAB.
Cheers,
Ian.

[Alex Forencich]

Hmm. After the failed programming, is there anything in the application
section or is it completely empty?

[Ian Barnes]

Hi Alex,
The boot loader is intact. There are chunks of programmed data that
don't appear to relate to the application that was being programmed
(not that I can tell anyway). The chunks are located at:
0x0 - 0xff
0x2000 - 0x20ff
0x4000 - 0x40ff
0x6000 - 0x60ff

I had to use avrdude with the device parameter "-p x32a4" because it
doesn't appear to know about the xmega32a4u, would this matter? The
makefile correctly specifies atxmega32a4u. Thanks for your help so
far.

Kind regards,
Ian.

[Alex Forencich]

That is really, really strange. What verison of avr-gcc and avr-ld are
you running? Can you send me xboot.map? And are you using the latest
xboot from github (head revision, not one of the archives)?

Alex Forencich

[Ian Barnes]

Hi Alex,

I believe I got the head revision, the file I downloaded was named "alexforencich-xboot-r2012.03.03-9-g8ee2611".

C:\>avr-gcc --version

avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2

Copyright (C) 2011 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\>avr-ld --version

GNU ld (AVR_8_bit_GNU_Toolchain_3.4.0_663) 2.22

Copyright 2011 Free Software Foundation, Inc.

This program is free software; you may redistribute it under the terms of

the GNU General Public License version 3 or (at your option) a later version.

This program has absolutely no warranty.

I have also attached xboot.map.

Many thanks,

Ian.

[Alex Forencich]

I was wanted the map file as there was a bug with gcc 4.7 where it would put the .bss segment in the wrong spot and clobber a bunch of hardware registers on atmega chips.  Looks like it's fine on yours, though.  And xboot ought to fit as well, as the end is before 0x0008fff.  As a sanity check, I just reflashed my x64a3 dev board with xboot to check it again and was able to write a test program just fine.  I'm starting to think there may be some sort of hardware problem, perhaps a baud rate disagreement that's just a little bit off.  Not sure how that could happen, though, as the baud rates in xboot should be quite accurate.  I have never had any trouble with ftdi chips either, using them on several of my boards to flash via xboot at 115200 baud with no problems. 

One thing I was wondering, though.  Did you try compiling it for the atxmega32a4, non U series?  I wonder if there is something fishy going on there.  I did hear from someone else that there are very few differentiating characteristics between the 32a4 and 32a4u as they share the same device ID.  Can you also send me the .conf.mk file that you made?

Thanks

Alex Forencich

--
You received this message because you are subscribed to the Google Groups "avr-xboot" group.

To view this discussion on the web visit https://groups.google.com/d/msg/avr-xboot/-/2slznfuvdxEJ.

[Ian Barnes]

Hi Alex,

I will try compiling for the non-U series and let you know how I get on. I did not create a .conf.mk file, but just edited the comments in xboot.h, I then used just "make" to compile. I did this because the build system seems a little broken under windows when using a .conf.mk file, results attached at the end. I have also attached my xboot.h for reference.

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

C:\test>make x32a4.conf.mk

The system cannot find the path specified.

cp x32a4.conf.mk config.mk

make

The system cannot find the path specified.

make[1]: Entering directory `C:\test'

ECHO is off.

-------- begin --------

avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2

Copyright (C) 2011 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

"Generating config.h for atxmega32a4"

"1" was unexpected at this time.

make[1]: *** [config.h] Error 255

make[1]: Leaving directory ` C:\test '

make: *** [x32a4.conf.mk] Error 2

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

[Alex Forencich]

Is your .conf.mk in the same folder as all the others?  You need to type the relative path from the working directory.  Just make x32a4.conf.mk is fine if it is in the cwd, but if it is in the conf folder, you need to type make conf/x32a4.conf.mk. 

I don't see anything strange going on in your header file, though.  Frankly I'm at a loss over here.  I'm not sure why it's still not working for you.  I know a few other people have gotten it working properly on the 32a4u, but I am not sure what procedure they used exactly. 

Alex Forencich

--

You received this message because you are subscribed to the Google Groups "avr-xboot" group.

To view this discussion on the web visit https://groups.google.com/d/msg/avr-xboot/-/AUM6t74SAesJ.

[Ian Barnes]

Hi Alex,

I have gotten a bit further... I managed to do some debugging of the bootloader and saw that when I used a terminal program to load in an address of 0x0, that the actual address variable was getting set to some weird incorrect value - this was traced to the function get_2bytes behaving incorrectly. When I looked at the code, I saw two implementations, one in asm and one in C commented out. I swapped them round, and avrdude worked correctly when using the C implementation but not the asm one. Also the correct address was loaded when I used the terminal program. Maybe the way arguments are passed between C and asm have changed with the gcc compiler I am using from Atmel?

Here's the broken asm version:

0000879e <get_2bytes>:

    879e: 0e 94 af 43 call 0x875e ; 0x875e <get_char>

    87a2: 98 2f       mov r25, r24

    87a4: 0e 94 af 43 call 0x875e ; 0x875e <get_char>

    87a8: 88 2f       mov r24, r24

    87aa: 08 95       ret

And here's the working C version:

0000879e <get_2bytes>:

    879e: cf 93       push r28

    87a0: 0e 94 af 43 call 0x875e ; 0x875e <get_char>

    87a4: c8 2f       mov r28, r24

    87a6: 0e 94 af 43 call 0x875e ; 0x875e <get_char>

    87aa: 3c 2f       mov r19, r28

    87ac: 20 e0       ldi r18, 0x00 ; 0

    87ae: 90 e0       ldi r25, 0x00 ; 0

    87b0: 82 2b       or r24, r18

    87b2: 93 2b       or r25, r19

    87b4: cf 91       pop r28

    87b6: 08 95       ret

I am not skilled enough to know any more than that. Are you able to shed any light on the differences?

Cheers,

Ian.

[Alex Forencich]

Well, good catch!  It must have something to do with your compiler.  Not sure what the issue is, though.  Mine compiles like so:

000103fe <get_2bytes>:

unsigned int __attribute__ ((noinline)) get_2bytes()
{
        // return (get_char() << 8) | get_char();
        unsigned int result;
        asm volatile (
   103fe:    0e 94 e0 81     call    0x103c0    ; 0x103c0 <get_char>
   10402:    38 2f           mov    r19, r24
   10404:    0e 94 e0 81     call    0x103c0    ; 0x103c0 <get_char>
   10408:    28 2f           mov    r18, r24
                "mov  %A0,r24"     "\n\t"
                : "=r" (result)
                :
        );
        return result;
}
   1040a:    c9 01           movw    r24, r18
   1040c:    08 95           ret

I will play with the C code a bit and see if I can get rid of the inline assembly while still producing reasonable code.  It's really not all that ideal to have that as assembly anyway, though you can see why I did it with the useless ldi and or instructions.  I mean, come on GCC, that's just a waste of space. 

Alex Forencich

--

You received this message because you are subscribed to the Google Groups "avr-xboot" group.

To view this discussion on the web visit https://groups.google.com/d/msg/avr-xboot/-/Np562VvuW0EJ.