Home/Support/Support Forum/New bootloader image won't correctly recover using DHCP/TFTP
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

New bootloader image won't correctly recover using DHCP/TFTP

0 votes
I've been working on testing the ability to recover bad image.bin uploads using the bootloader's DHCP/TFTP recovery mechanism. I'm using tftpd32, which didn't work on Vista, but on XP it worked to upload a new image on modules that had an OLD bootloader image. But after updating the bootloader using a newly compiled (from NET+OS v7.3) rom.bin file, the recovery sequence does send out a DHCP discovery request, and the DHCP server program offers up a valid IP address, but the module ignores the offer and tries again 2 more times before failing and moving on to attempt a serial recovery.

When capturing debug code during the recovery attempt, I see "TFTP...", indicating the the downloadImageUsingTftp() routine is being called in blmain.c. Then after the 3 attempts at getting IP parameters via DHCP, I get the message "DHCP fails", indicating that the board_initialize_dhcp() call failed.

Has anyone else had this problem using a bootloader built from v7.3?
asked Oct 23, 2008 in NET+OS by jfichtner New to the Community (12 points)
recategorized Dec 18, 2013 by tuxembb

Please log in or register to answer this question.

29 Answers

0 votes
Two questions

1) Have you pulled down, applied and rebuilt with all patches currently available on the Digi Web Site for NET+OS V7.3?

2) On what device are you testing?
answered Oct 23, 2008 by sparkys_dad Community Contributor (99 points)
0 votes
No I haven't yet applied any patches. I am close to release with this product and if possible I would like to be able to release it without any patches applied, since having to apply patches would add to the complexity of reproducing the design environment. Of course it looks like I may need a patch to fix this problem. I did look through the available patches and I didn't see any that addressed my exact problem, although I did see that the bsp updates patch addresses a problem with storing an image downloaded by TFTP, which I'll probably need anyway.

I am developing on the Connect ME. I have gotten this result on three different Connect ME modules, two of which are JTAG modules, one is a regular -C module.
answered Oct 24, 2008 by jfichtner New to the Community (12 points)
0 votes
Did you solve this problem? I'm running into the same situation.
answered Nov 25, 2008 by nfgaida New to the Community (27 points)
0 votes
Actually, after extensive troubleshooting and learning about DHCP and BOOTP standards I ended up learning that the boot file name can be specified either in the header OR as an option (option 67). Previous Connect ME bootloaders worked when the boot file name was only given in the header, but a bootloader built with NET+OS 7.3 will only pull the file if the bootfile name option is included.

I drilled down in the NET+OS code and I can't figure out what changed, because the code in blmain.c and in blDhcp.c doesn't seem to have changed. In fact the hasTftpInfo() function in blDhcp.c seems to look for the filename as an option, and then in the header, which seems like it should work.

I am using Tftpd32, as suggested in another post, and under "additional option" I have "67" and "image.bin". This will add the boot file option to the DHCP response, and this did trigger my NET+OS 7.3 bootloader to pull the image.bin file from the TFTP server.

Note that I am running Tftpd32 under (a virtual install of) Windows XP. I first attempted using it with Windows Vista, but found that there are issues with the program under Vista.

Also note that I never actually recovered the module, but that may be due to the other known issue (which is addressed with a patch) regarding TFTP recovery. But adding the boot file as an option did get the bootloader to actually retrieve the boot file from the TFTP server.
answered Nov 25, 2008 by jfichtner New to the Community (12 points)
0 votes
The "additional option" under Tftpd32 was what was missing for me. Setting that and triggering a reset from my digi board, it downloaded the image, applied and reset itself. I almost missed the download, it happened so fast I barely saw a flash as the progress window opened and closed.

I do have all of the patches applied, so I have the TFTP recovery bug covered I guess.

Now to figure out which pins match to GPIO so I can force an update via TFTP if certain pins are set.

Thanks for the response.
answered Nov 25, 2008 by nfgaida New to the Community (27 points)
0 votes
By default (starting at NET+OS v7.2 I think), it checks for pins 18 and 20 pulled low during startup to automatically trigger an image download. This is done in the blmain.c file, which is in the workspace, which means of course that you can customize it if you wish.
answered Nov 25, 2008 by jfichtner New to the Community (12 points)
0 votes
Hi,
i had almost the same problem last month. Is wery important to install all patches to Net+OS!!! There is several updates of bootloader and etc. After this upload rom.bin to digi module (this may update bootloader) After this try upload image.bin.

But image recovery via tftp is not normal process for upload new firmware to digi module - its only failsafe recovery. For uploading new firmware you have to add FTP upload capability.
answered Dec 2, 2008 by kubiajir Community Contributor (61 points)
0 votes
I have all the patches applied, and with that it seems to work.

The rom.bin file is the bootloader (as I understand it) so uploading that file will replace the bootloader on the module.

I wanted the TFTP update to be working in case I needed to update the application image. (Lets say in case my FTP upload capability wasn't working correctly, etc).
answered Dec 2, 2008 by nfgaida New to the Community (27 points)
0 votes
I seem to be having the same issue.

My app was working with 7.0, but Digi began shipping new modules (distinguishable by having a T under the barcode) and when you load a 7.0 app into one of these, it doesn't work. Digi said I needed to upgrade to 7.3, so I did. That seemed to work, but apparently it will work for a while, then fails again. I power up, yellow and green both on, after a bit, yellow goes off for a sec, then comes back on, and from then on, both lights on solid. A working unit will have the green turn off when the yellow comes back on, then flash as it begins communicating.

Since this was done on straight 7.3, I've since loaded all the patches, and rebuilt my image.

Trying to recover these modules, I got Tftpd32 running, and it acts like it is pulling in the fresh image, but nothing changes.

I suppose I could try the 7.4 that just came out, but it was a PITA just having to update to 7.3 a few weeks ago.
answered Dec 11, 2008 by jwormsley Community Contributor (78 points)
0 votes
I think you have a different issue there.

My unit had solid orange+green lights from power-on. Putting the connectme in the DevBoard and looking at the serial output, I could see that there was an abort exception happening almost instantly after power-on.

If you are able to get a tftp32 response, that is more than I got. I believe that the bootloader was corrupted somehow, though Digi says that if it was it wouldn't print anything. However their recovery method failed to work as well, it just went right to the abort exception. (on a working module, I was able to force the recovery every time).

Have you checked to make sure you are providing an updated image to tftpd32? I know I've done that a few times: build new release image, force module into recovery, wait as it downloads image and reboots, only to realize that I had forgotten to put the newly compiled image.bin in the tftp root folder.
answered Dec 11, 2008 by nfgaida New to the Community (27 points)
...