AutoUpdate MOD5234

[joepasquariello]

I'm doing MOD5234 development, and occasionally when I make a small change to the program, rebuild, and update with AutoUpdate, the update will fail. I've seen this occur with trivial changes to the program. When AutoUpdate fails, I can still load the new version with the serial loader. Do others see this?

Joe

[Ridgeglider]

How does it fail? I've found that if the AppName is too long, NBFind can fail. I can't be specific, but I think I can recall apps that look for input from the user, gets() maybe? that might prevent other tasks from running, and then autoupdate will fail. That said, I thought most of those get(), getchar(), fget() type functions allow other tasks to run, so not sure... I work with the 5234 quite a bit and it generally seems like AutoUpdate works well. I also find that if I use DHCP and setup a run config that specs an IP, that later, DHCP might assign a different IP. When it does, then autoupdatre will fail unless you reconfigure the IP spec'd in the run config. I dont think there is a way to spec the DNS name in the search dialogs that the run config setup offers. If so, it seems like it would eliminate this potential error.

[lgitlitz]

What exactly is failing? Do you have any external hardware on the processor data bus? I am assuming that your application is corrupt after the autoupdate and you must serial load through the boot monitor. This means that the whole application was received by the NetBurner, checksum passed and then a failure occurred during updating the flash memory.

Are you using the watchdog timer? The watchdog timer can trigger a reboot while writing to flash since it is not being serviced. It may even be possible to damage the flash memory if this is occurring. Look at the AutoUpdateFeatures example to see how you can use a callback function to service the watchdog while writing to on-board flash.

Do you have any active level 7 interrupts? While writing the application to flash USER_ENTER_CRITICAL(); is called. This will set the interrupt mask to 0x2700 and block all maskable interrupts. Level 7 interrupts are not maskable and may interfere with the flash writing process. There is another shutdown callback function that is triggered by auto-update, this is also shown in the example. You should use this to disable all active level 7 interrupts, you may also want to use this to close resources such as open sockets or file system activity.

Is your application using any of the the low-power processor features or changing the CPU clock speed? If this is the case you would want to use the autoupdate shutdown callback to return the settings to default before proceeding with the update.

[joepasquariello]

Hi Larry,

I'll try to answer all of your questions.

AutoUpdate is timing out and reporting that it failed. There is no external hardware. I'm just running a MOD5234 on a DEV-70 board. No, the application is not corrupt after the failure. I can press the reset button and the app will restart and run normally, so I guess that means the AutoUpdate never really begins. I can try repeatedly and the same thing will happen. I can always upload a new app by pressing the reset button and loading via serial loader.

No use of watchdog timer. I'm in the early stages of developing an application, and so far I'm just using serial ports 0 and 1, and the web server. No other use of hardware except assigning pins 23 and 24 as GPIO to turn LEDs on and off.

No active level 7 interrupts.

No use of low power features or changing the clock speed.

What's really strange is that I will make an absolutely trivial change, and the problem will occur. I'll undo the change and then AutoUpdate will work. The first time I noticed the problem I had just put code to toggle an LED in each of two tasks, where both toggles had previously been in one task. That was the first time I noticed the problem. I moved the one line of code that toggles the output (via the pins array) back to the original task, and the problem went away. I concluded that the problem had something to do with the pins functions, but later it happened again when all I did was add one variable to count communication messages or something like that. Undo the change and the problem goes away. Very odd.

If I can get it to happen in a simple application, I will send you the whole app.

Joe

[Chris Ruff]

Does this happen when you run a different app?

I have had problems in the past where either automatic variables, especially arrays, are overrun by my code and moving around printfs, moving variables around, simply adding a space somewhere and re-compiling makes the lock go away (until it inevitably returns later). And it has always been my code that is the problem. loose pointers are famous for this behaviour as well, always initialize pointers to something safe and always check them before using them.

Another possibility is that a task 'owns' the processor, but not all of the time due to my code, again. You can tell if this is it by placing an OSTimeDly(n) in each task. If the problem never recurs, and removing the OSTimeDly() calls makes the problem eventually recur, that was the issue.

Just some thoughts....

Chris

[joepasquariello]

Hi Chris,

When I have this problem, there doesn't seem to be any problem with the application, just with loading apps via AutoUpdate. Both before and after the problem occurs, the applications run fine. That's what strange about it. I'm making changes to the program that are not bug fixes, but rather just minor changes, and those changes work as intended, but for some reason they seem to break AutoUpdate. There's no clear answer for no, so I'll just keep going and see if I can document it better.

Joe

[tod]

This sounds similar to this thread and behavior I'm seeing on a 5272.

Can you hit the reset switch on your dev board and then try AutoUpdate again and get it to work, or do you HAVE to use the serial method? I ask because of the similar behaviour I've seen recently only after AutoUpdate fails I can get it to work the second (or maybe the third time). Also out our curiosity are you running a web server on this app? Also are you on Windows 7?

If I'm not mistaken the AutoUpdate process has several steps that I've just tried to detail on the wiki, maybe someone from NetBurner can verify this for me. I'm mentioning this in response to your comment about the Autoupdate process not starting.

[pbreed]

Key question to help me under stand...

Does the autoupdate failure occur over and over again if you don't change the running app (and just reset between tries)

If the answer is yes, then if it fails does the failure track the app running on the board, or the app you are trying to autoupdate?
IE if its not working can you reset the board and download a different previously working app via autoupdate?


If the failure tracks the app you are trying to upload, then a key question is are you using a bunch of C++ templates etc... in the app.
If the exact answer is yes to both questions then open a support request and make sure to include the MAP and ELF files.
(In the past the compiler somtimes includes odd sections in the output, the linker file does not cover this odd case and then
leaves large holes in the memory image causing compcode to screwup, it used to crash compcode... I think we fixed that.
We may have moved the problem to AA so this is a wild guess as to what is wrong... The autoupdate S-record to binary conversion does not like big
holes in the record.....)

We have had a few reports of strange autoupdate problems in the last month (3 reports), I suspect something somehow got broken, but so far its been
too random and un-reproducible to find any common thread or to reproduce. I have yet to see any failures here so if someone has a reproducable
version of this I'd love to see it.

[joepasquariello]

Sorry for the long delay in answering your replies. I got tied up on something else.

Tod,

I'm pretty sure that once the problem occurs, it keeps occurring, and the only way I can update the app is to press the reset button and trap into the serial monitor. I can't be as definitive as I would like because I haven't spent very much time trying to characterize the problem in detail. I've had to try to keep my project going. Yes, the project includes a web server and yes, I'm running NBEclipse on Windows 7.

Paul,

Yes, the AutoUpdate failure occurs over and over again. I'm pretty sure the problem tracks the app that is on the board. If I can't use AutoUpdate with app #1 on the board, I can reset the board, load app #2 serially, and then AutoUpdate will work with app #2 on the board.

I'm not using any C++ templates. So far I'm just doing a bunch of serial comm stuff and doing newbie tests with web pages.

Joe

[zoanie]

I had this same problem. The fix for me is related to how soon the stack can get a valid IP DHCP address. Some of the NB examples will fail to get a DHCP address in before the program starts the AutoUpdate thread. Note the below differences for startup function UserMain():

// This is the default. It will occasionally have problems getting a DHCP address before starting AutoUpdate():
void UserMain( void *pd )
{
InitializeStack();
OSChangePrio(MAIN_PRIO);
EnableAutoUpdate();
...
}

// This version allows more time to receive a DHCP address. It has never failed for me.
void UserMain( void *pd )
{
InitializeStack();
if ( EthernetIP == 0 )
{
iprintf( "Trying DHCP...\r\n" );
GetDHCPAddress();
iprintf( "DHCP assigned the IP address of: " );
ShowIP( EthernetIP );
iprintf( "\r\n" );
}
else
{
iprintf( "Static IP address: " );
ShowIP( EthernetIP );
iprintf( "\r\n" );
}
OSChangePrio( MAIN_PRIO + 1 );
EnableAutoUpdate();
...
}