Propeller Failure?

Sal Ammoniac · 2010-03-02 17:46

I've got an embedded data logging system that uses a Propeller to collect environmental data and send it to a PC for processing. The data are sent over a 9600 baud serial link. This system has been in operation for about six weeks now and has functioned well, but sometime last night the serial data stream has gotten corrupted. The data, which usually looks like this

57.23,61.10,1018.23,54.98,3.28
57.21,61.11,1018.21,54.98,3.29
57.20,61,10,1018.21.54.97,3.29

now looks like this:

57?+,6??,++@10@+?4?92
5?.3+,??.21+,
54.??,6@@+,+??18.,3.@?45@+?

I've reset the system several times and it always comes back up sending gibberish instead of real data. It's almost like the serial baud rate is off enough to generate garbage instead of the correct data. The logger is a custom design using the DIP version of the Propeller and a 5MHz crystal. I have the clock settings set to this:

  _CLKMODE = XTAL1 + PLL1X
  _XINFREQ =  5_000_000

I'm using FullDuplexSerial from the Propeller library for the serial driver. Anyone have any idea what may have caused this to suddenly start happening? I've made no code or hardware changes recently. One minute it was working fine and the next it started sending gibberish. Outdoor temperatures here have been in the 60's, so I doubt I'm running the Propeller outside its environmental limits.

Phil Pilgrim (PhiPi) · 2010-03-02 17:49

Check your serial cable and connectors.

-Phil

Sal Ammoniac · 2010-03-02 18:04

I swapped out the serial cable and that didn't help. The connectors on both ends are okay.

Mike Green · 2010-03-02 18:06

If the Baud is off, it can't be by much since the first character of each line seems to be correct and the carriage return at the end of each line seems to be correct.

It's not the "dreaded PLL selector failure" because it would stop working completely with the crystal. That would happen if you had some electrical noise on the power supply and inadequate filtering at the Propeller and/or left some of the Vdd/Vss pins unconnected.

If your program writes to the EEPROM and somehow corrupted location zero, that would cause the program to get an incorrect CLKFREQ value and the Baud timing would be off.

Try re-downloading your program. If it works ok for a while then you know the EEPROM somehow got corrupted (from a programming error).

Sal Ammoniac · 2010-03-02 18:38

Mike,

Thanks. I'll take a look at the things you mentioned tonight.

My code does not write to the EEPROM, so if it's getting corrupted, then there must be another mechanism doing so. I'm not reusing the two data pins connected to the EEPROM for anything else, so that can't be it either. I'll try re-downloading the code to the EEPROM and see what happens.

The hardware is battery powered and well-filtered, so I doubt I have much noise on the power rails. I also changed the batteries twice without effect. Both power and both ground pins on the Propeller are connected together (with short, low-impedance connections), so I agree that it's probably not the PLL issue.

One thing I forgot to mention in my original post is that this system also has a Xbee to transmit data wirelessly that's separate from the hardwired serial line. This also uses FullDuplexSerial on another cog (and two different ports). The data stream from the Xbee became corrupted at the same time as the data from the wired serial line.

Mike Green · 2010-03-02 18:45

Unfortunately, there's just not enough information provided to make an educated guess about the problem. All we can do is to make wild guesses about possible errors. Normally I'd suggest that your program is somehow writing over itself, but, with the error occurring immediately after reset, that wouldn't be the case. If your crystal is socketed, maybe there's a bad connection that's introducing extra resistance or capacitance throwing off the crystal frequency. Try reseating the crystal.

You should really post your complete source code (as an attachment to a message please!) and a schematic of your setup, maybe with a photo as well showing the layout.

jazzed · 2010-03-02 18:54

If you don't mind posting a .zip of the project, you may get quick answers. You can always remove it later.
BTW, the clkfreq variable is HUB address 0 so any inadvertent write there (memory wrap, etc...) can cause trouble.

ManAtWork · 2010-03-02 21:33

I don't know if it helps but I had a similar problem, today. I found out it was caused by a bad ground connection. The effects were quite weird. Some characters worked, some were turned to garbage and others didn't show up at all. I fixed the ground and everything worked well, again.

Peter Jakacki · 2010-03-02 22:19

I think you must be doing something with the characters on the receive end because the bad ones are always "@"s and "?"s. Anyway, this is either interference or a bad RS232 driver. Check the line with a scope to ascertain whether this is the problem. As mentioned previously, check your ground, but the scope should reveal all.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Graham Stabler · 2010-03-02 22:24

Might be worth checking the PC end too.

Graham

Cluso99 · 2010-03-03 04:49

You mention the xbee gets corrupted also. Did this start when you added the xbee code? Maybe your FDX objects are clashing?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Peter Jakacki · 2010-03-03 05:06

90% of troubleshooting involves elimination. Disable the XBEE and see if it still plays up on the serial connection and then try the other way around. Your problem could even be related to power-supply issues and the lack of proper decoupling especially with regard to those 10uf tantalums as it looks like a droop in the power supply. Who knows, because we don't have even photos or schematics to be able to comment properly. You know the game Sal, open the door and shows us the works rather than making us peek through a keyhole at what you might allow us to see.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Sal Ammoniac · 2010-03-03 20:42

I got out the ladder last night and pulled the cover off the box containing the electronics and did some checking with a scope. (It's a real pain doing this outside in 35 degree weather at the top of an eight foot ladder!)

The power rails looked fine with almost no noise (<.5mV RMS) and no ripple (it's battery powered). Disabling the XBEE made no difference, nor did disconnecting the battery for a few minutes. The 5 MHz crystal is soldered, and the joints look good, so I don't think that's the problem.

I reflashed the EEPROM and everything worked again after that. Something must have corrupted part of the EEPROM, most likely location 0, which holds the clock rate. The EEPROM is socketed, so if this happens again I'll remove it and plug it into a breadboard and dump the contents and compare them to what they should be. I still don't see anything in the code that could have written over the EEPROM. Maybe I'll put a jumper block on the EEPROM's WP line and only enable it when programming it.

I also plan to wrap the serial data stream with a CRC so I can more easily detect corrupted data at the PC end.

Propeller Failure?

Comments