FTP Refuses to load my IMAGE.BIN

Using NET+OS 6.3 and patch http://ftp1.digi.com/support/patches/netos63gnu_patch.zip

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:


Any idea what could be wrong?


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.

Anyone have any useful ideas?


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!

Cameron, if you are still out there - HELP!

I talked to Digi and they say that they are looking into the issue.

Meanwhile, I am hacking on it. I wonder…

Anyone out there get the FTP thingie to work? Did you use image.bin or rom.bin to get it to work?


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.

Let me see if I have it straight.

  1. Take fresh -C module with nothing but the factory FTP app on it.
  2. Compile app with your new FTP code
  3. FTP Load IMAGE.BIN into module
  4. FTP BYE - module reboots
  5. FTP Load ROM.BIN into module
  6. FTP IMAGE.BIN into module
  7. FTP BYE - module reboots
  8. Compile app with old FTP code
  9. FTP ROM.BIN into module (because your FTP code forces it)
  10. FTP IMAGE.BIN into module
  11. FTP BYE - module reboots
  12. From now on, everything is like before ???

Except for step #9. You took care of the ROM.BIN in #5.

Don’t forget to use the ROM.BIN from the platforms/connectme directory!

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.

Ok, lets go over this again -

  1. IF your module is missing the bootstrap,
  2. Use the code I wrote the FIRST time
  3. Load ROM.BIN plus an IMAGE.BIN that includes the STANDARD FTP app.
  4. Reboot.
  5. From now on, you are normal.

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.

The ROM.BIN needs to be loaded only if the bootloader has changed. The ConnectME modules come with a bootloader pre-loaded into the FLASH.

The IMAGE.BIN will be loaded every time the application changes.

The naftpapp application is already pre-loaded into the ConnectME modules (until it is over written by loading another IMAGE.BIN).

I hope this helps,