Odd Program Start Issue
Moderators: David Barker, Jerry Messina
Odd Program Start Issue
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
Can anyone suggest what might be happening here?
TIA
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.
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.
Device = 18F4520Francis wrote:Can you give a brief example and also tell us how you are programming the PIC.
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".
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.
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.
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.
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.
See here if using the internal oscillator http://www.sfcompiler.co.uk/wiki/pmwiki ... nternalOSC
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.
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.
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.NoSmoke wrote: BTW, why are both Clock = 8 and setting OSCCON required? If Clock =8 is removed, the SUART prints garbage.
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.RangerBob wrote: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.NoSmoke wrote: BTW, why are both Clock = 8 and setting OSCCON required? If Clock =8 is removed, the SUART prints garbage.
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.