Home/Support/Support Forum/FTP Refuses to load my IMAGE.BIN
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

FTP Refuses to load my IMAGE.BIN

0 votes
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?

asked Nov 8, 2006 in NET+OS by jwormsley Community Contributor (78 points)
recategorized Dec 18, 2013 by tuxembb

Please log in or register to answer this question.

17 Answers

0 votes
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?

answered Nov 8, 2006 by jwormsley Community Contributor (78 points)
0 votes
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?

answered Nov 9, 2006 by jwormsley Community Contributor (78 points)
0 votes
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!
answered Nov 10, 2006 by egawtry Veteran of the Digi Community (349 points)
0 votes
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?

answered Nov 13, 2006 by egawtry Veteran of the Digi Community (349 points)
0 votes
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.
answered Nov 14, 2006 by jwormsley Community Contributor (78 points)
0 votes
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.

answered Nov 14, 2006 by egawtry Veteran of the Digi Community (349 points)
0 votes
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?
answered Nov 14, 2006 by jwormsley Community Contributor (78 points)
0 votes
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.
answered Nov 14, 2006 by egawtry Veteran of the Digi Community (349 points)
0 votes
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 ???
answered Nov 14, 2006 by jwormsley Community Contributor (78 points)
0 votes
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!
answered Nov 15, 2006 by egawtry Veteran of the Digi Community (349 points)