RSTI low at POR - 5270 problem?

[greengene]

my eyes have glazed over reading the Reset Controller Module section in the Reference Manual,
so here i am.

here's what we've got: a maxim DS1818 tied to the RSTI and Vcc to detect out-of-tolerance
voltage and then hold RSTI until it is good again. the genesis of this "solution" was to
approximate the low voltage detect processing of the 5282.

a problem we see after a noisy power on sometimes (3%?), is we get a s/w trap shortly after
power on in the OS context switch(?), but when it resets it immediately gets into the trapping
loop with PC=0. i've read that when that bad reboot to app happens you need to power cycle
the board to get the boot loader back to a good state so that it can then boot the app.

the application can at times only see an external reset and not a POR in the reset status register
even after POR. i s'pose things are getting confused by the RSTI being fiddled around bouncy
start up power.

so putting 1 and 1 together i probably getting 27, but can those two things be related?
do we even need to try and wait for clean power before releasing, or even using, the reset?
should we just yank the DS1818?
is a noisy, spikey initial start condition even a problem? we didn't see this problem
(as much? at all?) on the 5282.

tia.

[pbreed]

The formal answer....
The MOD5270 has an internal 1.5V supply.
The only issue with power is if the 1.5V supply is above the 3.3V supply.
One could probably concoct a power up sequence where you power up the 3.3, then pull it down really hard and
get the 1.5V over the 3.3V.
I don't think any normal switching power supply topology would do that.
The reset controller on the MCF5270 is pretty good so I think it should work unless proven otherwise.


Reading between the lines I think your core problem is corrupted monitor flash.
90% of the time we see corrupted monitor flash is because people write to the configuration record or user flash on power up.
DON'T DO THIS!

If power is flakey while you are writing toflash all bets are off it could do anything.
Even the flash lock bits are no garentee when the power is funky during a flash write.

For AC powered situations:
The person connects power and the plug is loose of there messing with the cord /extension cord,
so the power may come and go 10 times in a 5 sec period.

For DC transportation powered situations:
The vehicle turns on then the starter motor runs pulling the input voltage rail way down.
Power drops out or is flakey during start up.

If you write to flash in the period most likely to be flakey you are playing Russian roulette.
With extra bullets. So if you need to record start ups wait 60 seconds and reduce your issues by an order of magnitude.

If your code is making sure the system configuration record is correct, read the record
and only save it IF it needs to be changed. I've seen customers rewrite it with identical values on every power up.

One can take this informaiton and go down the parinoid route and add big cap or battery backup and only
program flash when you have enough batter/cap to finish. It should 100% solve the problem, but
I think this is a bit too extreme in the other direction.

[greengene]

on our 5282 product, we did use the mcf flash for user data.
on our 5270 product, we only use the mod flash for program storage as
we have our own spi flash for user data and our back up copies of the
app program.

is the problem where you can get the bootloader into a bad state requiring
the mod to be power cycled a corrupted flash problem? or only when you
need to reprogram the boot monitor is it from corrupted flash? i.e., can
i corrupt flash such that the bootloader can no longer do its job from
reset but all is good after power cycle? that sounds to me like bad data
that is assumed to be in a given state after por but isn't when only doing
an ext reset. it's sumpin...

[pbreed]

If a hardware reset or power cycle fixes it its not a flash problem.

What do you have attached to the serial port?

Is it possible that its sending an 'A' and forcing the system to abort into the monitor?

Anything connected to the data bus?

Paul

[greengene]

ok.

usually nothing unless we are doing debug. when we detect that the
nb has gotten into this state, we have connected to the debug port,
we just see the constant reboot at pc=0.
we have had debug cable into hyperterm to try and track this down
and have had the 1st trap be to oscontxtsw(?) and then the pc=0
traps thereafter.

nothing on the data bus.

[pbreed]

Does it get into this mode on startup without ever having been running?
What version 5270 monitor are you running?

Please submit a support ticket on this.

Paul