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:
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...
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.
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
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!
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.
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.
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.
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.
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.