NetBurner Community Forum

This morning I encountered a corrupt application image and used the monitor to setup tftp.

Then I discovered that the NFLA command is not present in the MOD5441X monitor.

So, I am wondering: What happened?

I was able to recover using mttty for a serial download, but where is the support for the NFLA command in the MOD5441X monitor program?

The mod54415 monitor supports autoupdate.
No need for TFTP just use the normal load tools.

(In reality you never see the MOD54415 monitor... what loads after hitting 'A' is a full application
that is loaded from the unbrickable serial flash.

You can even get to the alternate monitor with a zero time delay and corrupt config record by shorting the two pins next to the ethernet socket and hitting reset...

Paul

Hi Paul,

The mod54415 monitor supports autoupdate.

Autoupdate worked great until I managed to get a corrupt image into flash, then it failed. Even the boot failed.

No need for TFTP just use the normal load tools.

I like to use TFTP to recover whenever Autoupdate stops working.

You can even get to the alternate monitor with a zero time delay and corrupt config record by shorting the two pins next to the ethernet socket and hitting reset...

Yup, tried this this earlier today, and it works great. However, no NFLA command. Why was the NFLA command removed? It is my preferred method to recover when Autoupdate is not an option. Under nb> setup, option #4 and #5 are still present. I can set the IP for the TFTP server and the file to request. There is just no command available within AIM V1.00 that will retrieve via TFTP. Why did this go away?

Mark

BTW the root cause of the issue with a non-bootable (and wedged autoupdate) is to simply define a main() in a C file __and__ a main() in a C++ file.

The NBEclipse IDE does not catch this!

A main? or a UserMain? If it actually was just main, then the issue isn't that you had it in a C and a C++ file, it's that you had it at all. main() is defined in main.c in the system directory and is used to boot the OS. If you created a main() function somewhere else, it will happily override this function into oblivion. Also, unless you declare a function as 'extern "C"' in a C++ file, they don't actually have the same name, and therefore will not collide from a compiler's perspective. This is a correct (although bizarre) behavior. As a result, NBEclipse will have no knowledge of the "collision".

[Edit]: I've actually had something pointed out that I did not realize. While the C++ compiler will mangle names of functions, it will specifically not mangle the function called main. Therefore, regardless of whether or not it is declared as 'extern "C"' in a C++ file 'main' will override the system 'main' defined in the library.

Dan,

Yes, you are correct- I was porting a linux library to ucOS and one of the C++ examples had a main() in it that I had forgot to change.

I am still wondering why the NFLA monitor command was dropped in the MOD5441x. Recovering an image via TFTP is much much faster than performing a serial flash- especially at 57.6 Kbaud.

-- Mark

Paul explained this one previously; though, I agree it would still be a nice feature just to say that its available. Simply put, Autoupdate works with the alternate monitor. The alternate monitor will always be available unless the hardware itself has failed. Therefore, flashing over serial is unecessary. Also, for the MOD5441X and NANO54415, from a construction point of view (not the users, unfortunately) recovery from TFTP was simply not added to the alternate monitor application.

Can you give me an example in your use of where recovering by TFTP is preferrable over using Autoupdate? I'm not saying there's not one; I just can't think of any.

-Dan

Dan, thank you for pointing out that autoupdate works from the AIM. I totally didn't get that from Paul's earlier comment. So now I know that I can boot into AIM using the TP1 jumper or by pressing "A" and then run autoupdate per usual while the MOD5441x sits at the AIM nb> prompt.

Yes, autoupdate from the AIM is better than TFTP or serial flash!

-- Mark