NetBurner Community Forum

When updating the firmware image on a NANO, if the NANO is reset while writing the image to flash, the image in flash is corrupted, as you would expect. When module boots up it goes to the monitor program. It is visible with the Discover webpage, but with an odd ip address. When you click the ConfigPage button, the webpage hangs until it times out. Is this caused by the odd ip address (169.x.x.x) or because the image also writes the configuration data? The module was configured for DHCP.

This comes up because we have a customer that wanted our product to support 2-images so that there would be a backup image to load if the primary failed. An acceptable alternative was to be able to boot to a monitor/bootloader program when there is no valid image and be able to load a new image from the monitor via Ethernet. That seems to be how the NANO functions when we convert it from a v2.x module to a v3.x module.

Is there a way recover from a corrupt image without shorting pins on the module during powerup and going through the v2.x to v3.x conversion process?

Using v3.3.8 of the tools.

Hello,

If the image is corrupted, the nano will boot to the boot monitor app, which does not have Internet connectivity to Discover. You can indeed load a new app via Ethernet at that point. If you don't know the IP address, use the localdiscover utility. If a newer module, the monitor will accept a .bin file and you don't need the conversion. https://www.netburner.com/NBDocs/Develo ... totoc_md30

The localdiscovery utility reports there are "no known devices on the Network". I don't know if the Nano I have is a newer one. The monitor is version 1.05, dated July 2020. Using monitor command "setup", it shows all network parameters as zero (IP, Netmask, etc). Using FLA, the only application I can load successfully is NANO54415-3p0-Update_App.s19.

With that monitor version should be able to just update to the device.
Using the current 3.X tools.
The 3.X discovery might not work from the monitor.
Does your network have a DHCP server on it?

You can also use the 2.X autoupdate tools to load the S19 you loaded via FLA.

Yes, our network has a DHCP server. Most all our products use DHCP.
Is it correct to say that, should the rare event of a power interruption occur while writing an image to flash, there is no way to recover the module while it is in the field?

If you know the ip address, you should be able to easily recover.
Assuming this is aonbe of the coldfire based devices.
(if its a MODM7AE70 or SBE70LC you may have to set the recovery jumper on the device.)


If the setup under the 'alternate' monitor is set for DHCP (IE the ip address in zero)
Then in case of a failed recovery....

Reboot the device.
Find it.
Then use tools to upload new code.

How do you find it?
Discover.netburner.com won't work.
Any of the find examples under pctools/find or ... the old ipsetup will all work.

So how can you upload new tools...
The newest monitors (yours is new enough) will work with both the old autoupdate and new web based methods.
So:
autoupdate(requires an _APP.s19 version of your app, you can force the 3.0 tools to make one of these)

Web methods:
use the wget or curl like the 3.0 tools do.
(or use eclipse with the ip address manually set)

wget command to make this happen is:

wget.exe --post-file=<binfile> <ipaddr>:20034/appupdate.htm

On my machine on the project I'm currently working on:
wget.exe --post-file=obj/release/UnitspeedTest.bin 10.1.1.169:20034/appupdate.htm

Works (I just tested it)

Just a note one of the very common wget's for windows has a 64K limit and will fail.
Use the exe we provide with our tools..

For curiosity, when you force a 3.x tool to build an _app.s19 version, is the _app.s19 version still hold the feature that are unique to 3.x tool. eg sign image

I don't think signed image will work if you force a _APP.s19