Firmware mismatch Linux and Windows

#1

I have an axoloti core and and stm32 discovery board. For simplicity i compile the firmware under linux where i have two up-to-date versions of the axoloti app one compiled with each firmware. Under windows i run the latest windows .msi version from github. Ideally i would like access one object and patch library with the two boards and prefer to work on windows as i am running other audio software there.
What would be best practice to achieve this?
At the moment all three axoloti apps report different firmware IDs:
Windows: 21C46C25
Linux (Axoloti Core): 7C099B1F
Linux (stm32 discovery): DBC5E6A4

#2

I looked for the reason why different firmware builds across host platforms are different, and found it is because the date and time of the build is inside the binary, checking in a fix now. Will be solved in the next release...
The discovery board needs a different binary, and I'm currently not looking to unify firmwares, because I fear that will slow down development, sorry.

#3

are there some limitations to this? or pre-requisites?
I just pulled the latest dev version, and built on both linux and mac OS X, and I'm still getting different firmware CRCs

also I wonder (out loud, as I dont have a solution, or really know if this is practical)...probably my 'bigger' issues,is flashing when moving between versions of axoloti (ok, I'm probably different here, as I'm running versions for testing etc).
I wondering if its possible to somehow CRC just the interface, rather than the binary.... which I guess in this case would be the linker map... and it particular it would/should only be the those symbols that the patch can access.
... of course, easier to say than do, Im certain :slight_smile:

#4

ok, did a bit more digging, found the CRC issues was due to me running chibios 2.6.8 on linux, and chibios 2.6.9 on mac OS X.. upgraded chibios and CRCs now match :slight_smile:

the move to 2.6.9 was done on the 17th Jan... so if you are running in dev on multiple platforms, worth deleting chibios and reinstalling. (Id 'refreshed' my mac install a while back, but don't use my linux so much so thought to update it)

(release builds should be consistent, so no issue)

#5

A common approach would be to assign a unique version number per firmware release in a format consumable by a human and retrievable in code, e.g. you already appear to mark them as things like 1.0.0.1. Any interfaces would then have separate version numbers ideally with some clear definitions on which version number breaks the interface. Checksums like a CRC (or signing) would only be used "behind the scenes" as a mechanism to check integrity of firmware at transfer time, load time, etc.