Rabbit doesn't restart after forceSoftReset() or virtual wd expiration

Hello,

I'm trying to use forceSoftReset()and virtual wd expiration to
restart my RCM3110 but what I'm getting is that both methods work for
me aprox 50% of the times.

For wd expiration, I'm using:

wd = VdGetFreeWd(100);
while(1) {};

I don't get any strange message that helps me to find some error on
my code.

Do I need to use a hardware watchdog (external to the rabbit) ?

Thanks,

Clement Start a New Thread

Generally, these type of problems are caused by array or stack
problems... this is a recording ... :) Start a New Thread

I don't understand how you are using a virtual or real WDT timeout
with forceSoftReset(). Either type of timeout already forces a reset.

If you run this in the DC debugging environment:

main(){
int wd;
wd = VdGetFreeWd(16);
while(1) {};
}

you should see an run-time error message about the VWDT timeout after
a second. If you run it stand-alone (no prgramming cable), the board
should do a HW WDT timeout and reset about every second.

If you run this in the DC debug environment, you should see a target
communication error because the board will hard reset and come up in
cold boot mode while DC is still trying to communicate with the
debugger. If you run it stand-alone, the board should reset about
every two seconds.

main(){
;
#asm // cause HW WDT timeout
ipset 3
xor a
ioi ld (WDTTR),a // make sure WDT enabled
ld a,0x5A
ioi ld (WDTCR),a // hit with 2 second time period
loop:
jr loop
#endasm
}

How are you trying to use forceSoftReset()? Start a New Thread

I'm sorry, English is not my primary language. I have been trying to
reset my rabbit using forceSoftReset():

if (conditions) {
forceSoftReset();
}

Sometimes it works, sometimes it doesn't.

Trying to solve that I removed the forceSoftReset() and put a virtual
wd, but the result was the same than using forceSoftReset().

According a reply from Mr. Ritcher I have to check stack and arrays.
My idea of checking stack is stepping at the begining of each
function, see the value of the stack, move to where that function
ends and check the stack again and should be the same as on the
beginning of the function. Is that right ?

Thank you,

Clement Start a New Thread

Thanks for your answer!

I'm not using forceSoftReset and virtual wd at a time. I tried first
with the forceSoftReset like this:

if (conditions) {
forceSoftReset();
}

It worked sometimes (even in standalone mode), so I removed the
forceSoftReset() and put:

if (conditions) {
wd = VdGetFreeWd(16);
while(1) {};
}

but the result was the same than using forceSoftReset.

According an email of Mr. Ritcher I have to test the stack among
other things. My idea of testing the stack is: step just at the
beggining of the function, look at the stack, step at the end of the
function, look at the stack and compare the stack with what you saw
at the beginning of the function: it should be the same; and do it
with all the functions. Am I right ?

Thanks again,

Clement Start a New Thread

--- In rabbit-semi@rabb..., "castcastus" wrote:
> Thanks for your answer!
>
> I'm not using forceSoftReset and virtual wd at a time. I tried first
> with the forceSoftReset like this:
>
> if (conditions) {
> forceSoftReset();
> }
>
> It worked sometimes (even in standalone mode), so I removed the
> forceSoftReset() and put:
>
> if (conditions) {
> wd = VdGetFreeWd(16);
> while(1) {};
> }
>
> but the result was the same than using forceSoftReset.
>
> According an email of Mr. Ritcher I have to test the stack among
> other things. My idea of testing the stack is: step just at the
> beggining of the function, look at the stack, step at the end of the
> function, look at the stack and compare the stack with what you saw
> at the beginning of the function: it should be the same; and do it
> with all the functions. Am I right ?

That's a good way to check for stack corruption, yes, but if you are
making it to the while loop I don't think that is the problem unless
you are very deep into the stack (is SP down close to D000h when you
get there?).

What do you see if you run this stand-alone?

main(){
wd = VdGetFreeWd(16);
while(1) {};
}
}

See my previous post about forceSoftReset also.


> Thanks again,
>
> Clement Start a New Thread

I made the test:

Run Time Error: Virtual Watchdog timeout
Address 00:1fb1

Thank you,

Clement Start a New Thread

I made the stack test on the real program where I have the problem:

L: 464 C:5
DFFC: 4053
DFFE: A100
E000: E100
E002: 0009
E004: 0000
E006: 00F2
E008: 9501
E00A: 8EFE
E00C: 86F7
E00E: E078
E010: 007F
E012: 3728
E014: 4339
E016: F1C9
E018: BF2B
E01A: 2F6D

Does that have something to do with my problem ?

Thanks,

Clement Start a New Thread

The problem with forceSoftReset may be related to interrupts being
active. Try the following before forceSoftReset:

WrPortI(SACR, &SACRShadow, SACRShadow & 0xFC);
WrPortI(SACR, &SBCRShadow, SBCRShadow & 0xFC);
WrPortI(SACR, &SCCRShadow, SCCRShadow & 0xFC);
WrPortI(SACR, &SDCRShadow, SDCRShadow & 0xFC);
WrPortI(TACR, &TACRShadow, TACRShadow & 0xFC);
WrPortI(TBCR, &TBCRShadow, TBCRShadow & 0xFC);
WrPortI(SPCR, &SPCRShadow, SPCRShadow & 0xFC);
WrPortI(I0CR, &I0CRShadow, I0CRShadow & 0xFC);
WrPortI(I1CR, &I1CRShadow, I1CRShadow & 0xFC);
WrPortI(GCSR, &GCSRShadow, GCSRShadow & 0xFC); Start a New Thread

It appears that you're right about interrupts being the problem with
using forceSoftReset. But that wouldn't explain why a virtual
watchdog wouldn't work also, would it?

Wouldn't creating your own softReset function that disables
interrupts before jumping to 0 be a more efficient way of handling
this? I would think that Z-world would have done that in their
function if there's the possibility of it failing due to interrupts. Start a New Thread