Re: [tuxdroid-user] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that CPU

[David B. <da...@ja...>]

On Sun, 18 Mar 2007 12:30:24 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

>
>> Original firmware:
>> :0C1DF000C8000300C9D10100CA000000B7^
>> =3D> version command =3D C8, version =3D 0.3.0
>>
>> My firmware:
>> :0C1DF000CA000000C9640000C800030025^
>> =3D> version command =3D CA, version =3D 0.0.0 ??
>>
> Actually apparently the order of version, revision and author fields w=
as
> wrong
> I tried to change global.c to reorder them:
>
> const version_t tag_version __attribute__((section(".version"))) =3D
> {VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
> const revision_t vn_revision __attribute__((section(".version"))) =3D
> {REVISION_CMD, SVN_REV, SVN_STATUS};
> const author_t author __attribute__((section(".version"))) =3D
> {AUTHOR_CMD, AUTHOR_ID, 0};
>
> Now the file is accepted by tuxup and I could flash the tux but then i=
ts
> behaviour is not correct so there are still other problems and my file=

> is still 20077-byte large instead of 20550.
>
> Someone has some suggestions?

Hi Philippe,

The original firmware was still done with winavr 2006 which uses GCC 3.4=
.6  =

iirc. I didn't want to move to a new version at the end of development.
I now completely moved to linux but didn't work much on the firmware sin=
ce  =

then. I once compiled the firmware under Linux with GCC4.1 and that work=
ed  =

fine. That's normal that the file sizes don't match as you probably didn=
't  =

use the same version as me.

If you recompile the firmware, you have to upload both hex and eep files=
  =

otherwise the standalone behavior looks very strange. Different versions=
  =

of GCC will reorganize data differently.

And that's also probably the reason why you had that such problems with =
 =

the version structure of your hex file.
At 0x1DF0 (just before the bootloader) I placed 3 structures to get the =
 =

version number (which also includes the CPU number), the revision number=
  =

and an ID for the author. I use the CPU number and version number to  =

validate the hex file in tuxup and know which CPU to reprogram.

GCC is free to organize data inside structures in any way so setting the=
  =

order manually like I did is not the correct way to go but I didn't find=
  =

better. It seems here GCC reordered the 3 strcutures sequence in the  =

.version section and also the byte order inside the structures and also =
 =

the bit order inside bitfields.

If it works for you like this, it's fine for now but we'll have to find =
 =

the solution for this soon.

btw, glad to see someone is interested in the firmware :-)
david