microchip社の8bitマイコンについて質問です。PIC18F67K22を開発で使用しておりまして、自社開発ソフトの変更をしたところバグが発生しています。ソフト内容の問題と思い確認しましたがプロジェクト自体が壊れているみたいで原因の特定が出来てません。今回のソフト修正について一部機能の追加をしただけでメイン関数とは別で動く特殊モードになります。このソフトのベースとなる旧ソフト（ソフト①）も存在し、旧ソフトに機能追加した物を新ソフト（ソフト②）とします。バグっているのは新ソフトです。新ソフトの追加した部分のみを旧ソフトに移植（ソフト③）すると正常に動作します。ソフト③とソフト②をファイル比較ソフトを用い、照合しましたが、CファイルやHファイルに相違点は見つかりませんでしたが、アセンブラファイルを比較するといろいろと違いがあるように見受けられます。また、ソフト②と、ソフト③で、内容は全く同じにもかかわらずチェックサムが違う状況です。 このようなことが起こり得るものかご確認頂けませんでしょうか。何が原因でこのようなことになるのか推測できることはありますでしょうか。

起こり得ますし、現象だけ見ると「ソースではなくプロジェクト設定の差」で挙動が変わっている可能性が高いです。

理由を説明します。
Cファイルやヘッダが同一でも、Microchipのコンパイラやリンカは以下のような条件で生成されるアセンブラやHEXが変わります。

1つ目はコンパイルオプションや最適化設定の違いです。
同じソースでも、最適化レベル、メモリモデル、スタックやヒープの設定、プリプロセッサ定義（プロジェクトプロパティで定義しているマクロ）などが違うと、生成されるアセンブラはかなり変わります。その結果、微妙なタイミングや未初期化変数の使い方が変わり、片方だけバグになることがあります。

2つ目はリンカ設定の違いです。
PIC18ではリンカスクリプトやメモリマップ、配置するライブラリの有無などが違うと、関数や変数の配置アドレスが変わります。スタックの位置や割り込みベクタ付近の配置が変わると、隠れていた不具合が出たり、逆に出なくなったりします。アセンブラレベルで見ると「いろいろ違う」状態になりますし、チェックサムも当然変わります。

3つ目はコンフィグビットやID領域などの違いです。
CONFIGビット、IDLOC、リセットベクタ周りの設定がプロジェクトごとに微妙に違うと、HEXファイルの一部だけが変化し、それがチェックサムの違いになります。MPLABの設定や別ツールで生成した設定ファイルを読んでいる場合も要注意です。

4つ目はプロジェクト自体の壊れや中間ファイルの残りです。
プロジェクトファイルが一部壊れていたり、古いオブジェクトファイルやライブラリが再利用されていると、ソースを変えていない箇所まで影響が出ます。クリーンビルドで改善することもあります。

今回、機能を移植したソフト③は正常で、ソフト②だけおかしいということは、ソースよりも「ソフト②のプロジェクト設定かビルド環境」に差があると考えるのが自然です。

対処としては
・ソフト①、②、③のプロジェクトプロパティを一つずつ見比べる（コンパイラ、リンカ、コンフィグビット、プリプロセッサ定義、最適化レベル、メモリ設定など）
・一度ソフト③のプロジェクトをコピーして、そこに新機能を入れ直してソフト②相当を作り直す
・クリーンビルドを行い、古い中間ファイルを全削除する

といった手順で原因を絞り込むとよいと思います。