Strange Baud-rate, suspect brgh=1 might cause it?

[Dargar]

Hello again!

I just noticed while debugging our software on the target PIC that I couldn't get anything but garble from it. I'm using the 16F877 PIC running a 20.00Mhz x-tal (with two 15pico, I think it was pico, farad capacitance).
This is how I have set up the com.

#include <16F877.h>
#device adc=10
#fuses HS, NOLVP, NOWDT, PUT

#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)


I use a "while(true)" loop, and just tried to print out BEXUS (to limit sources of error) but still just got garbles.

I hooked the RS-232 signal output (from MAX232) to a digital oscilloscope and noticed how one bit was just slightly under 10us long. It should have been 104us long shouldn't it?

I changed two things, so the header looks like this:
bla bla unchanged and then:
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

and voila! I get my BEXUS in the terminal program. It would seem that for some reason I cant run a 20Mhz xtal and use 9600 baud, at least not without adding some to my code? Why is this? According to the pic data-sheet it should be ok?

In the manual it says BRGH10K "allow bad baud rates on chips that have baud rate problems" I assume this is to ignore the error generated if the baud-rate can not be obtained to within 3% of the set value, but I don't get an error so I shouldn't need to use this right? or?

I might not need to run it at 20Mhz, but I have to assume that I have to use either 20Mhz or 16Mhz because I don't know if 4Mhz will give me the overhead I need to do all the background tasks in between sampling.

So, any idea why I don't get proper 9600baud communication with the 20Mhz header and xtal?

[PCM programmer]

1. Post the version of your compiler.

2. Post the complete part number that is printed on the top
of your PIC chip. It's possible that you have a PIC
that is only rated for 4 MHz operation.

[Dargar]

IDE version 3.36
PCM version 3.170

As for the printing on the top of the PIC, I will have to get back to you tomorrow, I don't have it home with me!
I know it is not a 16F877A though, if that helps.

PIC#1: "PIC16F877 - 20I/P 0105HGA"
PIC#2: "PIC16F877 - 20I/P 0229JPT"


Feel free to share the url to the list where you look up production batches or whatever those last numbers are.

[Dargar]

So, is it the pic or is the error somewhere else? I noticed that when I edited my previous post with the additional info, the thread wasn't "bumped" and so I assume that PCM programmer have not yet noticed that I have updated it with the requested information. . so I guess this is bumping, but I hope you will all forgive me. In the future I will not use "edit" to add information.
Thank you.

[Guest]

I made a test program, without changing your pre-processor statements,
and it ran OK. I tested it with:
1. A 20 MHz crystal
2. A 20MHz 16F877
3. PCM vs. 3.170
4. Hyperterminal

The output looks like this:
BEXUS
BEXUS
BEXUS
BEXUS
etc.

So I think the problem is not the PCM version or the PIC.
You said you had short pulses coming from the MAX232.
Do you have the proper capacitors on it ?
MAX232 uses 1 uf caps. MAX232A can use 0.1 uf caps.
Make sure they are installed properly per the data sheet.


#include <16F877.h>
#device adc=10
#fuses HS, NOLVP, NOWDT, PUT
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

main()
{

while(1)
{
printf("BEXUS\n\r");
delay_ms(500);
}

}

[PCM programmer]

Hi Dagar,
The post above was from me. Somehow, I was logged in as Guest,
but I fixed that now.

[Dargar]

Thank you for your verification that it can and should work. I will look into it tomorrow if I can.

Things have been so weird lately you would think that higher powers are working against the project...

In my group we have experienced, among other abnormalities, the following:

-CCS IDE appending an extra .h to header files (myheader.h.h) and failing to load them
-Updating a header file and explicitly saving it, next time we run, it "changes back" to what it was before, once we had to use notepad to get the change to stick
-device not found or some such (I didn't use it at the time so I don't know the exact wording)

-MPLAB telling me that it cant load a hex file (myhex.hex) because of an unsupported file type or read only (file type was hex, and it was not read only) this happened to older hex files that I had programmed through mplab before.

-2 of 3 PIC-start plus programmers were discovered to somehow have blanked themselves (this smells of sabotage in my mind, but I'm probably just paranoid) and the last one was broken by our technician when he tried to use an ALL-11 (Hi-Lo systems) programmer to re-program the chips.. When he did a "READ" from the one pic-start left, he was left with a blanc chip.

-Left with a deadline fast approaching and all pic-start programmers temporarily out of function, we tried to use two different hi-lo system programmers, but got error on the first mem-adress in about 8 out of 10 tries. when it programmed and confirmed we were thrilled... then we plugged the chip into our test-board, ran hyperterminal and watched nice data for 0.5 minutes, then the PIC started garbling, and it was sizzling hot. We checked EVERYTHING 3 times (one time to gether and two people independently) without finding any shorts or other faults!

Thats about when we gave up and called it a day!

EVERYTHING just seems to go wrong now.

I'll see if the Electron is on my side tomorrow! ;)

Thanks for great support from you all!

[Guest]

CCS IDE appending an extra .h to header files (myheader.h.h) and failing to load them


Try making sure that the Project file is the one you mean to compile (select file, right click, select "make file project", then compile)
this happened to me when first opening the IDE and the first file in the row was a .h file (it was picked as the project)

[neil]

Hi Dargar,
I can relate to you with the unexplained! I have seen all sorts of nonsensical behavoiur in the past and occasionally now. We get all sorts of bursts of noise coming into our lab which sometimes pop or just make hot our analogue (op-amp) based circuits. It is mad trying to prototype where I am, as you can't easily tell if it's external noise, or something 'hooting' in your design!

We eventually traced the source of noise we were seeing on the mains, and coming into out DC supplies to the *large* neodymium glass laser on the floor below us!! The noise coincided with the laser pulsing from its huge capacitor banks!

We installed a large incoming mains filter to our supply which helped a bit, but the rest must be radiated noise, so short of screening the room there's nothing we can do!

So.... what does your supply look like? do you have any pulsed capacitor banks in your vicinity? If it is noise, you could try a hefty zener or a tranzorb on your DC supplies.

Sorry this isn't related to pics, just letting you know you are definitely not alone!!

[Dargar]

Hehehehe! Neil, we don't have any heft lasers around us, but we do have some big antenna dishes running radar and WLAN (over a distance of ~8kilometers or so), mostly though, we are sometimes troubled by our old "friend" the 50Hz from the main-supply (today it was as high as 6V @ 50 Hz in a disconnected circuit! it was just taking it in through the air or something. the only wire was the wire going to it from the oscilloscope!)

Also we have several people working on home-made high-frequency switching regulations and such, so we are having quite a bit of noise here too.

Its nice to hear that weird bugs don't only happen to us!
My favorite one must be one time, I don't remeber exactly what I was trying to build, but it had LED's and BCD displays.
Somehow, I got it to light the LED's when I jumped with both feet from the floor... it wasn't vibrations, and it was apparantly tuned to me, alone.. so I had the worlds niffitest "jump-detector". I never found out how it worked though.

Maybe a capacitance detector or some such.