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

[Philippe T. <ph...@te...>]

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"))) =
>> {VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
>> const revision_t vn_revision __attribute__((section(".version"))) =
>> {REVISION_CMD, SVN_REV, SVN_STATUS};
>> const author_t author __attribute__((section(".version"))) =
>> {AUTHOR_CMD, AUTHOR_ID, 0};
which sounds reasonible as this is the expected order in the hex file.

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 actually
you don't have to fix global.c if you don't plan to use the hex file.

Phil