Testing a PIC controller

[McGuinn]

Hi,
As some of you may be aware, I am trying to get a 16F627 working in a Velleman kit. I have very limited exposure to this coding, and not having a working application is not assisting matters...
(see https://www.electro-tech-online.com/threads/how-to-use-an-opto-triac.10570/ also)

I have been able to confirm that the PIC is processing some instructions, but it appears to be sticking on some code:

Here is a sub procedure in the code:

DELAY		MOVLW   D'150'          ;*	;Put 150 decimal in the 'TIMER1' register.
                MOVWF   TIMER1          ;*
                ;
DELAY2		MOVLW	D'150'			;Put 150 decimal in the 'TIMER2' register.
	MOVWF	TIMER2
	DECFSZ  TIMER2,F        ;*	;Timer2 = Timer2 -1, skip next instruction if Timer2 = 0.
                GOTO    $-1             ;*	;Jump back 1 instruction.
                
	DECFSZ	TIMER1,F		;Timer1 = Timer1 - 1, skip next instruction if Timer1 = 0
	GOTO	DELAY2			;Jump to 'DELAY2' routine	
	RETLW   0			;Return (jump back to main) and load W-reg with 0.

The PIC seems to get stuck at the point where the first DECFSZ appears.
I was able to confirm this by doing a MOVWF PORTB to change LED's in sequence, incrementing the LED count per line.

Question #1 is: Is there an element in this code that is not supported on the 16F627 chip?

Question #2 is: Does anybody have a small piece of code that will serve to prove the operation of my Velleman circuit board... A simple LED on/off example would do.

Thoughts on the matter shall be considered and appreciated...

 

[Nigel Goodwin]

Check my tutorials, the 627 is just the smaller memory version of the 628 used in my tutorials - there's plenty of test examples there, starting with flashing LED examples.

For generating delays it's simpler to use a software loop rather than get involved with the timers, this is what my tutorials do - you can generate code for delays using an online generator on the PICList.

 

[Exo]

Nigel, the code is using a simple software loop, the author just named his variables 'timer1' and 'timer2' (its not TMR1 and TMR2)...

the problem is that this example was written for a pic16f84A. the data memory adress for the timer1 and timer2 variables are starting at position 0x0C, wich is where the f'84 ram starts...

on the 'f627 however, these positons are SFR's (PIR1 and a reserved space). wich is why the loops gets stuck...

also, the code doesn't turn off the analog comparators...

I'll change the code for a 'f627 and post it here if i find the time

 

[McGuinn]

OK, thanks for the pointer. I'll apply the code for the flashing LED's...

I'm wondering if the programmer board is a cause for the hanging, and a proper (known to work) program would prove this.

 

[Exo]

No, i just explained, the code was written for a Pic16f84. Running 16f84 code on a 16f627 is what causes the crashing

is it a 16f627 or a 16f627A that you have?

asuming its a 16f627 try what this does...

 

[samcheetah]

there is a 84 => 628 migration document on the microchip website. that might of be some help

 

[McGuinn]

No, i just explained, the code was written for a Pic16f84. Running 16f84 code on a 16f627 is what causes the crashing

is it a 16f627 or a 16f627A that you have?

asuming its a 16f627 try what this does...

Exo,
Our posts crossed, so my last post was in reply to Nigel's and I didn't see yours till now.

I loaded Nigel's code onto my 16F627 (not the A version) and tried to run it. It did nothing, and then I realised that I have port A hardwired as inputs, while Nigel's code uses it as an output.
I REM'd out the lines loading the port as an output, and re-assembled the file, but on trying to write it back onto the PIC, all of the LED's lit (and remain lit) and the PIC seems to be blown!!! It won't respond to reads or writes... (have reset/rebooted...)
I'll order a new one!

 

[McGuinn]

As a matter of interest, what PIC Sims are people using?
DonTronics has one called Oshon, but is this the best?

 

[Nigel Goodwin]

I loaded Nigel's code onto my 16F627 (not the A version) and tried to run it. It did nothing, and then I realised that I have port A hardwired as inputs, while Nigel's code uses it as an output.
I REM'd out the lines loading the port as an output, and re-assembled the file, but on trying to write it back onto the PIC, all of the LED's lit (and remain lit) and the PIC seems to be blown!!! It won't respond to reads or writes... (have reset/rebooted...)
I'll order a new one!

It may be that your programmer doesn't select programming mode fast enough, the 16F628 and 16F627 have an internal oscillator, if that's selected the programmer needs to set programming mode before the oscillator has time to start. Once the oscillator has started you can't set programming mode.

Which tutorial code did you use?, the first one (deliberately) flashes the LED's far too fast to see, the second one adds a delay to give a visible flashing.

 

[McGuinn]

The second one...
I REM'd out the lines as follows:

   	movlw 	b'00000000'		;set PortB all outputs
   	movwf 	TRISB
	; movwf	TRISA			;set PortA all outputs
	bcf	STATUS,		RP0	;select bank 0

...and the related movwf PORTA's in the rest of the code.
... but I think the damage was done.

 

[Nigel Goodwin]

... but I think the damage was done.

You shouldn't be able to damage the PIC in that way, they are extremely hardy devices.

 

[Exo]

I don't believe it's bust eighter... It's probabely just running on internal oscillator making it have trouble switching to programming mode...

does the velleman software allow you to change the vpp delay?

 

[McGuinn]

does the velleman software allow you to change the vpp delay?

Not now as it cannot communicate with the PIC.
It looks to get an ID from the chip first and it's flagging this as unavailable.

I have a 628 I will use till radionics deliver new ones...

 

[Nigel Goodwin]

does the velleman software allow you to change the vpp delay?

Not now as it cannot communicate with the PIC.
It looks to get an ID from the chip first and it's flagging this as unavailable.

Vpp delay isn't anything to do with the PIC, it's the programmer software, the delay between turned Vdd ON and turning Vpp ON - it needs to be short enough to prevent the internal oscillator starting up.

There is no ID from the PIC, it's most likely that the chip can't be switched to programming mode, simply because the Vpp delay on your PC software is too long.

 

[McGuinn]

I was able to spend time working this over the weekend.

It looks like a made a mistake... I loaded Nigel's first LED flasher onto the PIC, and not the second one. So the chip is running, and you are correct in saying that I am unable to program it because of the VPP delay.

When I now select program mode using a physical switch on the board, the chip goes into run mode, even though it's getting the correct programming voltage on pin 4 or 14 (can't remember which).

My software won't pick it up now... How can I change the VPP delay now?
I'm using a serial port, and WinPIC won't work...
Do I need to hold an input low/high to invoke it?

I'll start reading this link on the PIC's shortly...
**broken link removed** Seems good.

 

[Exo]

by looking at the scematic of your kit it seems to me that it has the same problem as the JDM programmer.

it supplies 5V to the pic all the time!. so, if a pic is programmed to run on internal oscillator and MCLR disabled (what nigel's tutorials do) the pic will start running as soon as power is applied and it cannot get into programming mode...

I have an idea for a simple mod for your kit wich would only apply power to the pic (in programming mode) when VPP is active. But it will require 'messing' with your kit a bit...

if you're not prepared to do this then the only alternative i can think of is to build/buy another proven programmer, like a P16PRO40.

you can try this mod by simply removing SW5, and soldering wires at the required places, and connect them to a little protoboard holding the mod circuit, this way you can test it without permanently damaging your kit
(if you remove SW5, dont forget it consists of 2 parts, SW5A and SW5B, so you need to solder wires at SW5A too)

you could also get a new pic, and NEVER program it for internal oscillator and MCLR disable, but that seems a bad way around this problem to me.

 

[McGuinn]

Himmmm... great mod... I see what you are getting at...
Whether the software will support it, I don't know. I'll try it.
I will simply cut the PCB track coming from the switch and wire in a trans across the broken tracks.

I'll post back when I have completed.