Firmware Modifications

[asicdruide]

Hi Jacek,

i'm trying to reproduce the released firmware of a led_rgb module (3.8.0.0-rev0).
Steps i've done:
* MPLAB-X IDE downloaded from microchip homepage and installed
* git repository cloned
* code imported in new project and build, completed without error

Code: Select all

Device Database Version 1.20
Copyright (c) 1998-2011 Microchip Technology Inc.
Errors    : 0

MP2HEX 5.03, COFF to HEX File Converter
Copyright (c) 1998-2011 Microchip Technology Inc.
Errors    : 0

make[2]: Leaving directory '.../MPLABXProjects/test.X'
make[1]: Verlasse Verzeichnis '.../MPLABXProjects/test.X'

BUILD SUCCESSFUL (total time: 2s)
Loading code from .../MPLABXProjects/test.X/dist/default/production/test.X.production.hex...
Loading completed

* hex-to-haf converted downloaded, slightly modified to compile it under Linux
* self-created hex-file converted
* compared self-created haf-file to haf-file from git
In the first half there are a few differences (maybe 1%). But, your haf-file is about twice
as long as my self-created one.

What might went wrong with my build process?

Many thanks for help in advance.

Klaus

[Jacek]

Hi Klaus,
The only thing I can think of is your modification of converter.
The haf file is almost identical to hex file, but does not contain the fake bootloader and has got calculated firmware checksum, so it is about 50 lines shorter. Make sure your haf file is about 50 lines shorter than hex file.

[asicdruide]

Hi Jacek,

for hex-to-haf step i've used the 'HAPCAN Converter - source code' from http://hapcan.googlecode.com/files/hapcan_conv.zip
with minor change (added line '#include <string.h>' at beginning of file).
I've compiled it with g++ under linux.
If there isn't a fundamental difference between windows and linux (like litte endian vs big endian) this hardly explains the difference.

You mentioned that the converter cuts out the fake bootloader.
Is this done by writing out address/data starting from 0x1000 (and ignoring everything before)?
This is at least how i understand the code.

Maybe you can provide the original firmware (3.8.0.0-rev0) as hex-file?
This would allow me to check whether my asm-to-hex or my hex-to-haf step is wrong?

Many thanks for your support.

With best regards,

Klaus

[Jacek]

Hi Klaus

If there isn't a fundamental difference between windows and linux (like litte endian vs big endian) this hardly explains the difference.

It is a big endian order (most significant byte is in the lower address)

You mentioned that the converter cuts out the fake bootloader.
Is this done by writing out address/data starting from 0x1000 (and ignoring everything before)?

Correct.

Maybe you can provide the original firmware (3.8.0.0-rev0) as hex-file?
This would allow me to check whether my asm-to-hex or my hex-to-haf step is wrong?

The hex and haf files are attached here. The haf file starts from 0x1000 address and ends with 0x2A39. The hex file contains the fake bootloader (addresses below 0x1000) and additionally configuration bits and ID in eeprom (addresses after 0x2A39). This might help as well http://en.wikipedia.org/wiki/Intel_HEX

[asicdruide]

Hi Jacek,

many thanks for original hex- and haf-files.

Converting your original hex-file with my locally modified converter produced result very similar to original haf file.
Only difference are two bytes at address 0x1008 and 0x1009 which are 0x00 in original haf and 0xFF in my haf
(header comment and checksum is also different, of course).
According to documentation i'd guess that the difference is irrelevant. Anyhow it's easy to adapt in the converter code.
I've added lines

Code: Select all

binBuf[0x1008] = 0x00;
binBuf[0x1009] = 0x00;

before writing out haf-file.

After this modification converter produced result which is 100% equal (except header comment).

This means that my issue is in the asm-to-hex step. I'll have a deeper look into the build mechanics of microchip.
If i'll be stuck somewhere i'll bother you again. ;-)

Again thanks your support.

With best regards,

Klaus

[asicdruide]

Hi Jacek,

...don't know what i did different this time in MPLAB-X
* created new project
* imported sources from git-tree
* build
* compared hex and got 100% match :-)

=> everything is fine, now.

Intended next step:
* hack the EEPROMWrite routine to not write i case same data is already in place (endurance optimization)
* new box-type for state support (to implement walking thru light scenes easier)

I'll share my results.

The more i look into your project the more i like it.
Well designed hardware/firmware, useful modules, open source license allowing to understand, tweak/extend,
very complete and acurate documentation, well defined message structure, enough free space in the flash for own ideas, ...

Thank you for sharing it as open source.

With best regards,

Klaus

[Jacek]

Thank you Klaus