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?
MOD5441X flash via TFTP?
Re: MOD5441X flash via TFTP?
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
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
-
- Posts: 22
- Joined: Tue Dec 01, 2009 2:12 pm
Re: MOD5441X flash via TFTP?
Hi Paul,
Mark
Autoupdate worked great until I managed to get a corrupt image into flash, then it failed. Even the boot failed.The mod54415 monitor supports autoupdate.
I like to use TFTP to recover whenever Autoupdate stops working.No need for TFTP just use the normal load tools.
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?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...
Mark
-
- Posts: 22
- Joined: Tue Dec 01, 2009 2:12 pm
Re: MOD5441X flash via TFTP?
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!
The NBEclipse IDE does not catch this!
Re: MOD5441X flash via TFTP?
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.
[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 Ciliske
Project Engineer
Netburner, Inc
Project Engineer
Netburner, Inc
-
- Posts: 22
- Joined: Tue Dec 01, 2009 2:12 pm
Re: MOD5441X flash via TFTP?
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
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
Re: MOD5441X flash via TFTP?
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
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 Ciliske
Project Engineer
Netburner, Inc
Project Engineer
Netburner, Inc
-
- Posts: 22
- Joined: Tue Dec 01, 2009 2:12 pm
Re: MOD5441X flash via TFTP?
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
Yes, autoupdate from the AIM is better than TFTP or serial flash!
-- Mark