Weird issue with Lab X1

Using PBPro, 16F877 compiles, programs and runs fine, the LED bar blinks at the proper rate. If I reset MCLR, the LEDs blink at proper speed.

But if I disconnect the X1 power and reconnect the LEDs blinks at turbo speed. I reset MCLR and it does the same thing.

Has anyone had something similar to this? It's as if it loses the oscillation.

DEFINE OSC 4 ' Set oscillator speed
TRISD = 0 ' PORTD to all output
loop: PORTD = %00000000
pause 200
PORTD = %11111111
pause 200
Goto loop ' Do it forever
END ' Terminate processing

PIC BASIC Pro v2.46a
Microcode Studio Plus v3.0.0.5
MeLabs USB Programmer v4.24 using default configurations switches
Lab X1 using all default jumpers running at 4 MHz

I've been out of the loop for a while, so please bear with me if this is something real stupid.

I have never used that board but I have heard of others using that type with the programmer software setting the fuses giving trouble.

Should be some place in the programmer software to turn that option off then set the fuses in code space or the *inc file.

Maybe....

Robert,
Are the OSC pins on the board set for 4Mz or a faster rate?

Quote:

---

Originally Posted by MOUNTAIN747

Robert,
Are the OSC pins on the board set for 4Mz or a faster rate?

---

Yup, 4, using onboard crystal.


"Lab X1 using all default jumpers running at 4 MHz"

Quote:

---

Originally Posted by mackrackit

I have never used that board but I have heard of others using that type with the programmer software setting the fuses giving trouble.

Should be some place in the programmer software to turn that option off then set the fuses in code space or the *inc file.

Maybe....

---

The part I don't get is that the program works perfectly as long as I don't disconnect power. I can program over and over, no problem.

Remove power, reconnect and boom, LEDs blink at turbo rate. I reprogram, LEDs now work fine.

I can disconnect programmer as the program runs, LEDs continue to blink properly.

Quote:

---

Originally Posted by mackrackit

I have never used that board but I have heard of others using that type with the programmer software setting the fuses giving trouble.

Should be some place in the programmer software to turn that option off then set the fuses in code space or the *inc file.

Maybe....

---

I look in the sample programs and none of them use includes. I remember that we had to use them before, but it's been long enough that I don't know if this is now the way things are done.

The programmer does identify the PIC 16F877 properly.

Depends what you want to include. Not sure what you are getting at?

Quote:

---

Originally Posted by mackrackit

Depends what you want to include. Not sure what you are getting at?

---

We used to include stuff like 18F877x, I can't find any more examples, don't have my old drive. It was long files with a ton of variables and addresses inside, I think in assembler.

And then there's this stuff:


ASM
LIST
include 'M16F62x.INC' ; PM header
device pic16F628, hs_osc, wdt_off, pwrt_on, mclr_off, lvp_off, protect_off
XALL
NOLIST
ENDASM


I can't find one I used for a 16F877, and no longer remember which of these switches we used.



EDIT: Found M16F87X.INC, that looks like what I was thinking about.

That all was either before my time or by the looks of it maybe a PM thing. What if tou used MPASM? Just curious...

Now modedefs seems about the only thing that PBP requires and only for certain command.
But you can still use includes, you are going to love some of the stuff Darrel has done.

Looking at the schematic of the LABx
http://melabs.com/downloads/labx1sch.pdf
What does U2 do? Bad chip?
I am just guessing... as usual :)

The ICS502 LOCO™ is the most cost effective
way to generate a high quality, high frequency
clock output and a reference from a low frequency
crystal or clock input. The name LOCO stands for
LOw Cost Oscillator, as it is designed to replace
crystal oscillators in most electronic systems. Using
Phase-Locked-Loop (PLL) techniques, the device
uses a standard fundamental mode, inexpensive
crystal to produce output clocks up to 160 MHz.
Stored in the chip’s ROM is the ability to generate
6 different multiplication factors, allowing one
chip to output many common frequencies...


It's used to generate the clock, the jumpers are set to 4, and it works fine, until I replug.

I would say it works fine, or else it wouldn't work at all when I program.

I found these:

E:\Mecanique\MCSP\MPASM\P16f877.inc

E:\Pic BASIC Pro 2.46\16F877.INC

E:\Pic BASIC Pro 2.46\M16F87X.INC <---- I would think I want to include this one.


So I tried this:


ASM
LIST
include 'M16F87x.INC' ; PM header
device pic16F877, xt_osc, wdt_on, pwrt_on, lvp_off, protect_off
XALL
NOLIST
ENDASM


And I get an error it cannot open file, include 'M16F87x.INC' not found.

In MicroCode Studio Plus, under tabs VIEW, EDITOR OPTIONS, the Default Source Folder points here:
E:\Pic BASIC Pro 2.46

I would have thought it would pick up the file that way.


EDIT: So I copied M16F87X.INC where I have my PIC program source, usually compilers look in their source folder first, but it can't find it anyways. It looks like it wants to find INCLUDE files somewhere specific, I just don't see any way to tell MCSP.

Look in you PBP directory for 16F877.inc. That file is already included there, you do not need to worry about it.

In my opinion if you are getting back into this for the long term give up on PM and use MPASM. You will have to at some point, might as well be now.

Yeah, I looked at the generated files and opened up LST, very interesting.

I noticed it was already picking up P16F877.INC.

Then it picked up PBPPIC14.LIB.

And then further down it tried to open the include I provided. So it seems as if everything is in there now. Except it uses this for the switches:

__config _XT_OSC & _WDT_ON & _PWRTE_ON & _LVP_OFF & _CP_OFF

And I'm wondering if this is what I have to set properly, and how.


EDIT: And yes, I am pointing to MPASM in MicroCode Studio Plus.

Yup, fuse are very important :)

You can modify the *.inc file or set them in code.
http://www.picbasic.co.uk/forum/showthread.php?t=543

That's what I'm trying to do, thanks.

I don't like changing the include, in case I have different needs in another program.

So I tried this:

@ __config _CP_OFF & _DEBUG_OFF & _WRT_ENABLE_ON & _CPD_ON & _LVP_ON & _BODEN_ON & _PWRTE_ON & _WDT_ON & _XT_OSC


But it's doing the same thing, the speed goes crazy when I reconnect.

Not sure if I set the switches properly though.

EDIT: I list all switches, that way I can easily see what is available without going back to datasheet, even if I use default values.

Might want to turn LVP off, I do not think you are using it.

I keep going back to hat fancy OSC thing. The 877 is pretty straight forward. Has to be the OSC acting up to cause a change in speed. Power cycling causing a clitch? And somehow the programmer is resetting it?

LVP OFF is the first thing I tried, no diffference.

I unplug the USB cable to the programmer or disconnect the programmer completely from the Lab X1, touch the oscillator and the timing returns to normal speed!

Ok, so what can be the causes of something like this? This goes into capacitance stuff and that's over my head.

Being I just learned about that OSC and have not pulled the data sheet I do not know.

But...

I will make an assumption that this board was in storage since you say you have been out of this for awhile. Look for loose/broken connections and corrosion/tin whiskers.

Maybe put it under a heat lamp for a bit.

Can't see anything wrong with it. I emailed MeLabs support, hopefully they can figure this out.

I paid over $200 for this puppy, I finally get around to using it and it's acting funky. :(

At least the USB programmer was a nice step up from the serial programmer, but darn, this hobby doesn't come cheap.

Hi, Robert

Could you verify which is your Osc setting ON THE CHIP by re-reading it ...

I suppose for some reason there's no CONFIG Writing and you run your default RC osc ...
( option to tick somewhere for programmer ??? - MPLAB Has ! )

For your Missing link to Antoon gadgets ...

just try this one : http://www.sentex.ca/~mec1995/index.htm ...

Alain

Robert, do you have an oscilloscope or frequency probe to check the actual clock frequency that's being supplied to the chip? I would start there before pursuing config settings and include files. I wouldn't be surprised, though, if the frequency corrects the instant you touch the pin with a probe.

My gut feeling is that there is an open connection somewhere in the clock multiplier circuity. This could be as simple as a pin on the surface mount chip that was deprived of solder. This has happened occasionally (though not recently, to my knowledge) and all of the X1 boards are visually inspected for this. But... there is always the possibility that one slipped through.

A careful visual inspection with a magnifier might yield a clue. (Picture Sherlock Holmes.)

I received your email, but I wanted to address the issue of included header files publicly. This may help others understand PBP's compilation process.

PBP handles the inclusion of header files automatically. This is why you have to specify the target device when you compile. If you manually include files like 16F877.BAS, 16F877.INC, M16F87X.INC, or P16F877.INC, it will cause errors.

16F877.BAS is a PBP file that specifies memory map info, library files, etc.. It is also used to set up aliases for special compatibility, like PORTL/PORTH for BASIC Stamp. This file is created by melabs and it is always included.

16F877.INC is an Assembly file that holds default configuration fuse settings and specifies the header file for the assembler. If the device is supported by the PM Assembler, the file holds settings for PM and MPASM. Otherwise it holds only settings for MPASM. This file is created by melabs and it is always included.

Assembler header files hold the names and addresses of internal registers, configuration fuse information (including those mysterious labels that are used in config directives), and other stuff like bit names. Some of the MPASM header files are quite large.

M16F87X.INC is the header file for the PM Assembler. It is included automatically if the PM Assembler is used. melabs creates these files.

P16F877.INC is the header file for the MPASM Assembler. It is included automatically if MPASM is used. Microchip creates these files.

Are you using your U2 USB programmer to power the Lab-X1?

Quote:

---

Originally Posted by Bruce

Are you using your U2 USB programmer to power the Lab-X1?

---

Nope, not possible that I know of. I'm using a 15V 1A wall adapter.

Quote:

---

Originally Posted by Charles_Leo

Robert, do you have an oscilloscope or frequency probe to check the actual clock frequency that's being supplied to the chip? I would start there before pursuing config settings and include files. I wouldn't be surprised, though, if the frequency corrects the instant you touch the pin with a probe.

My gut feeling is that there is an open connection somewhere in the clock multiplier circuity. This could be as simple as a pin on the surface mount chip that was deprived of solder. This has happened occasionally (though not recently, to my knowledge) and all of the X1 boards are visually inspected for this. But... there is always the possibility that one slipped through.

...

---

My oscilloscope is not on hand at the moment, and I suspect the same thing will happen.

I have a powerful magnifier somewhere, I'll have to dig it up and inspect the clock circuitry and report back.

Thanks for description of includes, that was pretty much what I had deducted as I fumbled along yesterday. :)

It does sound like a bad connection/component in the osc circuit.

How does it act it you insert a long delay at power-up?

Say PAUSE 5000 (or longer) before turning any LEDs on?

I had tried with 3000, 5000 didn't make a difference either.

So I flipped the X1 over (now looking at solder side, LCD at the top end):

- touched the oscillator lead tip on the right, no difference.
- touched the oscillator lead tip on the left, blinking returned to normal pace.

Now you know where to use the soldering iron.

Didn't help (didn't have time to try anything else though).

I'm going to dab the legs on the timer IC even if they all look nice and clean. I doubt it will work but I have nothing to lose.

If that doesn't work I'm thinking that maybe the hole for the OSC is not done right, maybe it was supposed to be a via but no signal is going to the top layer.

I'm going to try to remove that 4MHz osc and check the inside of the hole (and continuity if there are pads on both sides). Then solder another one back with longer legs so I can solder both top and bottom.

After that I don't know what else to do except take it skeet shooting next time out. :D