Home/Support/Support Forum/How to upload image.bin with NET +OS
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.

How to upload image.bin with NET +OS

0 votes
I have a digi me 9210 -C module (without J-Tag) with NET +OS I'd like to update the image.bin file on the module through ftp.

I have followed the instructions in the help:

Upload the image.bin file using FTP:

1.) Type ftp <device ip address>, and press Enter.
2.) When you see the prompt for user and password enter root and password.
3.) Type binary and press Enter.
4.) Type put image.bin and press Enter.
5.) Type quit and press Enter.

The ftp client says the file has been transmitted successfully. But nothing happens.

I have followed the same steps on another module (with JTag). I have updated the flash, removed the JTag and restarted the device. Then I connected to the module through ftp and uploaded the new image.bin and it does work. I could see that the new image.bin would be executed.

Can anyone tell me why it does not work on the ME module without JTag?
asked Dec 30, 2013 in NET+OS by christiaan New to the Community (3 points)

Please log in or register to answer this question.

4 Answers

+1 vote
Best answer

I believe for the ME9210 the only supported carrier board is the "new" one, but I just need to check first. On the carrier board there is either one large off-white block of switches or there are two. Also down by the power plug, is there a MFG P9 block of four pins or not?

Where I am going here is that there is a documented method for recovering a board but it is different for the old VS new carrier board. So I want to ensure I know which one you have.

See the following:

The only thing I believe there may be a mistake. On the new board, on header P3, I believe you want to jumper 18 and 20, not 16 and 20 as described in this document.

Also you'll need to have the stdout serial port connected to a terminal emulater such as hyperterm, so you can see the output. I use serial recovery. It is a little slow but does work. Whatever you do, do not remove power until you are sure that recovery completed.

Also you may want to ensure that whatever you are uploading includes an FTP server.
answered Dec 30, 2013 by dakotas_dad Veteran of the Digi Community (694 points)
selected Dec 31, 2013 by christiaan
0 votes
Hello dakotas_dad,

First of all thanks for replying! I believe I have the "new" carrier board. I see one large white block of switches on it and down by the power plug there is indeed an MFG P9 block of pins. I will look at the link you mentioned for the recovery process.

I got the new image.bin uploaded and it works! I made a mistake by connecting the serial port to the terminal in the NET +OS dev environment. I got no output there. But when I approach the module on via my browser I get the expected web page. So the new image.bin was uploaded to the module. My image.bin includes the ftp server so I can update it afterwards again.

I will look at the emulator hyperterm as you described so I can also see the output from the serial port. It seems that the problem has been solved. Thanks again for your help!
answered Dec 31, 2013 by christiaan New to the Community (3 points)
0 votes
I'd like to suggest you add one of the image program to help you out.Most of the image tool supports to upload image or process image direclty.That would save more time.
answered Mar 7, 2014 by Nana111 New to the Community (3 points)
0 votes
you may also use C:\netos75\bin\netosprog.exe provided with NET+OS 7.5
see also C:\netos75\bin\NetosProg_ReadMe.html

Note: after you quit the ftp client, its clear you will not see any output from the FTP server anymore.

You should also watch the serial port output.
It will tell you that something is getting written to flash and a reboot will take place.
However it might also report some error, e.g. telling you that the header of the uploaded image.bin does not match, so it will refuse to program it into flash.

Also note that the FTP server is sensitive to the filename. It will only accept rom.bin to program boot loader starting with the very first flash block, or image.bin starting with the second flash block (after the boot loader). Newer versions might also accept backup.bin to program a second kernel+application image into upper flash blocks to be executed in case the image.bin was getting corrupted.

Depending on which FTP application version is pre-programmed the behaviour might be different, so check the serial port output for the NET+OS application version/revision beeing reported.
answered Aug 20, 2014 by User143 Community Contributor (132 points)