不具合？解決 　　　　　　　　　　　　　　　　　　　　　　　2010/6/11更新
深刻な不具合

今まで動いていたソフトが急にまったく動かなくなるという現象があり、前後の修正を見ても不具合部分がまったくわからず。時間をかけて調べてみるとcharのポインタに引用符号で記述をするとまったく動かないHEXファイルになるkとが判明しました。不具合のおきるサンプルは以下にようになります。
void main()
{
    int a;
    char buf[32];
    char szDown[] = "key douwn\n";
    char szUp[] = "key up\n";
    
    porta = 0xff;
    trisc = 0x00;
    portc= 0x02;
    strcpy(buf, szDown); //これはOK
    strcpy(buf, szUp); //これはOK
    strcpy(buf, "key douwn\n"); //これはNG
    strcpy(buf, "key douwn\n"); //これはNG
    while(1)
    {
        portc ^= 0x02;
        delay_ms(1000);
    }
}
上記はportcのbit1に接続したLEDを1秒ごとに点滅させるプログラムです。
//これはNG
と記述した部分があると動作しなくなります。
strcpyで szDownのように配列で定義した引数を指定すれば問題はおきません。
問題がおきるのは、"key douwn\n"のように引用符号で括った場合におきます。
さらに条件があります。
strcpy(buf, "key douwn\n");
が一箇所だけしか使われてなければ問題はおきません。2箇所以上使われていると問題が起きる可能性があります。
さらにもうひとつ条件があります。
strcpy(buf, "OK\n");
のように文字数が少ないと問題がおきません。
まとめると、
ある文字の長さ以上の引用符号で括った関数が２つ以上あると動作しないHEXファイルができてしまう。ある文字の長さまで調べる気にはなりませんでした。それより引用符号を使っている部分をszDownのように配列で定義して書き直しました。

この不具合がSDRAM読み書きをするプログラムで頻発したので、とうとう調べることにしました。
HEXコードを調べてみると....
Source Boost Cが生成するHEXコード

:1008100001E11200FF0E00000000000000000000D7
:1008200000000000000000000000000000000000C8
:1008300000000000000000000000000000000000B8
:1008400000000000000000000000000000000000A8
:100850000000000000000000000000000000000098
こんな感じできれいにならんでいます。
特にアドレスの部分
1008100001E11200FF0E00000000000000000000D7
は16バイト単位できれいに並んでいます。

Mikro C では、
同じようにきれいに並んでいることもあるのですが、プログラムが大きくなったりすると、
::1001000043C3C9FFC7B002D00000FCD7C9CF00F07D
:020110001200DB
このように途中で空きができてしまう。
さらに次のアドレスは、
:10011200F250026EF29E0500FF6A0150FE6E005020
で連続とはなっているのですが、半端なアドレスからの16バイトなので大変見にくいです。
一応連続したデータで埋まっています。
以上は不具合が発生しないときです。

次にコードが突然動かなくなったときのHEXデータを調べてみました。（上記のようにアドレスが半端なところから記述されているので見kるのが大変でした）
そしてわかったこと、

コードが連続でなくで飛んでいるところがある。

アドレスの順番が不連続なところがある
例
100番地からのデータ
120番地からのデータ
１３０番地からのデータ
110番地からのデータ

上記の２点が今まで経験したHEXファイルと違うことがわかりました。

そして、これが原因で自作のブートローダーや秋月さんのROMライタで不具合となっていました。

確かに、インテルHEXのデータ形式ではMikro Cが生成するHEXコードは間違ってはいないようです。しかし、こんな汚いコードを吐き出すのはやめてくれー！
このHEXファイルはROMライタを開発しているメーカーにとって、テストデータとしてデバッグをするのにいいかもしれません。これで問題なければほかでも問題なさそうですね。

PC用のブートローダープログラムを直しました。
これを使えば不具合が解消です。
PIC用のブートローダープログラムは変更の必要はありません。
ご注意
　今回わかったことからすると、ROMライタ自身のプログラムがきれいなHEXコードを前提に設計されているとMikro　Cが吐き出したHEXファイルでROM焼きができないことがあると思われます。ROMライタの選定の際はご注意を！
　
今後
　とりあえす今までの問題が解決したので、もう少しつかってMikro　Cを使ってみようと思っています。これのいいところはサポートしている関数が多いことにあります。また、関数の使い方もシンプルです。
　開発の形態は、自作のブートローダーを使って直接ROMライタを使わないようにします。