definite port states at power-up

[hkpatrice]

Hello everyone.

I have an application that must absolutely power-up in a definite state. Pins on port b must NOT be in high state. Output and low state is OK, input is ok.

The problem I am facing is that 1 time out of 1000, the pic will power up with a pin on port b being high for a few milliseconds, which is unacceptable.

This problem is driving me crazy, I have the power up timer enabled, pull down resistors on all pins, but still this pops up once in a while.

I wonder if this can ever be corrected in software or if I should consider a hardware solution (i.e. power the pic first, then power the rest of the circuit?)

Basically, my application waits for serial com and will pulse outputs accorrding to what message comes in. However, the short "high" state at power up happens even if no coms are coming in. Could it be garbage in the receive buffer being interpreted as valid data?
Should I clear the buffer before enabling interrupts? Could it be related to the voltage ramp-up time?

Any suggestions you may have would be greatly welcomed.

I have attached the first part of my program here, I am using a pic 16f877A:


@ __config _HS_OSC & _WDT_ON & _PWRTE_ON & _LVP_OFF & _CP_OFF & _BODEN_OFF
include "modedefs.bas"
TRISB=0
TRISC=%11111111
TRISD=0
PORTD=%00000000
portb=%00000000
ADCON1=%00000111 'PORT A AND PORT E ARE DIGITAL
DEFINE SER2_BITS 9 ' define 8 bits + parity
DEFINE HSER_RCSTA 90h 'receiver enabled
DEFINE HSER_BAUD 4800 'define 4800 baud speed
DEFINE HSER_CLROERR 1 'automatically clears buffer overrun errors

RCIF VAR PIR1.5 ' Alias RCIF (USART Receive Interrupt Flag)
OERR VAR RCSTA.1 ' Alias OERR (USART Overrun Error Flag)
CREN VAR RCSTA.4 ' Alias CREN (USART Continuous Receive Enable)




buffer_size CON 64 ' Sets the size of the ring buffer
addressbuffer VAR BYTE[buffer_size] ' Array variable for holding received characters
commandbuffer VAR BYTE[buffer_size] ' Array variable for holding received characters
index_in VAR BYTE ' Pointer - next empty location in buffer
index_out VAR BYTE ' Pointer - location of oldest character in buffer
bufchar VAR BYTE ' Stores the character retrieved from the buffer
i VAR BYTE ' loop counter
errflag VAR BYTE ' Holds error flags



ADDRESS var BYTE
COMMAND VAR BYTE
LOWADD VAR word
HIGHADD VAR word
value var byte
BOXADD VAR BYTE
loopcount var word
counter var byte[16]
loop var byte
fireflag var byte
OUTPUT_ENABLE VAR PORTA.1
clock var portE.0
datain var portA.3
load var portA.5
checkstatus var portE.1
dumpvar var byte




fireflag=0
VALUE=0
counter=0
high load
low checkstatus
low output_enable
index_in = 0
index_out = 0
i = 0




INTCON = %11000000 ' Enable interrupts
PIE1.5 = 1 ' Enable interrupt on USART
ON INTERRUPT GoTo serialin ' Declare interrupt handler routine



main:
IF errflag Then error ' Handle error if needed
IF index_in = index_out Then main
GoSub getbuf ' Get a character from buffer
ELSE
GOTO MAIN
ENDIF


‘(I haven’t included the whole program for sake of clarity)

[Acetronics2]

Hello everyone.

I have an application that must absolutely power-up in a definite state. Pins on port b must NOT be in high state. Output and low state is OK, input is ok.



‘(I haven’t included the whole program for sake of clarity)

Just two things to absolutely respect ...

1) The hardware side : system must be in a stable safety state if Processor is out of its socket ( ! ) - @ poweron all pins are inputs ( floating ...)

2) The software side : processor outputs must meet 1) ( no change !!! ) and inputs must be set to the state the sensors and buttons are in 1) situation, so no uncontrolled change could occur.
PORT or LAT Registers have to be set first, THEN TRIS registers ...

That's enough to be perfect !!!

Alain

[hkpatrice]

Salutations de Hong Kong Alain!

I'll continue in English so that this may eventually help others...

1) The hardware side : system must be in a stable safety state if Processor is out of its socket ( ! ) - @ poweron all pins are inputs ( floating ...)

Got it!, Yep! the system would be stable even without a processor in socket. I've got pull down on all lines that I want to power up in low state.

2) The software side : processor outputs must meet 1) ( no change !!! ) and inputs must be set to the state the sensors and buttons are in 1) situation, so no uncontrolled change could occur.

PORT or LAT Registers have to be set first, THEN TRIS registers ...

Oups... I'm doing the opposite. I first set Tris, then assign them low or high... Could that really cause the problem?

That's enough to be perfect !!!

Thanks for your help!

Patrice

[Acetronics2]

Salutations de Hong Kong Alain!

Oups... I'm doing the opposite. I first set Tris, then assign them low or high... Could that really cause the problem?

Patrice

Hi, Hong Kong FuFu

that is more than enough !!! as outputs states can be whatever you want until the PORT = ... line is reached. Also think to inputs to be correctly preset ... not to trigger an interrupt i.e.

One funny app was an electronic ignition for cars ( A110 forum ) there always was an explosion in the exhaust system @ powerup ...
so, Alain raised the " Anti prout " mod. ... just like described here.

Comment tu fais pour survivre là bas ... je n'ai pas réussi à dépasser les 15 jours lors d'un voyage pro à Singapour ( LadyHill Hotel tout de mème ...)... et pourtant le gus qui me chaperonnait était super sympa !!!

Alain

[hkpatrice]

Alain,

Thanks a lot. This makes perfect sense. at 4Mhz clock speed, there has to be about 1/500 th of a secong between the time where I set Tris, and when I assign the "0"or "1" to the pin. That would be enough to create the problems I have been experiencing. I naively thought that the registers always defaulted to "0" at power-up.

Je suis ici depuis dix ans... j'ai ma petite famille ici... en moins de 4 heures je suis sur une plage en Thailande ou dans la jungle aux phillipines...Je ne me vois pas revenir en occident...

Merci!

Pat

[Acetronics2]

Alain,


Je suis ici depuis dix ans... j'ai ma petite famille ici... en moins de 4 heures je suis sur une plage en Thailande ou dans la jungle aux phillipines...Je ne me vois pas revenir en occident...

Merci!

Pat

With family ... much better !!! We must admit those people have another way of thinking and other life priorities than in Europe ... that needs some time for training !!!

and social tourism ( dedicated expression ! ) is something really nice there. I had enough time to appreciate it visiting Malaysia.

Thanks a lot. This makes perfect sense. at 4Mhz clock speed, there has to be about 1/500 th of a secong between the time where I set Tris, and when I assign the "0"or "1" to the pin. That would be enough to create the problems I have been experiencing. I naively thought that the registers always defaulted to "0" at power-up.

I remember the minimum time for the PIC to see " anything " is around 20 ns ( 50 Mhz ) ... yes, nano ...

read you soon
Alain