Sanity check please

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

About a week ago everything I compiled was trash. It compiled OK but didn't run. I wrote this Hello World program and found (by oscilloscope) that the baud rate was about 2900 baud vs the declared 9600 baud. The clock is from an external source and is definately 20MHz. Finally I just uninstalled the compiler and re-installed it and evereything was fine. Now a week later it has happened again!
Has anyone else seen this? Am I doing something stupid? Is there any better solution than simply re-installing the compiler? The compiler version is 3.104 but I can't get the MBA's that run this place to update it. I have my old trusty 2.7x PCB but it won't support the 16C771. The PC is running win2000 ver 5.00.2195.

alexbilo · Joined: 01 Jun 2004 Posts: 39 Location: Trois-Rivières

I found that when these problems arise, looking at the assembly code listing is of great help. You can take a look at the code generated by the compiler to configure the RS232 module to see if the baud rate config seems correct. If you don't know assembly langage, you can even post the configuration code snippet and I'll take a look at it.

Good luck,
_________________
Alex

hillcraft-I am not logged · Guest

We do 90% of our work on 18F458 vs RS232 @ 19200 BAUD.

I have found that the PC (Windows - RS232 UART) actually loses its mind sometimes and that a reboot is the only answer, this happens mostly with a laptop and Delphi after many compiles.

Another thing to look at is ground loops and earthing. We sometimes have very strange results with a project when the project is connected to the PC via USB and the RS232 port...It gets worse when we connect the PC based logic analyzer.

The best thing I have found to test the validity of a RS232 PIC based device when the PC looks like its losing its mind, is to test it against a Palm or an IPAQ, at least you eliminate ground loops, earthing and Windows XP.

Another thing you can do is to short 2 and 3 of the DB9 RS232 cable to one another and type a couple of characters on the PC. You should get the character echoed back properly. When my Compaq is in its 'mindless state', it actually echos garbage back.

Ttelmah · Guest

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Read this thread -- especially Darren's comment about different
device files. Have you recently been installing different versions
of the compiler ?
http://www.ccsinfo.com/forum/viewtopic.php?t=19614

Guest · Posted: Wed Sep 15, 2004 10:55 am

Your transmit pin is B0 what is the external IT input, too. Probably sometimes the ext it is (unexpectly) enabled and every transmit bit causes an IT. In this case the default CCS IT handler is executed (context saving, do nothing then context restore). Just my 2 cent.

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

Using the EC clock fuse, rebooting and un-installing and re-installing the compiler have had no effect. Not only is the baud rate bad, but the 10ms square wave (the while loop) only runs one cycle, then nothing happens untill aparently the watchdog resets (despite the NOWDT fuse) in about 2 seconds.
I guess I will dig out an old PC and put PCW on it and see what it gives.
_________________
The search for better is endless. Instead simply find very good and get the job done.

rnielsen · Joined: 23 Sep 2003 Posts: 852 Location: Utah

I have found out, by my own mistake and hair loss, that if I enable an interrupt without having a ISR defined that the PIC will go brain dead when a delay() function is called. Make sure that you have a routine for EVERY interrupt that you have enabled.

Ronald

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

I tried a different PC and added
disable_interrupts(Global);
with no difference in behavior. Oddly disabling the interrupts made this change in the code to toggle the port pin:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

There are a few things about your test program that I would change.

1. I would use Pin B0 as the recv pin of the soft USART, and Pin B1
as the xmit pin. This gives you the option of using the external
interrupt to detect an incoming start bit. (ie., #int_ext)

2. You're incrementing a "short" variable. Is this operation defined ?
A 1-bit "short" is an invention of CCS. I would regard doing
anything except setting it and reading it, as extremely risky.
I looked at the ASM code for "foo++" and I don't know what its
doing. I don't think it's doing what's intended.

I would change "foo" from a short, to a char. Then the ASM code
looks clean.

3. You're toggling the xmit pin of the soft usart in your while() loop.
I'm not sure why. I would have done several lines of putc('U').
That will test the soft usart.

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

The plague is spreading! A board that has been running for weeks sealed in a watertight housing has suddenly come down with the same problem. It seemed to suddenly stop sending data but upon opening the housing I find that the embedded PC that takes the data from the PIC and combines it with other data and sends it in packets up to the surface is rejecting the data because the baud rate is about 3300 instead of the original 9600 baud!
Somehow it is a hardware problem, not a compiler problem. Time to roll out another set of tools.

Thanks to all that tried to help.
_________________
The search for better is endless. Instead simply find very good and get the job done.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

That's about one third the baud rate. This suggests a crystal that is
supposed to operate in 3rd overtone mode is actually running in
fundamental mode. I would check the external oscillator.

You mentioned a water-tight container. This implies possibly cold
temperatures at an undersea location.

I would open up the suspect unit on the bench and freeze the oscillator
with freeze-mist. Then check the output frequency.

----
Edited for a typo.

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

Actually there are two PICs on the PCB. One is a trusty 16C58B that runs the sonar transmitter off of a 20MHz crystal. The other is the troublesome 16C771. The 16C771 gets its clock from the OSCOUT (pin 15) of the 16C58B which is a rock steady 20MHz when I put a scope on it. In this case the sonar transmitter is idle so there is no EMI from that.

I have three 16C771s on my desk:
A) a windowed part several weeks old that the original development was done on and still has the program.
B) an OTP part that worked for a few weeks and just stopped.
C) another windowed part of the same lot as A but recently programmed.

All three chips verify OK by my Dataman 48 programmer with VCC +/-10%. But A works fine. B & C run slow. Both windowed parts have stickers on the windows.

Maybe tomorrow I will try a different programmer, and a laboratory 20MHz TTL source. But now its 5:00.....Miller time!
_________________
The search for better is endless. Instead simply find very good and get the job done.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I had assumed that "external oscillator" meant it was coming from
a "can". It's actually tapped off the oscillator circuit of the 16C58B.
That's adding a load onto the oscillator circuit.
I would now definitely suspect some interaction that might
cause the oscillator to start up at 6.67 MHz.

This thread on the Microchip forum discusses running 2 or more PICs
from one crystal.
http://forum.microchip.com/tm.asp?m=41722