dfu-programmer reports "address error" while burning Mizar32

[Bogdan Marinescu]

Hello,

I'm trying to burn my Mizar32 image (version on the master branch) to the Mizar32 board and I'm getting this error from dfu-programmer:

Burning image to target ...

Address error.

Something went wrong with creating the memory image.

This is a first, I didn't see this error before. I'm using the latest dfu-programmer (0.5.4); prior to this I was using 0.5.2 and I got the same error.

I think the board is entering DFU mode, since I can see this when running 'lsusb':

Bus 001 Device 014: ID 03eb:2ff8 Atmel Corp. 

Did anyone experience a similar error?

Thanks,

Bogdan

[Martin Guy]

On 9 October 2011 18:33, Bogdan Marinescu <bogdan.m...@gmail.com> wrote:
> I'm trying to burn my Mizar32 image (version on the master branch) to the
> Mizar32 board and I'm getting this error from dfu-programmer:
> Burning image to target ...
> Address error.
> Something went wrong with creating the memory image.

I think this happens when the firmware is larger than the flash memory.

Is the main chip on the base board an AT32UC3A0128 ?
If so, you will need to compile for target=lualong

If you want to enable modules other than pio and tmr, you would need
to apply the patches that reduce code size in various ways and then
enable all the modules - see
http://code.google.com/p/mizar32/wiki/CompilingElua#For_Mizar32_C

M

[Bogdan Marinescu]

Hi Martin,

Thanks for your reply. The image built (and linked) properly, so I don't think the issue is related to the size:

~/work/elua/elua [newtimers] $ avr32-size elua_lualong_at32uc3a0128.elf 

   text   data    bss    dec    hex filename

 122368   1368   1776 125512  1ea48 elua_lualong_at32uc3a0128.elf

I'll try to use batchisp from Windows, then I'll try to re-program the DFU loader in the CPU (although I'm pretty sure I didn't erase it).

Best,

Bogdan

 

   M

[Martin Guy]

> If you want to enable modules other than pio and tmr, you would need
> to apply the patches that reduce code size in various ways and then
> enable all the modules - see
> http://code.google.com/p/mizar32/wiki/CompilingElua#For_Mizar32_C

Oops, I just found I was getting this too with the 120KB patches, so I
guess the size of eLua has increased by a byte or two. I remember that
last time I measured the 120KB image with the LCD module, there were
only 4 bytes to spare...

If you disable the BUILD_LCD macro in mizar32_conf.h it fits - and you
can enable BUILD_TERM if you do that too:

#if defined( ELUA_CPU_AT32UC3A0128 )
// Build options for 120KB image
# define RAM_SIZE 0x8000
# define BUILD_ADC
# define BUILD_TERM
#else

M

[Martin Guy]

> Thanks for your reply. The image built (and linked) properly, so I don't
> think the issue is related to the size:
> ~/work/elua/elua [newtimers] $ avr32-size elua_lualong_at32uc3a0128.elf
>    text   data    bss    dec    hex filename
>  122368   1368   1776 125512  1ea48 elua_lualong_at32uc3a0128.elf

There is a window of image size where the build scripts don't detect
that it has overflowed but it doesn't fit in the available flash -
maybe it just measures the text size, I don't know.

122368+1368 = 123736, which exceeds the 120*1024 limit of 122880

Do let us know of any other issues you encounter

Bless

M

[Bogdan Marinescu]

Ah, thanks! I completely forgot about the 8k for the bootloader. I'll reduce the image size and try again.

Best,

Bogdan

 

Bless

   M