Design mistake on a 12F675-based heli lighting system

[NiKoLai_]

Hi, at first I want to apologize for my bad English, I'm from Spain.

A month ago, so so, I designed a PCB for a lighting & battery monitoring system for a HB CP2, based on a 12F675 PIC. It's simple, three LEDs lighting in a certain sequence and another LED that lights up when battery voltage drops from a programable threshold. I attach the schematic and a modified photolithograph (with the shape of components to help understanding of each track).

Before doing the PCB (my first pcb :rolleyes: ) I mounted the circuit on a protoboard, and made the program for the PIC. It works, but sometimes (actually when the power is turned off and turned on), I see that the PIC blocks, and the circuit works impropely. This means that all LEDs lights up at low intensity when they have to be off and changes at high intensity when supposedly they have to light up, or the sequence changes, or just two or one LEDs operates. Strange things like that.

This problem could be solved removing the PIC from the protoboard (with power applied) and putting it again. I supposed that the problem had relation with the long wires I used in the protoboard, some impedance desadaptation or coupling that blocks the PIC or something like that (my electronics knowledge is very small). Actually, I have no idea of what the problem could be caused by :( But I thought the problem would be solved once the PCB was made, so I made it.

Unfortunately, I was mistaken, and the problem is on the PCB, too. Apart of this, the ICSP support I tried to design doesn't work. I had to desolder the SMD PIC, program it, and solder it again to the PCB, showing the problems I have described above.

I ruled out the theory of burning the PIC with the soldering iron (a 30W JBC), because I tried to solder two chips (And I was very careful soldering the second), and two of them showed the same problems.

I have no idea of the mistake I have done in the design. Do you see something bad in my schematic or/and PCB?

Thanks for advance.

[MatC]

- 78L08z is presumably 8v, but the '675 is only rated to 5.5v?
- Is external clear enabled? If so you'll need to tie pin4 high with a 100k resistor.

Other ideas:
- Does resetting the chip help? [You have to enable external in the config fuses] - Will help diagnose the problem.
- Watchdog timer resetting on you? Or not doing?
- Brown out detection? [config fuse]
- Power up delay? [config fure, probs a good idea, may help with powerup issues]
- You might consider putting C1 the other side of the switch, to help smooth things out during powerup.
- No reason why ICSP shouldn't work when soldered in, there's nothing to stop it in your circuit that I can see (at least when the jumpers are set properly).
Maybe you could socket the chip till it's working properly?

[MatC]

PS high powered soldering irons are better, because you can make the joint faster.
PPS Err by "socket the chip" I obviously mean "build a soic->pdip adatper", sorry I forgot it was soic.

[pmackenzie]

I had a similar (http://www.rcgroups.com/forums/showthread.php?t=538325) problem
As it was in my case this could also be a software issue - perhaps forgetting to initialize some variable.

Pat MacKenzie

[NiKoLai_]

Thanks to you two for answering so fast.

pmackenzie:

-I think that if the problem was the thing you are talking of, the circuit wouldn't never work, and it does when you remove and put the PIC again (in the protoboard). However, I can't ensure that absolutely.

MatC:

- There is an error in the schematic. The voltage regulator I used is the 78L05. Thanks for the warning.

- I can ensure that the problem is not the MCLR flag. I had another problem relationed with this flag (the PIC worked for a while and then stopped, having to unplug power and turn on it again). I solved this first problem disabling the external MCLR by fuses.

- I'll test the idea you said about triggering the MCLR manually to see if it restarts well.

- I think another flags are well-configured, but I'll check them again because I'm not sure.

- I don't understand well where I should put the C1 capacitor, because I see another error in the schematic. In the PCB, C1 is closer to the chip, after the switch (jumper). Warn me if I should put it closer to the 78L05.

- Yes, I don't see nothing bad in the PCB about the failure of ICSP function, too. But it doesn't works, and I think that the reason is the same of all other failures on the circuit. The correct jumper settings for the ICSP is removing all, because the PIC programming specifications talk about isolating ICSP DATA and CLK pins, of I/O devices connected in (the LEDs). I thought that the simplest and cheapest way to do it is cutting the circuit by a jumper.

I'll try some tests and post the things I see here. If you have some other idea about my design please post here.

Thank you two again for the answers.

[Malc C]

Try posting the PIC code (ASM, basic or whatever) so it can be confirmed that you have all the config settings right. Also you don't appear to have a 0.1uf decoupling capacitor between the supply pins (1 and 8) of the PIC, and (as mentioned) it would be worth putting a 10K or higher resistor between MCLR and +5v

EDIT:

Also have you set the PIC up as digital... by default all inputs are set as analogue.

Scrub the capacitor.. just put me glasses on and looked at the schematic again !!

[MatC]

Caps: I'd put them closer to the chip, after the jumper. Not a biggie, but will help to get rid of noise from the switch/jumper.
If ICSP isn't working with that circuit, I'd try and hunt the problem with that first. In my limited experience ICSP is fairly robust, so if that's not working with no other components in the way, I'd be wary. Somewhat marginal programmer? Have you done a resistance test to check continuity and absence of shorts around the PCB?
You don't necessarily need full isolation for ICSP, for instance you can drive outputs through a resistor and so on, but you're right that a jumper is simplest and most reliable (except apparently not :\)
I'd get MCLR set to external and see what a reset does, that will help identify if you're looking at a code issue or not.
Incidentally, MPLAB on mine warns about configuring for low voltage programming and internal MCLR at the same time - no idea how much of an issue this is, and I'm not certain it was a '675, but worth a check on the datasheet.

[dleroi]

Have you checked Vdd at pin 1? I glanced at your PCB drawing and the 78L05 is backwards if it's a TO-92 inserted the way that it is shown.

[JimDrew]

Your problems are pretty simple. You MUST connect a 47K resistor from GP3 to VDD. Resistors R5 and R6 appear to be a voltage divider. Make absolutely sure that these resistors do not allow a voltage to exceed the maximum input voltage allowed for the PIC (5.5v in this case). Jumpers JP1 and JP2 must be open during the programming. JP3 doesn't need to be open as long as there is no voltage powering the regulator.

[dleroi]

You MUST connect a 47K resistor from GP3 to VDD.

Jim,

Educate me why GP3 has to be high if MCLR is disabled?

Thanks,
Don L.

[Mr.RC-CAM]

During device programming, enable the BROWNOUT and PUT fuses. I suspect you will be fine after those are turned on.

[JimDrew]

Jim,

Educate me why GP3 has to be high if MCLR is disabled?

Thanks,
Don L.

This is a Microchip thing. I know that in every design I have done where the 47K resistor was left out, the device would not program. Even if the device has MCLR disabled (or used as an I/O pin), you have to supply +5v to Vpp during programming. I just went through this same thing with the 16F684 and added the resistor in the ICSP programming header cable to be able to program the part. Also, a few parts had silicon revisions to fix a problem where MCLR was enabled until some part of the microcode was reached and turned it off (if the bits were set to turn it off), and some code was executed with MCLR possibly in the wrong state.

[NiKoLai_]

Hi to all

It's wonderful to see so many answers, I thank you all for the help (do you noticed that I posted my problem in another forum and almost nobody answered? :D )

Malc C:

- Yes, the PIC inputs are set as analogue. Except the one I use for the comparator, of course.

- I'll try putting the resistor between MCLR and 5+. But I want to focus my problems in the ICSP failure. Can it have some relation with it?

MatC:

- I don't understand what do you mean with "marginal programmer". I can only say that the programmer is a JDM purchased on eBay, and I program the circuits with the ICSP port. It works well in the protoboard but not in the circuit mounted on the PCB.

- I tested the MCLR manual triggering. Sometimes the PIC restarts well, and sometimes not. I couldn't get some problems I wrote about above. I just got some LED failure (two LEDs did the sequence but one doesn't). It couldn't be solved by restarting the PIC via MCLR, only removing and putting the PIC again, as described in my firsts posts.

- Low voltage programming? I had a quick look at the datasheet and I think that 675 doesn't support low voltage programming. Please correct me if I am mistaken.

dleroi:

- Yes, I checked Vdd and Vpp pins. The voltages are correct.

Mr. RC-CAM:

- What do you mean with BROWNOUT and PUT? I guessed that it's refered to the BODEN and PWRTE flags (fuses?). In my first program BODEN was disabled and PWRTE enabled (bit cleared). I thought it would be correct. I tried enabling and disabling flags (or fuses) in some combinations and it didn't solve the problem.

JimDrew:

- The circuit is powered by 12-13v battery. If you see the schematic, you'll see that the voltages after the voltage divider are inside the acceptable threshold for the PIC (correct me if I am mistaken).

- Yes, all jumpers are open while programming (that's the reason I put them ;) ). I put JP3 because I read that the 7805 can be damaged if you power up the output lead without a voltage in the input. You have this situation while programming.

- I'll try your idea (and Malc C's) about bridging MCLR and Vdd pins with a resistor. But I tell to you the same question I have told to him. This resistor can be the reason of the ICSP failure? Or just the improperly behaviour of the PIC?

I'll post again when I tested your suggestions.

See you. ;)

[JimDrew]

If you don't have the resistor, ICSP will not work. Also, if you are using MCLR as a reset, you must hold this high with this resistor or it will float and the chip will reset itself based on the weather. :)

[NiKoLai_]

I'll test it this evening. But it's strange because I have the circuit mounted on a protoboard without this resistor (Vpp port of programmer directly tied to GP3 and nothing else) and ICSP works fine. :-?

[Mr.RC-CAM]

What do you mean with BROWNOUT and PUT? I guessed that it's referred to the BODEN and PWRTE flags (fuses?).
BODEN = 1 (Brownout enabled).
PWRTE = 0 (PUT Timer enabled).

When the external MCLR input is not used (MCLRE fuse = 0), these settings will help ensure a reliable reset.

I don't understand what do you mean with "marginal programmer". I can only say that the programmer is a JDM purchased on eBay, and I program the circuits with the ICSP port. It works well in the protoboard but not in the circuit mounted on the PCB.Marginal Programmers: I recall that the JDM design is one that is very temperamental on some PICs, especially if a cable is used.

[NiKoLai_]

Do you mean that my JDM programmer could be the reason of the failures?

However, I use the same cable to program both the protoboard and the PCB. How is possible to program the protoboard and fail when trying to program the PCB unless there is something wrong in the PCB?

I have heard that a long cable between the programmer and the circuit can make ICSP fails. The cable I use is between 10 and 15 cm long. I think that is an acceptable lenght.

[Mr.RC-CAM]

Do you mean that my JDM programmer could be the reason of the failures?The main problem (power up troubles) is probably your fuse settings or application code. Please set the fuses (BODEN, PWRTE, MCLRE) as mentioned, then go from the there.

The problem with not being able to ICSP the PCB may be related to the JDM programmer. Or, there is something you are doing differently between your PCB and protoboard. For example, are the two wired exactly the same? Do you remove all the jumpers on the PCB before programming? The list can go on and on ...

[Malc C]

When breadboarding the nature of the way they are made can have a factor (mainly capacitance I believe) on the way the circuit behaves.

If I was you and I had this sort of problem I would try etching another PCB, but with a DIL packaged PIC - then program the PIC via the socket on your JDM programmer and if it reports a sucessfull burn then remove the PIC and place it in the PCB and test it. If the circuit works then you know that A) the code works, and B) the PCB is fine. I would also stress that the 10K + resistor between MCLR on most pics is a must, because as explained if the pin is left floating the PIC resets on a whim ! - I also never use internal pull ups and prefere to pull a pin high or low (depending on the input I'm testing) via 10k resistors.

The other thing I would try is using some other software to load the HEX to the PIC. It may be that the software can't set the VPP before VDD (or vice-verca) and is not actually loading the HEX to the PIC. Are you able to read back the PIC and compare it to the HEX in the programe file ? PICpgm is nice application and works well with the JDM programmers I have here... alternativley there is ICPROG or WinPICpro or WinPIC800, all of which do a fair job considering they are free !

I also suggested you post your code so that the experienced guys here can advise if the issue is the fuses, code or both. Simply copy the code and paste it between [c o d e ] and [/ c o d e] (without spaces)

[NiKoLai_]

Ok, here are the tests I have done yesterday evening:

Mr.RC-CAM:

- I tested again your suggestion about the fuses and the circuit works fine. I compared the behaviour with and without the fuses and without them, the circuit freezes easily.

- Yes, the jumpers are out when programming, and the wiring is the same (suposedly), but I'll check it again.

JimDrew:

- I tried your idea of tieing MCLR and Vdd with a 47K resistor. One time putting the resistor between the pins of the ICSP connector and another between the two pins of the PIC. Both without results. ICSP fails yet.

Malc C:

When breadboarding the nature of the way they are made can have a factor (mainly capacitance I believe) on the way the circuit behaves.

-Can you explain me what do you mean with that? I think my english isn't so good.

- No, I can't read or write to the PIC. Also, I can't read the PIC type using picpgm (picpgm -r). I tried with IC-Prog, too. Without results.

- Yes, I guess that I should make another PCB with a DIP-8 socket. I'll tell something about it when the PCB is done and tested.

- I'll test your idea of 10K resistor between MCLR and Vdd. At the moment, I tried with 47K one, as suggested by JimDrew.

- Here is the code in asm and hex. I don't know how to add fuses configuration to the asm file (and whether it's possible). I load the file on IC-Prog and do the necessary changes.
In the HEX file, I added the .txt extension because the forum doesn't allow uploading of certain extensions. Just rename it to remove ".txt".


#include <p12f675.inc>

cblock h'20'
delay_counter
delay
endc

org h'00'
goto start

org h'05'

start:
call startup
main:
call lighting
;movlw b'00010110'
;movwf GPIO
call voltage_test
goto main

lighting:
;light1
bsf GPIO, 2
movlw h'43'
call delay_ms
bcf GPIO, 2
movlw h'43'
call delay_ms
bsf GPIO, 2
movlw h'43'
call delay_ms
bcf GPIO, 2
movlw h'9C'
call delay_ms
;light2
bsf GPIO, 1
movlw h'43'
call delay_ms
bcf GPIO, 1
movlw h'43'
call delay_ms
bsf GPIO, 1
movlw h'43'
call delay_ms
bcf GPIO, 1
movlw h'9C'
call delay_ms
;light3
bsf GPIO, 4
movlw h'43'
call delay_ms
bcf GPIO, 4
movlw h'43'
call delay_ms
bsf GPIO, 4
movlw h'43'
call delay_ms
bcf GPIO, 4
movlw h'CF'
call delay_ms
movlw h'CF'
call delay_ms
return

startup:
;start-up
movlw b'00001110'
movwf CMCON
bsf STATUS, 5
clrf ANSEL ;Voltage alarm adjustement
movlw b'10001100' ;10001100 = 9.6v
movwf VRCON ;10000101 = 6.4v
clrf TRISIO
bsf TRISIO, 0
bcf STATUS, 5
clrf GPIO
return
;end of start-up

;330 ms FF
;200 ms 9C
;180 ms 8C
;160 ms 7C
;140 ms 6C
;53 ms 28
delay_ms:
movwf delay
bucle_delay:
;micro delay start
movlw h'FF'
movwf delay_counter
micro_bucle:
decf delay_counter, 1
movf delay_counter, 1
btfss STATUS, 2
goto micro_bucle
;micro delay end
decf delay, 1
movf delay, 1
btfss STATUS, 2
goto bucle_delay
return

voltage_test:
btfsc CMCON, 6
goto voltage_alarm
bcf GPIO, 5
return

voltage_alarm:
bsf GPIO, 5
return

end


Best wishes.

[JimDrew]

Where are you CONFIG bits assigned?

[Malc C]

As Jim stated, your config settings seem absent from your ASM code. You need to set the configuration bits at the start of the code. Here is an example of the CONFIG settings I use with a 12F675 to flash some LEDs.



list p=12F675
#include "p12f675.inc"

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _CPD_OFF


The comments regarding the breadboard apply to the solderless breadboards that you simply push the components into. These have metal contact strips under the holes and as such can cause some issues with capacitance, so I'm told.

My gut feeling is that the issue will be resolved by setting the config bits, adding a 10K resitor between MCLR and Vdd.

[NiKoLai_]

I didn't include the config bits in the code because I didn't know how to do it. It's my first code. As stated above, I set the fuses I need with IC-Prog before programming the device.

I changed 47K resistor to 10K resistor between MCLR and Vdd and ICSP fails yet.
This evening I'll try the code you posted for the config bits.
I hope this will solve the problem.

I'll post the results here tomorrow, so so.

Thanks to all for the help.

Best wishes.

[Mr.RC-CAM]

I tested again your suggestion about the fuses and the circuit works fine. I compared the behaviour with and without the fuses and without them, the circuit freezes easily.
Glad to hear the manually entered config bits resolved the power-up problem. Once you get the ICSP to work, life will be good. :)

[MatC]

re: marginal programmer and breadboarding issues:
Protoboard (the plug-in things) has significant capacitance between the pins because of all the extra metal there, and you're dealing with cmos so the resistance (high as it is) between pins may be an issue too. Good PCB's (esp soic based) have much better capacitances, inductances and resistances between pins/along the traces.

This isn't normally a factor at frequencies that the PIC operates at, but being cmos they can be temperamental if abused (eg floating inputs, mclr not configured right, etc) that leads to intermittant failures (or perhaps intermittent successes) on protoboard rather than PCBs. It would have to be a very marginal setup that would be affected by this for PIC stuff, but it's a possibility.

Is your SOIC device on the PCB the same as the PDIP device on your protoboard? Not a different chip revision? (Not even sure if there is a 12F675A yet...). Are you using the same lead for proto and PCB icsp? You're right that it shouldn't matter at 10-15cm, but it's just possible it does :)

[rmteo]

Nikolai,

For newcomers to PIC programming, I would generally recommend using a high level language - C, Pascal, BASIC etc. However, if you want to dabble with ASM, a good simulator will be very helpful. You can step thru your code, look at register values, see what the ports and peripherals are doing....

Take a look at this one:
http://www.oshonsoft.com/pic.html
You can download a free trial version. It has a variety of peripherals that can be simulated - LEDS, LCD, stepper motor...

Also, it has a built-in BASIC compiler and you can program in ASM too. The BASIC compiler generates ASM so you can learn a lot from it. You can also embed ASM into your BASIC CODE. If you decide to buy the software, it is about $50 for a personal license.

Disclaimer: Not connected in any way with them - just a satisfied customer.

[Malc C]

Try loading the code below. It should flash the three LEDs on GPIO.4, GPIO.2 and GPIO.5 with a double pulse in a loop.- works for me here with a 10K resistor between MCLR and +5v


;12F675 Flashing LED using software delay

list p=12F675
#include "p12f675.inc"

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _CPD_OFF

del_lo equ 0x20
del_hi equ 0x21

org 0x00
nop
goto init

org 0x04
return

init
banksel 0x80 ;select upper register bank
clrf ANSEL ;make all I/O ports digital
movlw 0x0B
movwf TRISIO ;make GP4 and GP5 outputs
banksel 0x00 ;select lower register bank
clrf GPIO ;initialise all outputs
clrf del_lo ;initialise delay counter low byte
clrf del_hi ;initialise delay counter high byte

flash
bsf GPIO,4 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,4 ;set output GP4 low
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bsf GPIO,4 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,4 ;set output GP4 low
movlw 0xFF
movwf del_hi
call delay ;call the delay subroutine


bsf GPIO,2 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,2 ;set output GP4 low
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bsf GPIO,2 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,2 ;set output GP4 low
movlw 0xFF
movwf del_hi
call delay ;call the delay subroutine

bsf GPIO,5 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,5 ;set output GP4 low
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bsf GPIO,5 ;set output GP4 high
movlw 0x45
movwf del_hi
call delay ;call the delay subroutine

bcf GPIO,5 ;set output GP4 low
movlw 0xFF
movwf del_hi
call delay ;call the delay subroutine

goto flash ;go back and do it again

delay
decfsz del_lo,f ;decrement the low order delay register
goto delay ;go back if it hasn't reached zero
decfsz del_hi,f ;decrement the high order delay register
goto delay ;go back if it hasn't reached zero
return ;return to where the subroutine was called

end


try it on your breadboard, and then in your pbc... at least that way it will prove its either the code or the pcb thats at fault

If you want a decent programmer have a look at the USB ISCP programmer from CT-Tuning http://www.ct-tuning.co.uk/ - works fine with ISCP of a 12F675

[NiKoLai_]

Mr.RC-CAM

Glad to hear the manually entered config bits resolved the power-up problem. Once you get the ICSP to work, life will be good.

I'm gladder than you about that, I can ensure that :rolleyes:

However, I disappointed with myself because I can't make ICSP work.

MatC:

Yes, I know something about the problems a protoboard (breadboard is the same thing?) caused by capacitances and bad connections between leads and metal strips. But it's funny because is the PCB and not the protoboard which fails.

I think that two PICs are 12F675, not A. However, I'll recheck that. Is this enough to ensure they have the same chip revision?

I'll try to program the device with a shorter cable. Let's see what happens.

rmteo:

I use the simulator of MPLAB and it works fine, but I can only see the register values, not see connected devices. It's harder to understand but it's understandable. Even so, I downloaded the software you recommended and I'll test it. Thanks for the suggestion.

Malc C:

I'll try your code and tell something to you. Thanks for post it. But a code problem couldn't be related with ICSP failure, can it?

I tried to put a tie MCLR and Vdd with the 10K resistor you said and ICSP fails yet. I'll do some another test I have in mind and I'll tell something to you all.

Best wishes to all.

[JimDrew]

If you do not have the CONFIG bits set correctly, ICSP can definitely fail. You NEED to have the _CONFIG statement (followed by the proper config bits) in the header of your code, as shown by MalcC. I would not trust setting the bits manually. Most programmers can re-load the object code prior to programming, and if that occurs and no CONFIG bits are set, who knows what you will end up with.

I would try programming MalcC's code into your 12F675 and see if it programs correctly.

[NiKoLai_]

Most programmers can re-load the object code prior to programming, and if that occurs and no CONFIG bits are set, who knows what you will end up with.

JimDrew:

I don't know what do you mean with "object code". I would be grateful if you explain exactly what do you mean and how a wrong code can make ICSP stops working. I thought that it was not possible.
I can tell to you that I *think* my programmer does if it is useful for you:

- Performs a reading of the PIC code. I don't know what it does exactly. I think it reads OSCAL and band-gap values (perhaps something else) in order to save them in the PIC while programming the new code.

- Programs the PIC, and then, read the memory again to verify it has written successfully.

MatC:

- I tried to program the PCB connecting directly the ICSP port of the programmer to the port of the PCB. No results.

Malc C:

- I soldered some thin wires *directly* to the PIC to construct a simple ICSP port and test your code and mine (with the changes suggested by you all), and it works (the port).

- Then, I loaded your code and tested the PCB. Later, I tested mine. Both codes perform well the startup, and the lighting sequence works well, but there is a little problem. All LEDs remain partially lit up when it should be off. The lighting up is correct in all of them.
The partial lighting of the LEDs is faint, but it's visible. I have to say that I don't have this effect in the protoboard. The behaviour of the protoboard-mounted circuit is perfect for both codes.
(the PCB has the 10K resistor between MCLR and Vdd)

- I have been thinking in some kind of "inter-track" coupling to explain the partial lighting of the LEDs but I have not any explanation for the ICSP failure.

That's all for now. I would like to hear new theories (if there are) to solve the problem. I'll try to prove new ideas. I'll post something here.

Best wishes to all.

[Malc C]

The only thing that is obvious to me from looking at the schematic and PCB is that J2 shows a return for the LEDs to GND (ie there are 5 pins on J2 on the schematic) but on the PCB you just have 4 outputs and no return... where are you connecting the return for the LEDS, as this may have a bearing on why there is some conducting when they should be OFF.

The other possible cause is the flux in the solder causing a path for a slight leakage between the pins of the PIC on the PCB. If it were me I would redesign the PCB to accept a DIL device and try programming that, both via ISCP, and via the socket on the programmer. If this works then you'll know that the problem was a physical fault on your original PCB.

[Malc C]

NikoLia,

Ok just programmed a PIC with the following code based on your code with some config settings


list p=12F675
#include "p12f675.inc"

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & _MCLRE_OFF & _CPD_OFF

cblock h'20'
delay_counter
delay
endc

org h'00'
goto start

org h'05'

start:
call startup
main:
call lighting
;movlw b'00010110'
;movwf GPIO
call voltage_test
goto main

lighting:
;light1
bsf GPIO, 2
movlw h'43'
call delay_ms
bcf GPIO, 2
movlw h'43'
call delay_ms
bsf GPIO, 2
movlw h'43'
call delay_ms
bcf GPIO, 2
movlw h'9C'
call delay_ms
;light2
bsf GPIO, 1
movlw h'43'
call delay_ms
bcf GPIO, 1
movlw h'43'
call delay_ms
bsf GPIO, 1
movlw h'43'
call delay_ms
bcf GPIO, 1
movlw h'9C'
call delay_ms
;light3
bsf GPIO, 4
movlw h'43'
call delay_ms
bcf GPIO, 4
movlw h'43'
call delay_ms
bsf GPIO, 4
movlw h'43'
call delay_ms
bcf GPIO, 4
movlw h'CF'
call delay_ms
movlw h'CF'
call delay_ms
return

startup:
;start-up
movlw b'00001110'
movwf CMCON
bsf STATUS, 5
clrf ANSEL ;Voltage alarm adjustement
movlw b'10001100' ;10001100 = 9.6v
movwf VRCON ;10000101 = 6.4v
clrf TRISIO
bsf TRISIO, 0
bcf STATUS, 5
clrf GPIO
return
;end of start-up

;330 ms FF
;200 ms 9C
;180 ms 8C
;160 ms 7C
;140 ms 6C
;53 ms 28
delay_ms:
movwf delay
bucle_delay:
;micro delay start
movlw h'FF'
movwf delay_counter
micro_bucle:
decf delay_counter, 1
movf delay_counter, 1
btfss STATUS, 2
goto micro_bucle
;micro delay end
decf delay, 1
movf delay, 1
btfss STATUS, 2
goto bucle_delay
return

voltage_test:
btfsc CMCON, 6
goto voltage_alarm
bcf GPIO, 5
return

voltage_alarm:
bsf GPIO, 5
return

end


On the breadboard the LEDs run a sequence of double flashing each LED in rotation commencing with GP2 (then GP1 and GP4). If I connect GP0 to a 10K pot accross the +5v supply,when the voltage is near the +5v the LED on GP5 is off, iand then as the pot is adjusted connected the LED on GP5 lights as it passes a threshold. - I take it that this is what you want to happen.

This suggests that the problem is with the programming of the SOIC device. Or a fault with your PCB. As you are using standard resistors etc, then why make life difficult by using a PIC designed for surface mounting, try re-designing the PCB using a DIL IP version PIC...

[NiKoLai_]

The return for the LEDs is the long rectangle at the right of the ICSP port and above of JP2. I solder all LED's leads there.

Yes, the idea of my code is the idea you are talking about. GP5 must light when the voltage reduces from certain threshold (9.6v supposedly).

The reason to use SOIC PICs is the smaller size. DIP is enormous compared with it.

I was almost sure since the beginning that the error was an error in my PCB, but I didn't know what it can be and how to fix it. If the problem were the flux between tracks, the problem would be solved, but if the problem is a bad PCB design, another PCB would have the same errors of the one I've done now. That's the reason I posted this thread. Trying to find this error before doing another PCB.

I thought in some solution to the ICSP problem. If the problem is caused by coupling between tracks, I can put ICSP tracks in the other side of a double-layer PCB to improve isolation and track lenght.
The problem relationed with the LED lighting would be the thing you are talking about, a leakage between tracks or a coupling as well. I don't know exactly how to fix it, apart of designing another PCB with a DIP PIC where leads are more separately.

Best wishes.

[Malc C]

The reason to use SOIC PICs is the smaller size. DIP is enormous compared with it.

I would agree with you if you were using surface mounted devices throughout, but as you have used normal descrete resistors (presumably 1/4 watt) I personnaly can't see any advantage in using a SOIC device, as the saving will be of no real consiquence. Also, unless you are aiming at using this device in a very small model, most craft can handle the few grams your board will end up weighing.

The attached image showes a similar project I made a few years back, and even using Veroboard the module was still small enough to mount on a Piccolo / Hummingbird helicopter

As for the PCB, I don't know what application you used to draft up the images in the original zipfile, but have a look at Eagle (www.cadsoft.de). If you havenot got your own laser printer then a photocopier works just as well to make yourm own boards. This way you can make as many boards as you like.

[NiKoLai_]

Yes, I used Eagle to do both the schematic and the PCB :rolleyes:
I also use a transparency (special for a ink-jet printer) to print the design. I should do more tests, but I am quite glad with the results.

Apart of trying making my first pcb work, I'll do another one when I have some time. Now I am a bit busy. I'll post some results here, if there are.

Thanks to all for the help given :)