Pin initialization question

[rocket_troy]

I have an application/circuit based on the PIC18F13K50 and an issue I face is that upon the initial power up, the output on port C.4 (an assigned output) can be a bit unpredictable ie. sometimes it can start in the high state even through I have a 10K resistor pulling it to ground. It's critically important that it starts in the low state consistently on power up. Doesn't appear to happen on portC.5 which is configured the same way. Is there any way to ensure this pin always starts in the low state at power up? Or have I selected the wrong pin/port for this task?

Thanks,

Troy.

[mackrackit]

Do you have
PORTC.4 = 0
right after the TRIS statement at the beginning of your code?

[rocket_troy]

Dave,
I begin with 2 lines of assembler code
followed by 5 DEFINE lines
followed by all the TRISx allocations (including portC.4 to output)
followed by 13 lines of control register setting
followed by 50(odd) variable name assignments in which I assign variable name "Channel1" to PortC.4

Then straight after that, I assign "Channel1 = 0"

Do you think this is too late in the piece to assign 0 to PortC.4 via the Channel1 alias?

Thanks,

Troy

[mackrackit]

I like to set the IOs right after the configuration registers (fuses).
That way you are sure what the chip is doing while everything else is settling in.
Give it a try...

[HenrikOlsson]

Hi,
Looking at table 3-2 in the datasheet you can see that the default state of PortC (and the other Port regsiters) is unknown at power up, so one pin being high and another low is to be expected. If you need them to be in specific states when powering up you need to make sure to set them. However, you might considder setting PORT before TRIS - otherwise there might be a short pulse on the output between the output driver being turned on and actually being set.

/Henrik.

[rocket_troy]

As it turns out, the issue was actually coming from a combination of code and the unpredictability of an external IC the PIC is interfaced to. It appeared as if it was occurring at power-up, but a carefully placed pause statement illustrated otherwise. I've modified the code as per your suggestions anyway as they seem like good practice. Thanks Dave and Henrik for the tips.

Regards,

Troy.