 |
 |
| View previous topic :: View next topic |
| Author |
Message |
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
| 18LF2520 Craziness! |
 Posted: Tue Jul 19, 2005 4:49 pm |
 |
|
Kind Sirs/Ladies-->
I have assembled a PCB surrounding an 18LF2520 after prototyping the entire system therein on a protoboard. All of the connections are correct, and I even replaced the CPU because I thought it must have failed (how I LOVE smd repair!  )...
My problem is this: the program I created in PCH 3.217 works perfectly on my 18F2520 driving the protoboard system but will not respond in any way when loaded into the PCB's chip. Now I know what you'll all say - make a small test program and load it. I did, and it works perfectly. I am running both systems with 5 volts.
I played around with the headers like so:
Original code's header:
| Code: | //Begin pre-processor directives//
#include <18F2520.h>
//#include <math.h>
//#include <ctype.h>
#include <stdlib.h>
//#include <input.c>
#fuses HS, NOWDT, NOLVP, PUT, NOPROTECT, WDT64
#use delay(clock=20000000)
#use i2c(MASTER, FORCE_HW, FAST, SCL=PIN_C3, SDA=PIN_C4)
#use rs232(BAUD=9600, BITS=8, PARITY=N, XMIT=PIN_C6, RCV=PIN_C7, STREAM=hwrs232, ERRORS)
#use rs232(BAUD=9600, BITS=8, PARITY=N, XMIT=PIN_C0, RCV=PIN_C1, STREAM=swrs232) |
Complete test code:
| Code: | //Begin pre-processor directives//
#include <18F2520.h>
#fuses HS, NOWDT, NOLVP, PUT, NOPROTECT
#use delay(clock=20000000)
#use rs232(BAUD=9600, BITS=8, PARITY=N, XMIT=PIN_C6, RCV=PIN_C7, STREAM=hwrs232)
#use rs232(BAUD=9600, BITS=8, PARITY=N, XMIT=PIN_C0, RCV=PIN_C1, STREAM=swrs232)
//End pre-processor directives//
void main()
{
while(1)
{
while(input(PIN_B0))
{
output_high(PIN_C2);
fputs("Blink", swrs232);
delay_ms(100);
output_low(PIN_C2);
delay_ms(100);
}
}
} |
I can't understand why the original code runs on the protoboard, then when loaded into the PCB (identically interconnected and with the same components) I get nothing. In the original code I enable lots of interrupts, but only after this statement I put in to test the system:
| Code: | void main()
{
while(1)
{
while(input(PIN_B0))
{
output_high(PIN_C2);
delay_ms(100);
output_low(PIN_C2);
delay_ms(100);
}
}
... |
I can send the entire original code to anyone who wishes to help, but it's quite long and I'd rather not post it unless necessary. 
Has anyone ever experienced this phenomenon before? I'm about to spontaneously combust! |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 19, 2005 5:07 pm |
|
|
| What happens if you install an "F" chip on your final board ? |
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Tue Jul 19, 2005 5:15 pm |
|
|
Well, right now I have no 18F2520's around, and my PCB pads really don't like me to remove a CPU. I can order more samples, but I would like to see if anyone has seen any errata about the low-voltage versions before I spend another few hours removing this thing.  |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 19, 2005 5:38 pm |
|
|
Somewhere, I think maybe on this board, I have seen a post where
they have a "LF" device that won't run at 5v. But I can't find it, so
I'm not sure. It could have been the brownout setting. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 19, 2005 5:42 pm |
|
|
To easily remove a SMD chip, you can use ChipQuik.
It's a special solder that, when mixed with regular solder, causes
it to melt at just above room temperature. You can lift the old
chip off easily. You then clean up the pads with solderwick.
Here's a photo of it:
http://rocky.digikey.com/WebLib/Chip%20Quik/Web%20Photo/SMD1.jpg
I use sharp side cutters to cut off small pieces of the chipquik solder
and then use tweezers to place them between the pads of the IC.
It's better to use small pieces of chipquik because if you use too
much it makes a mess. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Tue Jul 19, 2005 8:31 pm |
|
|
| Look on ebay and you will find cheap ($200) hot air smd equipment. I have a benchtop model that will heat both sides of the board. It takes about 20-25 seconds to remove a chip. They make doing prototypes a breeze too. I would recommend anyone thinking about doing any surface mount work to get one. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 19, 2005 9:48 pm |
|
|
We were thinking about this just a while ago at the company.
What model do you have, or what model do recommend that's
normally available on EBAY ? |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
| Re: 18LF2520 Craziness! |
| Posted: Wed Jul 20, 2005 2:55 am |
|
|
| UFAnders wrote: | In the original code I enable lots of interrupts, but only after this statement I put in to test the system:
| Code: | void main()
{
while(1)
{
while(input(PIN_B0))
{
output_high(PIN_C2);
delay_ms(100);
output_low(PIN_C2);
delay_ms(100);
}
}
... |
|
Am I understanding it correctly when you say the small test program is working on your pcb, but the real application with the same testroutine embedded in your main is not working?
If yes, then it is not likely the hardware to be the problem but some kind of configuration option not shown in the code you are giving us. Two things come to mind:
1) In your real application you have set the WDT64 fuse, this suggests you are thinking about using the watchdog. Are you calling setup_wdt(WDT_ON) somewhere? This will enable the watchdog, but confusing, will only enable the watchdog when the fuse is set to NOWDT.
2) Another possible difference between the two programs might be the use of a directive like #use fast_io or #use fixed_io. Try changing your main function to:
| Code: | void main()
{
#USE STANDARD_IO(B)
#USE STANDARD_IO(C)
while(1)
{
while(input(PIN_B0))
{
output_high(PIN_C2);
delay_ms(100);
output_low(PIN_C2);
delay_ms(100);
}
}
... |
|
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Wed Jul 20, 2005 8:04 am |
|
|
To answer your questions, ckielstra:
1. Yes, you are understanding the predicament correctly - My real application will not run; the test program snippet embedded into the real application does not execute.
2. (Please forgive this hideous run-on sentence  ) I use the WDT64 fuse because a button tied to RB0 is meant to execute an interrupt handler that starts the watchdog timer and then dives into an infinite loop in order to reset the system once the watchdog runs out. I tried to use reset_cpu(), but I and others in this forum were having trouble with it.
I just tried the #use standard_io(x) statements, but nothing is different. 
Thanks for everyone's help thus far, I just ordered some more samples of the 18F2520 in the SOP package. But until those get to my door, I'm eager to try out other options before I remove the LF chip. |
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
| Re: 18LF2520 Craziness! |
| Posted: Wed Jul 20, 2005 9:00 am |
|
|
| UFAnders wrote: |
I can't understand why the original code runs on the protoboard, then when loaded into the PCB (identically interconnected and with the same components) I get nothing. In the original code I enable lots of interrupts, but only after this statement I put in to test the system:
[code]void main()
|
I can't understand this either, unless the part about "identically interconnected" just isn't true.
Spend a few hours getting up close and personal with your PCB. Make sure you have a clock signal. Verify the connectivity of each and every signal off the PIC. Pay close attention to any hardware/interrupt connections required by your real code, as opposed to your test code. If you can make an LED blink, you can arrange for it to turn on and off at reasonable times in your real program, so you can tell (eventually) just where your program is hanging up, or if its running at all.
By "identical", do you mean power supplies too, or is the board powered differently? Is your PCB power regulated?
Good luck |
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Wed Jul 20, 2005 10:37 am |
|
|
sseidman: I understand your concern about the hardware connections, and how often times a protoboard can be wired one way though the final fabrication can have a few differences  . I have the test program running perfectly - I get "Blink" on my terminal and the LED flashes every 100ms. However it appears that my real application is not running at all, falling short of main() altogether.
I have been powering my boards (proto and PCB) with an LG cellular phone charger (5.2v at 800mA) with no problems as far as I can tell.
Thanks for all the ideas, guys! I hope I can find a solution soon... |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Jul 20, 2005 11:59 am |
|
|
| Quote: | | 2. (Please forgive this hideous run-on sentence Shocked ) I use the WDT64 fuse because a button tied to RB0 is meant to execute an interrupt handler that starts the watchdog timer and then dives into an infinite loop in order to reset the system once the watchdog runs out. I tried to use reset_cpu(), but I and others in this forum were having trouble with it. |
I remember a thread like this, but there it concerned a PIC16 processor which doesn't have a hardware reset instruction but performs a jump to address 0. The PIC18 has a real reset instruction which does reset the internal registers, so I don't think you have to go this difficult way.
Just trying to come up with more differences between your two hardware designs:
1)- What are the revision numbers of your F and LF version chips?
2) What size is the large application?
3) What is the starting address of main() in your large application?
4) Do you use #zero_ram? |
|
|
UFAnders
Joined: 13 Apr 2005
Posts: 36
Location: Michigan
|
|
| Posted: Thu Jul 21, 2005 1:16 pm |
|
|
Guys, you won't believe this-->
After I plugged an 18LF2520 into my protoboard and loaded the whole program, it worked fine. That, however, isn't the interesting part!
The interesting part is that I created a new project file in MPLAB 7.10 and copied the original whole program to the new project's directory. I compiled it with all of the header files it originally called for, loaded it into the PCB and IT WORKS!
What the hell. The only thing I did differently is rename the original source filename from "RaveGear18_2005.6.14.c" to "Central Controller Test.c" and one of the header files from "frameDefs_2005.6.14.h" to "frameDefs.h"
Regardless of the internal problem, my problem is fixed. Thank you everyone who helped me along the way! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
