8
Fast-Nop
168d

Wasted a day as Shitlock Holmes with the build chain.

It would not reproduce the firmware hexfile that had been checked in. Reverse engineering that along with the mapfile to find out the cause, it was a const string that was guarded by an ifdef from another file that was auto-generated as prebuild step via a script that fetched some version control info.

Or, it would have been if the installation instructions had been correct and someone had described that no spaces in the absolute path name of the project are allowed. Otherwise, that shit just failed silently.

I then had to reverse engineer the intended workflow from the commit history in the version control to figure out that the last dev obviously hadn't quite understood the project specific workflow and how the version control interacts with these build scripts.

At least, I finally did get a matching hexfile.

Comments
  • 3
    But actually, that wasn't as bad as the previous time where I got a hexfile mismatch. That was in the code part, not in the data part, so I had to diff the assembly listing (generated from the sources).

    OK, first, the linkage order was totally different, so I fixed that and got the diff down to one small portion.

    Turned out that in the startup assembly, some instructions were different. That assembly file was auto-generated by the IDE as per the IDE settings, and some asshole had forgotten to check in the project settings properly (hence also the screwed up linkage order).

    So I had to trial and error my way to figure out which checkbox was responsible until it finally matched.
Add Comment