Reset and UART Problem.

[Glennk]

When one of my 18F452 systems reset while there is activity on the RS485 bus, the system does not bootup properly.

I am creating a Stack Underflow Reset and my program reboots normally unless there is activity on the Rx line during the bootup time.

Has anyone got a fix for this problem?

[PCM programmer]

I would get rid of the Stack Underflow problem. That's the underlying
problem. So how do you get an underflow ? You could do it by
executing a Return instruction (RETURN, RETLW or a RETFIE) without
first having done a CALL or RCALL instruction, or an interrupt.
So the question would be, why are you doing this ?

[Glennk]

Thanks for your reply.

The situation is that I have controllers in the field and one is going down and doesn't reset itself properly. I am trying to simulate the situation in the lab to see what can cause the controller to fail to reset.

Since there is serial communication much of the time and I cannot control when a reset may occur in the noisy environment of a compressor room, I'm trying to make the bootup process reliable.

The problem appears to be related to an overflow or a framing error in the UART. I have tried to clear those errors before the enable_interrupt() command but has not worked yet.

Any other thoughts you may have would be appreciated.

Glen

[PCM programmer]

The 'Reset on Stack Underflow' capability of the 18F452 has nothing
to do with a UART overrun or framing error.

What you need to do, is to detect and clear any overrun errors
that occur in the UART. You can do this by adding the ERRORS
parameter to your #use rs232() statement, as shown in bold, below:

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)

This only works with the hardware UART.

[PicFan]

How sure are you that the actual source of the reset is a "stack underflow"?

Are you testing the register or using the built-in function restart_cause() to allow you an opportunity to react to differing start-up conditions?

As PCM Programmer indicated, you won't experience a stack underflow as a response to communications activity during bootup.

Maybe set the receive pin (PIN_C7) as digital and wait for an idle state before enabling the USART to assure no comm activity?

Best Regards

[asmallri]

One possibility is that you may be enabling interrupts too early during your initialization

[Mark]

I hope that you are not enabling interrupts inside the handler. You should only do this in main() or some function called from main. The ints are automatically enabled on return from the handler. If you enable them during the interrupt routine, you are bound to have problems.