NetBurner Community Forum

I've seen a fair number of people asking about various oopses with the MOD5441X and NANO54415 where they've managed to put it into an aparently unrecoverable situation (wrong boot port, can't flash, etc.). If it's a software/configuration fault, you can recover it. If you let out the magic smoke or have some other hardware problem, you may have yourself a new board for the drawer of cautionary tales... This post is to give a guide of how to recover from those software and configuration faults.

Step 1: Getting to the alternate monitor
First of all, there is the primary boot monitor, accessable by entering the 'A' (0x41) character immediately on boot. This should allow you to recover the module normally. If for some reason that fails or you cannot enter the 'A' character, the MOD5441X and NANO54415 both contain a secondary boot monitor to allow the user to recover from (virtually) all software or configuration faults. This is the process of getting to it:

1. Power off the module.
2. Short the alternate boot jumper.
3. Power on the module.
4. Wait for the module to finish boot and enter the monitor.
5. Remove the short on the alternate boot jumper.

But where is this jumper?
NANO54415
The boot jumper is a pair of circular pads located near the middle line of the board near the connector. MOD5441X
The boot jumper is the unpopulated header 'TP1', located near the ethernet jack. Step 2: Great, I'm in the monitor. Now what?
By now you've made it to the alternate boot monitor. Some of you already know what you can do in the boot monitor on the other platforms, but the MOD5441X and NANO54415 are special. Their boot monitors also have IPSetup and Autoupdate capabilities (which come in really handy if you want to run tests/applications where networking is disabled). For those of you who don't, this is the output of the help command, where the description is in the left column and the command entered is on the right: The most important of these commands are the 'Setup' and 'FLA' commands (though 'FLA' is mainly superceded by using Autoupdate for these devices).

Step 3a: Recovering from a bad app
Once you're in the alternate monitor you can recover from a bad app in one of two ways: run Autoupdate and reflash the module over the network as usual or enter the 'FLA' command in the boot monitor and upload the app over the serial port.

Step3b: Recovering from a bad configuration
Again, once you're in the alternate monitor you can recover from a bad configuration in one of two ways: update the configuration via IPSetup or running the 'Setup' command in the boot monitor. Note that if you choose to use the 'Setup' command, you will need to save the configuration once you have made your modifications for them to actually be made in the system.

Hi,
I was trying the fix my MOD54415. When everything was working I tried to set the default boot port to UART7 and it stopped working. So I went through the steps you mentioned here but when I install the jumper and power up the only message that I get is

Boot override Jumper installed
doing alternate boot

but it doesn't show anything else. Have I permanently damaged my MOD54415?

Thank you,
TM

This is how I fixed it. I installed the jumper and powered up my MOD54415 and then I connected my NB to my computer using the orange CAT cable provided with the development kit. I ran IPsetup and I could find my NB then I set my uart0 to default boot port using the IPsetup.

I think that makes sense. It means the console port data was still going to uart7

I'm having a problem with my Nano in that Once I am in the alternate boot monitor, it does not stay in the monitor for longer than my boot delay period, e.g. my boot delay is three seconds. Once I get the nb> prompt, no mater what I do I get another reboot three seconds later. How can I fix this?

Could it be the watchdog? When you say "no matter what I do", what specifically do you mean? What happens if you type "setup" before the 3 second reboot?

I can enter the monitor by hitting 'A' and get the nb> prompt. At this point, the system will reboot about 3 seconds later no matter what I do (what type of command I type in, e.g. help , or FLA, or just repeatedly hitting the enter key. I am also getting my keystrokes echoed back to me, e.g. I see FFLLAA in MTTY.

I tried typing setup and I got the menu, but it rebooted right after it was displayed.

And to answer the next question , the only input into the Nano's RSTI pin is my pushbutton manual reset, which is what I am using to reboot before typing in my 'A's.

OK, I figured out the problem, but I'm really scratching my head over the implementation of the boot monitor.

I remembered that my application enables the watchdog in the user config record whenever the static network addresses are changed and stored to flash (which will always be done at least once during initial setup). I went and changed the code to disable the watchdog, wrote new IP addresses, and did a cold boot, and now I stay in the alternate boot monitor.

However... the primary function of an alternate boot monitor (at least as far as I'm concerned) is that it allows you to recover from a failed application. In order to use the alternate boot monitor, one should not have to modify the application that is unable to be programmed into the device using autoupdate.

I want to use FLA to do a serial transfer in the event of autoupdate not working. The rebooting prevents me from doing so. Shouldn't the boot monitor do something to disable the watchdog while it is active? This makes no sense to me.

It looks like if someone were a 150WPM typist and could issue the correct commands fast enough (setup<cr>w<cr>s<cr>) to change the watchdog status before the system reboots, that might work, but that is not exactly desirable, especially if I were to send a file to be downloaded to a user. Talking them through this process would elicit responses like "you've got to be kidding me".

It is also not feasible to increase the wait time before boot. That confuses users when they power on the unit and see a blank screen on my device for any great length of time before the splash screen can be displayed.

Surely there must be a better solution...

P.S. - NOT enabling the watchdog in the config record is not a solution, it is a workaround.

The alternate boot monitor supports a network update. Is there some reason you do not want to do it that way?

If you're referring to AutoUpdate, I typically do use it, but it would not complete because of the rebooting issue.

My basic question is, shouldn't the alternate boot monitor disable the watchdog? Once the watchdog is enabled in flash, it's rather difficult to disable it before it times out. Is there any valid reason for having a watchdog operating in an alternate boot monitor? I can't think of one.