NetBurner Community Forum

MOD5234 monitor is set to wait for 2 seconds before loading application from user flash. However, the monitor appears to be waiting indefinitely. After 10 minutes, even, I can enter 'A' and access the monitor. If I then BOOT, my app runs just fine. Everything hangs again as soon as I power cycle.

What would cause the boot monitor to refuse to load my application, and instead just wait forever for 'A'? I suspect some potential hardware problem, because I have this same application on a couple hundred other Netburners and haven't experienced this issue. Also, even with this one 'troublesome' Netburner module, it acts differently depending on what application I've loaded. Other versions of my firmware do not 'hang' when loaded by the monitor.

Any help much appreciated!

Also:

The monitor has an 'flm' command that allows you to reflash the monitor. Where can I find the monitor S19 file? Is there some possibility that the monitor application just needs to be reloaded?

Does the problem occur if you run the module in a netburner development board? There may be external signal conflicts if you have it plugged into your own carrier board.

Unfortunately, I don't have a stand alone Netburner development board. The only development I've ever performed has been with the Netburner module seated on my product's own carrier board. What external signal conflicts could cause this to happen? My board has connections to J2 pins: 3, 4 (serial); 21, 22 (serial); 25, 26, 27, 28, 30, 31, 32, 33, 34, 35, 37, 40 (GPIO); 39, 42 (I2C)

Also, even since yesterday, this "monitor locked up" issue is a bit more concerning than what I had imagined. We are seeing a short term mortality rate in the field much higher than what we've traditionally seen. I'm questioning a recent rev to the firmware. This recent rev has a bit of code that runs on startup that modifies the ConfigRecord to obfuscate the monitor function as follows:
1. moves it to port 1 instead of our typical debug port 0
2. sets a non-standard baud rate of 11520
3. shortens the wait time from 4 seconds to 2 seconds
4. invokes quiet boot mode

Perhaps this bit of code, because it runs soon after the board is powered, or perhaps because someone power cycles the board as it runs, is causing some issue? Code looks like this:

// create new config record and copy data
ConfigRecord newRec;
memcpy( &newRec, &gConfigRec, sizeof( newRec ) );

// Change parameters
if (g_fwDevelop)
{
newRec.ser_boot = 0; //monitor on port0 (debug)
newRec.baud_rate = 115200; //std baud rate
newRec.wait_seconds = 4; //4 seconds before loading application
newRec.m_q_boot = 0; //boot w/ messages
}
else
{
newRec.ser_boot = 1; //monitor on port1 (host)
newRec.baud_rate = 11520; //non-std baud rate
newRec.wait_seconds = 2; //2 seconds before loading application
newRec.m_q_boot = 1; //quiet boot
}
// Write new values to Flash system configuration sector
UpdateConfigRecord_Num(&newRec, 0);


The problems I have with the monitor waiting forever for 'A' only occur when it has been configured in the 'else' configuration. The configuration has been invoked correctly as programmed, it just doesn't start my user application.

Thanks again, in advance, for assistance on this issue.

Writing to flash immediately upon power up is always extremely error prone; power may be unstable, user may start/stop quickly, etc. There has been more than a few threads on this topic in the forum. Based on this new information I don't think its a h/w issue.

There is a way to test this to get more info. Take a new board right out of the package with no modifications. Run the code yourself in the lab, ensuring no power problems. Does the problem occur? If not, then that makes a case for user/power issues.

Even so, are you knowledgeable enough about how the boot monitor functions to guess at why it wouldn't load my program from user flash? What would cause an infinite timeout as it waits for 'A'? If I use the boot monitor to read the area of flash that stores the monitor parameters, I can see the timeout values change as I modify them. Is it possible that some other area of flash besides the four parameters I modify could get corrupted and influence boot monitor behavior? And, why would the behavior cease once I flash an alternate version of firmware to user flash?

Do you see anything wrong with the snipped of code I posted? Hopefully, I've read the appropriate config record, modified parameters, and re-written flash in an appropriate manner. The fact that when I compile and download code that doesn't run through the 'else' portion of the snippet the strange monitor behavior ceases concerns me.

Thanks again. If I post my name, business, and telephone number, is it possible to talk?

Hi,

I don't think I know enough to look at the code and know exactly what is going on. I was just trying to come up with some tests to cause a change in behavior at a high level to try and narrow things down. I have not written code to modify those settings before. Maybe you could be off by the size of the variable you are writing, and it isn't waiting forever, just a very long time? Sorry I can't be of more help more. I don't see any obvious errors in the code. You could also try experimenting by changing only one of the parameters at a time and see if a particular one makes a difference. Only change the first parameter, test, change the second parameter, etc.

Writing to flash every time the device loads seems a bit abusive to the flash.
Other than that, is there any chance that serial line 1 has bytes/activity/is being held high and preventing the boot monitor from running? (not sure how this is possible but...)

Have you tried leaving everything alone except leaving the serial port at 0?
newRec.ser_boot = 0; //monitor on port1 (host)
both configs to remove the serial port as a suspect? (same train of thought as changing one at a time)

Does the boot fail every time? On a hard (power cycle) boot or soft boot or both?
If it works on a soft boot but fails on a hard boot then it's got to be a power issue.

Update: I have 3 Netburner modules, out of 100, that exhibit the "monitor function stuck waiting indefinitely for 'A'" phenomena. I've just discovered that if I connect a host to port 0, such that Rx0 goes high, this phenomena goes away and the monitor function properly exits and loads my application from user flash. Note that the monitor port is actually on port 1. This issue with port 0 isn't a problem on the other 97 of 100 Netburner modules.

Something is wrong in the monitor utility implementation, I think. I need someone familiar with monitor utility source code to give me a clue as to why the utility might have some problem managing port 0, error out, then wait forever for 'A' instead of loading program from user flash.