Odd Program Start Issue

[NoSmoke]

If I write a simple program that starts by printing a text spring (to the s/w UART connected to a PC), the text string is always "printed" four times. After that, output to the s/w UART is normal.

Can anyone suggest what might be happening here?

TIA

[Francis]

Can you give a brief example and also tell us how you are programming the PIC.

I am doing code right now where i have been playing with test prints using soft uart and h/w usart near start of code.
I get no problems as described.

The only multiple I get is during programme download onto my EasyPIC4, where the PIC is restarting a couple of times during/after programming.
Once the code is on the PIC I get no such multiple writes.

[NoSmoke]

Can you give a brief example and also tell us how you are programming the PIC.

Device = 18F4520
Clock = 8

Include "SUART.bas" 'Note: S/W UART defaults to inverted signal
' (it then works with a PC serial port)
Include "Convert.bas"

dim x as integer, in as byte

config OSC = intiO7, 'Enable internal oscillator
MCLRE = off 'Disable MCLR pin

SetBaudrate(sbr9600)
SetTX(portb.4)
SetRx(portb.5)

OSCCON.4 = 1 'Set internal oscillator to 8 MHz
OSCCON.5 = 1 '(so delay statements give correct delay time)
OSCCON.6 = 1


x=0
Write("Hello")

while 1=1
if (portb.5) = 1 then
Read(in)
if in = 13 then
Write(in, DecToStr(x))
end if

end if

if x=60000 then
toggle (portb.3)
x=0
end if
x=x+1
wend

In this example, "Hello" is displayed four times in quick succession after programming. From that point on, if "enter" is keyed on the PC, the current value of "x" is correctly displayed. Note that portb.5 is checked b/f the Read is executed to prevent hanging there.

If the device (18F4520) is reset by power off/on, "Hello" is printed twice.

The programmer is a MPLAB ICD2 clone called "Easy ICD2".

[Francis]

Worked fine for me, just one "Hello".
I'm using an old EasyPIC4 board and just pull the USB out/in to start.

Is your circuit doing something to cause a reset once?
Is the power section of your board a bit iffy?

[NoSmoke]

Have noticed that the "Hello World"s begins printing during the programming process. If a add a delay statement to the start of the program (long enough for the programming process to complete), all works normally.

The PIC is being powered by the programmer - maybe the power supply is a little light.

I'm using the internal oscillator and I recall reading somewhere on the SF site that there may be a problem caused by program execution starting b/f the clock speed is set in code.

[Francis]

All three of my programmers cause a start and restart and, with your code example, will give 2 "hello" messages during the programming process. (MELabs , Mikro , PICKIT).
I guess your extra delay gets around this.

If I do a power-up start I get one single "hello" - as expected.
What do you get?

If I enable the MCLR and do a press-button reset I get a single "hello".
What do you get?

I can't see this being an SF issue.
Have you tried swapping the positions of your OSCCON and Set... statements to see if it makes a difference? Perhaps check the ASM to see where things get put.

[Raistlin]

It's always a good idea to pop a delay at the beginning of your code to let the pic settle. A few hundred milli secs will do it.

[rmteo]

See here if using the internal oscillator http://www.sfcompiler.co.uk/wiki/pmwiki ... nternalOSC

[NoSmoke]

If I enable MCLR and do a reset or power off/on, "Hello" is printed only once (as it should be).

If I put in an Include Intosc as suggested, Hello now prints _five_ times!

Here's the Include code:

// Internal oscillator module (Intosc.bas)
// Place as 1st include in program to set internal osc b/f following code is executed

module IntOSC

config osc = INTIO7 'Set for internal oscillator
config MCLRE = off 'Also disable MCLR

OSCCON.4 = 1 'Set internal oscillator to 8 MHz
OSCCON.5 = 1 '(so delay statements give correct delay time)
OSCCON.6 = 1


Here then is the revised 1st portion of the program:

Device = 18F4520
Clock = 8

Include "Intosc.bas"
Include "SUART.bas" 'Note: S/W UART defaults to inverted signal (it then works with a PC serial port)
Include "Convert.bas"

dim x as integer, in as byte

SetBaudrate(sbr9600)
SetTX(portb.4)
SetRx(portb.5)

x=0
Write("Hello", 13)

while 1=1 etc. etc

Strange indeed.

BTW, why are both Clock = 8 and setting OSCCON required? If Clock =8 is removed, the SUART prints garbage.

[NoSmoke]

It's always a good idea to pop a delay at the beginning of your code to let the pic settle. A few hundred milli secs will do it.

Tried that and it works with about 400ms. I guess I'll just leave it at that, unless an explanation pops up, and attribute it to a programmer quirk.

[RangerBob]

BTW, why are both Clock = 8 and setting OSCCON required? If Clock =8 is removed, the SUART prints garbage.

Setting the OSCCON sets the actual clock setup in hardware, the "Clock = 8" tells the compiler itself what speed things are running at for calculating the delays and such.

As mentioned before, adding a delay to the start of the program is a good idea to let the power supplies and clocks settle, otherwise you may end up with this sort of issue, where program exectuion may start, stop and reset.

Another way which I use, is to use an external reset controller to guarantee your supplies are settled before MCLR is released. Adds to cost, but I needed the reliability and extra features provided.

[NoSmoke]

BTW, why are both Clock = 8 and setting OSCCON required? If Clock =8 is removed, the SUART prints garbage.

Setting the OSCCON sets the actual clock setup in hardware, the "Clock = 8" tells the compiler itself what speed things are running at for calculating the delays and such.

As mentioned before, adding a delay to the start of the program is a good idea to let the power supplies and clocks settle, otherwise you may end up with this sort of issue, where program exectuion may start, stop and reset.

Another way which I use, is to use an external reset controller to guarantee your supplies are settled before MCLR is released. Adds to cost, but I needed the reliability and extra features provided.

Thanks for the explanation. I guess it's a delay at the start from now on then.