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 17:39:07 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi David,
>> 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.
> Ok thanks! That works better now!
>> 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.
> No I don't think so because the order is wrong *in the hex file* and
> tuxup complains about it so eep file has nothing to do with that point=
 I
> think.
>
>
> So now I can mangle the firmware :-) but still with this change in  =

> global.c:
>>> 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};
> which sounds reasonible as this is the expected order in the hex file.=


What I meant is that the version of GCC you use when compiling the  =

firmware can freely arrange the order of 3the  structures in the .versio=
n  =

section. GCC is not due to follow any specification when arranging parts=
  =

of a section, or bytes of a structure or bits of a bitfield. With my  =

version of GCC that works just fine with the order actually in the  =

firmware. So changing the order like you did is OK for your version but =
is  =

not the good solution for everybody.

>
> My first personalized firmware has the following behaviour:
> Eyes closed when no rf link and opened when rf link is established.
> Note that it would be easier if there was a CLOSE_EYES_CMD
> I solved it by using
> #define RF_DISCONN_E_SEQ {\
> 0, OPEN_EYES_CMD, BLINK_EYES_CMD, 1, 0,
>
> Note that for such personalization, only eep file is required so actua=
lly
> you don't have to fix global.c if you don't plan to use the hex file.

Close eyes will be added if it's still not there. That's just because th=
e  =

switch that detects when the eyes are closed has only been working  =

correctly very late in production.
The idea of storing all these sequences and configurations in eeprom is =
to  =

be able to update them from your application without the need to bootloa=
d.  =

That's still not possible now but there isn't much to do to finish it.

Great to see the first custom firmware btw :-)

Cheers,
david