Thread: [tuxdroid-user] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that C
Status: Beta
Brought to you by:
ks156
Menu
▾
▴
tux-droid-user
|
From: Philippe T. <ph...@te...> - 2007-03-18 10:18:09
|
Hello, I tried to setup the toolchain to recompile the firmware but tuxup tells me the hex file has a wrong format. I'm using Debian Etch apt-get install gcc-avr avr-libc gdb-avr libsvn-dev Edit svncrev-0.1/config.mk: APR_INCLUDE=/usr/include/apr-1.0 Make svncrev and cp to /usr/local/bin Then on tuxcore: $ make clean rm -rf main.o sensors.o motors.o global.o led.o communication.o i2c.o fifo.o ir.o parser.o config.o standalone.o svnrev.h tuxcore.elf dep/* tuxcore.hex tuxcore.eep tuxcore.lss tuxcore.map bootloader.o tuxcore_bl.hex tuxcore_bl.lss tuxcore_bl.map tuxcore_bl.elf svnrev.h dep $ make svnwcrev . svnrev.tmpl.h svnrev.h Last committed at revision 100 Updated to revision 175 avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT main.o -MF dep/main.o.d -c main.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT sensors.o -MF dep/sensors.o.d -c sensors.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT motors.o -MF dep/motors.o.d -c motors.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT global.o -MF dep/global.o.d -c global.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT led.o -MF dep/led.o.d -c led.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT communication.o -MF dep/communication.o.d -c communication.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT i2c.o -MF dep/i2c.o.d -c i2c.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT fifo.o -MF dep/fifo.o.d -c fifo.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT ir.o -MF dep/ir.o.d -c ir.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT parser.o -MF dep/parser.o.d -c parser.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT config.o -MF dep/config.o.d -c config.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT standalone.o -MF dep/standalone.o.d -c standalone.c avr-gcc -mmcu=atmega88 -Wl,--section-start=.version=0x1DF0 -Wl,-Map=tuxcore.map main.o sensors.o motors.o global.o led.o communication.o i2c.o fifo.o ir.o parser.o config.o standalone.o -o tuxcore.elf avr-objcopy -O ihex -R .eeprom tuxcore.elf tuxcore.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex tuxcore.elf tuxcore.eep avr-objdump -h -S tuxcore.elf > tuxcore.lss text data bss dec hex filename 7022 280 164 7466 1d2a tuxcore.elf $ tuxup tuxcore.hex [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that CPU Time elapsed: 0 seconds. I did not modify the firmware sources but tuxcore.hex I compiled is only 20027 bytes while the one in firmware/hex is 20550 Note that the 20550-byte tuxcore.hex is accepted by tuxup so the problem is really when compiling it from sources. Any idea what's going wrong here? Phil |
|
From: Philippe T. <ph...@te...> - 2007-03-18 10:50:54
|
> $ tuxup tuxcore.hex > [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct > hex file for that CPU > I looked at check_hex_file in tuxup, here are the interesting bits of my invalid firmware: Original firmware: :0C1DF000C8000300C9D10100CA000000B7^ => version command = C8, version = 0.3.0 My firmware: :0C1DF000CA000000C9640000C800030025^ => version command = CA, version = 0.0.0 ?? |
|
From: Philippe T. <ph...@te...> - 2007-03-18 11:30:37
|
> Original firmware:
> :0C1DF000C8000300C9D10100CA000000B7^
> => version command = C8, version = 0.3.0
>
> My firmware:
> :0C1DF000CA000000C9640000C800030025^
> => version command = CA, version = 0.0.0 ??
>
Actually apparently the order of version, revision and author fields was
wrong
I tried to change global.c to reorder them:
const version_t tag_version __attribute__((section(".version"))) =
{VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
const revision_t svn_revision __attribute__((section(".version"))) =
{REVISION_CMD, SVN_REV, SVN_STATUS};
const author_t author __attribute__((section(".version"))) =
{AUTHOR_CMD, AUTHOR_ID, 0};
Now the file is accepted by tuxup and I could flash the tux but then its
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?
Phil
|
|
From: Philippe T. <ph...@te...> - 2007-03-18 16:39:20
|
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
|
|
From: David B. <da...@ja...> - 2007-03-18 22:03:11
|
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
|
|
From: Philippe T. <ph...@te...> - 2007-03-18 18:29:27
|
I tried to post my patch on http://www.tuxisalive.com/issue-trackers/tuxup but there is no zone defined and the tool complains about mandatory selection of a zone: Zone (Requis) Sélectionnez une zone ou ce ticket est approprié. Zone is required, please correct. Here's a copy of what I planned to post on the tracker (just to avoid loosing it): TITLE: Wrong order in version-revision-author structs, tuxup fails DETAILS: This is actually a firmware bug, not a tuxup bug but it concerns differents parts of the firmware so I think it is better to explain it here than in the various sub-sections of firmware tracker. When compiling the firmware files and trying to upload them, I get the error tuxup tuxaudio.hex [FAIL] Programming of 'tuxaudio.hex' failed, this file is not a correct hex file for that CPU or tuxup tuxcore.hex [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that CPU To fix those problems I changed: firmware/tuxaudio/trunk/main.c invert lines 42 and 44 firmware/tuxcore/trunk/global.c invert lines 53 and 55 |
|
From: David B. <da...@ja...> - 2007-03-18 22:20:41
|
Hi Philippe, Thank for the feedback, it's now fixed. As I told you, changing the order in the sources is not the good way to solve thatvdefinitely but this is indeed a bug of the firmware and the title describes it perfectly so please go ahaead and file the bug. I would add it on the firmware bugtracker though, I added a 'General' category as this is not specific to any firmware like you explained. Thanks, david On Sun, 18 Mar 2007 19:29:08 +0100, Philippe Teuwen <ph...@te...> wrote: > I tried to post my patch on > http://www.tuxisalive.com/issue-trackers/tuxup > but there is no zone defined and the tool complains about mandatory > selection of a zone: > > Zone (Requis) > Sélectionnez une zone ou ce ticket est approprié. > Zone is required, please correct. > > > Here's a copy of what I planned to post on the tracker (just to avoid > loosing it): > > TITLE: Wrong order in version-revision-author structs, tuxup fails > > DETAILS: > This is actually a firmware bug, not a tuxup bug but it concerns > differents parts of the firmware so I think it is better to explain it > here than in the various sub-sections of firmware tracker. > When compiling the firmware files and trying to upload them, I get the > error > tuxup tuxaudio.hex > [FAIL] Programming of 'tuxaudio.hex' failed, this file is not a correct > hex file for that CPU > or tuxup tuxcore.hex > [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct > hex file for that CPU > To fix those problems I changed: > firmware/tuxaudio/trunk/main.c invert lines 42 and 44 > firmware/tuxcore/trunk/global.c invert lines 53 and 55 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > tux-droid-user mailing list > tux...@li... > https://lists.sourceforge.net/lists/listinfo/tux-droid-user |
|
From: David B. <da...@ja...> - 2007-03-18 14:45:03
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X