Boot Monitor conflicts with connected device on MOD5270

[sblair]

I've ran into a fun startup issue with a MOD5270 connected over serial to another device. I'm using the MOD5270 to control the other device via serial commands. The target device uses 115kbaud.

This is where the fun starts. On power up the NB sends the normal Boot Monitor message to press Shift-A. The target device starts sending error responses about "INVALID COMMAND". The NB is receiving all this and sees an 'A' in there and dumps into boot. As the NB is going into the boot monitor it spits out a time stamp (i.e. 12:02:34) When the target device gets a string formatted like that from the NB then it just craps itself and crashes.

I'm sure other folks had to have run into similar situations here. I know there is a bit in the config record to disable the boot monitor but I don't want to leave myself in a brickable situation either. So what are the various options for me here?

Also, while I'm dealing with the MOD5270 right now, I'm building a new design on the MOD54415 which is supposed to be "unbrickable" so on that platform how would the options change for me to avoid this problem?

Thanks!
Scott

[versamodule]

Is there a reason why you cant change the monitor port to Com1 instead ?

[Ridgeglider]

Agreed with Versamodule's comment. Just configure the monitor using the setup option to have the Com1 be the default comm port for the 5270. Then continue to use Com0 and the existing wiring/connectors to connect to your device. When you do this, you will probably have to do something like using:
int fd_Com0 = OpenSerial( 1, 115200, 1, 8, eParityNone );
ReplaceStdio(stdin, fd_Com0);
ReplaceStdio(stdout, fd_Com0);
ReplaceStdio(stderr, fd_Com0);

to make stdio (and functions like printf() ) run thru Com0 instead of Com1.

That way, info associated with the monitor (eg: the Shift 'A' prompt) go in/out Com1, but everything else goes in/out Com0. There are other ways to do this, but replacing stdio may be the easiest way to leave your existing code untouched.

When I do this, I usually put a label on the module telling me the default Com port is Com1 so I don't think it's toast later.

[roland.ames]

If you cannot use COM1, you could use the 'Quiet Boot' setting.

In this mode the boot monitor does not send anything out on startup. You still have to be confident that your device will not issue the 'A' within the first two seconds.

There is also the option of changing the baud rate used by the monitor.

[dciliske]

Roland is correct. This is one of the things 'Quiet Boot' is intended for.

[pbreed]

You can also program the boot monitor to 57600.... so it won't see 'A' at 115200...

Paul

[sblair]

I use both Com 0 and 1 to communicate with other devices. There are also a wide range of devices I connect to that all use different baud rates. So just changing port or baud rate doesn't completely solve the issue.

Quiet Boot gets me part way there but in a startup condition a lot of the devices I connect with send out all their startup log out the serial port so on a power cycle event I would still have problems with an 'A' coming in.

I saw something in the config record allowing me to disable booting through the boot monitor. I also saw references to an alternate boot monitor in the forums by using a jumper.

So, if I disable the boot monitor in the config record and I brick myself how would I get out of it? I haven't run across anything explaining the alternate boot monitor.

Thanks!
Scott

[dciliske]

There is no alternate boot on the MOD5270. This is only available on the Mod54415 and Nano54415. It's sounding like you need the 0 second wait, to prevent pontential data conflicts. Another alternative you could try is to add a hardware buffer on the console port and only enable it after booting, though this is getting into Yak shaving territory...

As for how you would recover from a trapping app on boot, you'd need to use a BDM...

-Dan

[sblair]

Unfortunately I don't have the hardware signals in place to be able to disable the RS232 driver. I was thinking about that over the weekend.

How it works on the MOD54415 is also relevant to me as we are migrating over to that platform. The MOD5270 is a mid-range timeframe problem for me until then.

Is it possible for me to reflash with a BDM myself? I wasn't sure how much you guys made available in that regard to do it. I used to do Coldfire dev another company so all my experience prior to this was with using BDM's.

On the MOD54415, can I disable the boot monitor and then use the alternate boot monitor still to recover?

Thanks.
Scott

[dciliske]

On the Mod54415, yes, you can safely set the boot delay to 0 (effectively disabling the monitor) and recover from a bad app with the alternate monitor. I have in fact used the alternate monitor to perform testing with networking, and therefore Autoupdate, completely disabled.

As for the BDM, that's something we'd need to discuss internally before I could hazard a guess (whether to release the info/tools/procedure; we bringup the devices using a BDM).