I get the following error when I try to load my image.bin.
_NAAppOffsetInFlash in the linker customization file is set incorrectly.
The application image must start on a sector boundary.
The image.bin created before applying the patch (no changes to my source code) would load, but the web pages used had the stylesheet error that needed this patch to correct. See:
Its possible, actually likely considering the error, that I have used naftpapp.c instead of naftpapp_connect.c. If this is the case, is there a good way to fix this?
Nope, that can’t be it. 6.3 doesn’t use naftpapp_connect.c, that’s only a 6.0f_lsk thing.
I went back to the support site and downloaded all of the patches there, and compared the files in those zips to my 6.3 + the above patch file tree. One thing I notice is that the other patches on the site had an ftp library that was far older than the one on my HD. The one on my drive is dated 2/3/2006, the one from the support site is dated 8/16/2005. Not sure if that would be a problem or not. Adding a debug statement to the FTP process, I got this:
NAAppOffsetInFlash = 65536
Sounds wrong to me. And of course, now that module won’t take an update via FTP anymore. I can’t afford to keep killing modules to figure out what’s going on here.
I am having the same issue. To prevent the killing of the modules I am using the devkit with JTAG, but I have the 64K offset as well.
The problem is that the -C modules do NOT have a bootstrap, and I assume that is what the 64K is for. There is nothing to execute at 0. I think that we need the bootstrap to load into the modules along with the image.bin.
I thought about loading rom.bin, but it turns out that rom.bin is close to 2MB in size!
I’m glad they are looking into it for you. My jtag module is old, and won’t work correctly for FTP no matter what, they say, so I am on hold until I can get another one to debug with. If you hear something in the meantime, please post it here. I’ll do the same.
I got it to work, but it won’t work for a non-JTAG module.
It turns out that the bootloader is missing and needs to be loaded. The problem is that once that is done, the naftpapp reboots and you are screwed.
The rom.bin in the bsp/platforms/connectme directory is the bootloader that needs to be loaded into sectors 0-3. Then you need to load the image.bin into sectors starting at 4.
Without the JTAG you cannot re-run the naftpapp to load the image.bin. I will rewrite the naftpapp and post it.
Having to load two separate BIN files to update an application sounds like a recipe for disaster. I can just see my customers trying to manage that, and failing miserably. Why is it that the bootloader and application aren’t combined into a single image.bin like before?
Cameron at one point told me that 6.0f could be used to code for allME modules, using the lsk for old modules and the non-lsk for new modules. I wonder what 6.0f code does on a new -C module?
Once the ROM.BIN is loaded, it never needs to be loaded again. So you can just update the IMAGE.BIN in the field and ignore the ROM.BIN like on the old ME modules. I don’t know why it isn’t preloaded.
Anyways, here is my patched naftpapp.c file. It will not automatically reboot until the rom.bin and image.bin are both updated. I would assume that this would only be used as the initial file in the factory production, then you would have something to update only the image.bin in the field.
Then I still don’t understand. If your FTP code requires uploading both ROM.BIN and IMAGE.BIN, then if I leave your code in place, every time I upload a new IMAGE.BIN, I’ll also have to upload a ROM.BIN, or the device won’t reboot, right? At least that’s how I read the code.
Once you have loaded the ROM.BIN, you use the old ftp app that loads the image.bin only. ROM.BIN only needs to be loaded once. It is the generic bootstrap code.
I have heard a rumor about a ROM.BIN that lets you recover from a bad image.bin and am investigating. (Digi sent me some source and I am testing.) It would be nice to have this capibility back.
My reply was a bit confused. Step 9 must be required, because at this point you are still running your modified code, and thus you have to load ROM.BIN before a reboot will occur.
I wonder if there is a way to detect if the ROM.BIN is present, so that only one version of FTP ever needs to be produced and will only require ROM.BIN when needed? This procedure will be rough on the guys in the back, who have a hard enough time as it is (these are non-engineers/programmers). I suppose I can make some custom software that has a built in FTP client, but it will still be much more cumbersome than it needs to be. Maybe when I get the paperwork on my support contract finished up, I can get Digi to address this issue in a better way.
Should this process work with the JTAG unit? It doesn’t seem to. I load your modified FTP code, and it accepts the ROM.BIN file ok, but refuses IMAGE.BIN just like the normal code. I wanted to try this with the JTAG unit first, so I can fix it if anything goes wrong.