EFFS-AppUpdate example bugs

Discussion to talk about software related topics only.
Post Reply
khoney
Posts: 125
Joined: Fri Sep 11, 2009 12:43 pm

EFFS-AppUpdate example bugs

Post by khoney »

FYI, the EFFS-AppUpdate example could use some modifications. I discovered one problem through use of the example in my program and I can foresee another problem.

1st problem - If the update fails (for instance, if you have a file with the wrong platform name), the error detection is correct the first time you try the update. However, if you remove the SD card and put the correct file on and reinsert it, the update will fail again, even if the file is valid. This is because there are two variables, tmp_buffer_start and tmp_buffer_end, which need to be initialized to zero at the beginning of the UpdateFromFat routine, otherwise they will have values left over from the first update attempt, and the program does not read from the correct file location on subsequent attempts.

This bug only shows up if you do not power cycle between update attempts. In my case, I autodetect card insertion and any time there is an S19 file present, I will try to upgrade. For testing purposes, I intentionally put the wrong platform name in my S19 file, and the 1st time I got FAT_UPDATE_WRONG_PLATFORM error, but when I removed and reinserted I got FAT_UPDATE_BAD_FORMAT due to the variables not getting reinitialized.

2nd problem that I see is only related to MOD5270 vs MOD5270B. If your platform is a MOD5270 and you try to update with a MOD5270B file, you won't get an error because the platform check will stop at the end of the platform name stored in ROM (which in this case is MOD5270), so it will think a B version is valid.

That is all... :)
Post Reply