PIC + rs232 Woes

May 7, 2006 1:21 AM

My JDM PIC programmer and the serial routines I've got stuffed in the little chip were working just fine....

Until I put it down for a couple of weeks. Now the serial input from the PIC is garbled ASCII nonsense and the JDM refuses to re-program the chip. No settings were changed in IC-prog and the only thing I've installed is a usb mouse (There was one of the same brand installed before). I get -12 volts on the TX/RX pins of the rs-232 cable and an old serial mouse seems to work fine on the port(for an old serial mouse). The port settings are all the same (9600N8-1) and I've reebooted, fiddled, checked/reset the BIOS in vain. I did once have a problem similar to this, but don't remember how I fixed it (not quite the same, IIRC). I've tried winpic with the same results. I have a modem on COM3, but this hasn't been an issue before. Serial is being driven by a MAX232 with charge pump caps. I've been writing a C# program that talks to it, and it also worked previously. What gives?

posted by IronLizard to technology (5 comments total)

Not enough info to help much...

You have two problems? A malfunctioning PIC programmer from JDM Microdevices and a PIC that you programmed, right?

If correct, the easiest thing to do is find another computer to test with the JDM box first, since you'll need it to program your PIC and test it out anyway. You do NOT need your C compiler for that. If you can get it to work on another PC with a clean install, then you can keep worrying the problem on your normal PC. If you can't, then it's time to send it back to JDM for repair. (To test it, you can used the same object files (the .s19 or .hex) that you created for the PIC program you mention is no longer working. )

On the target program, once you get a programmer working, write the simplest comm test program possible... a long delay and a single character out... such as a "!" or some such. That will let you resolve baud rate and framing issues, if there are any. If you are using a PIC with an internal RC clock, or an otherwise inaccurate or unstable time base, you'll get framing errors and gobbledygook (engineering term) due to oscillator drift (thermal). Try lower baud rates with higher divisors to find a baud rate that works. Look at the waveform of the serial character on a scope, if you have one or can borrow one. Compare it to the expected pattern. If the pattern is good, then it's a framing problem and you need to tweak your divisors a little or get a more stable oscillator.

Is the PIC target your design? Which PIC, btw?

I'm not a big fan of PICs, generally. I usually program the damn things in assembly language, and there is too much crap to take care of due to their paging structure. Ick. RISC... ick!

I personally prefer the 8051 variants and the Freescale 9S08 chips. Lots of good peripherals and cheap development tools, plus programming models that are just better, IMO.
posted by FauxScot at 5:13 AM on May 7, 2006

Also: Local loopback failed in hyperterm

The PIC242 is just what I managed to get samples of some time ago, I'm using PB so there's not much complication here and the osc is a 10mhz crystal with 22pf caps. It could be an odd coincidence that both failed simultaneously, but I'm leaning toward the fried/incorrectly configured serial port. What the pic is doing at this point is just sending a M: prompt after a "OK, what?" mesage, nothing complex. After a single decimal input, it should spit out a D:, but I can't get it to acknowledge an input with even the garbage it sends upon startup (there is a delay for stabilization already in place, about 500ms), which leads me to believe it may not be getting an input at all. The PIC not communicating properly is what prompted me to reprogramm it. When this failed I tried a fresh 252 and it failed as well. It's odd, however that the mouse still works. Otherwise, I would be certain the port was beyond hope. Also: The JDM, it's not from JDM Microdevices. It's from HombrewNutsInTheBackYard Devices. See here. Yes, the unreliable DIY, super tricky, throw it together and pray pile of silicon. It's worked flawlessly (since my second attempt at building it), albeit slowly, for quite some time and hasn't been tampered with or abused. It also has a red perforated aluminum cage with a stained wood base surrounding it :) Looks worse than it sounds, trust me.
I'll try it on another PC when I can, but the only thing available is an old p266 that will require me to unplug the mouse to use it. It'll need to be dug out of a closet. My main concern, though is the useability of the serial port on this machine.
posted by IronLizard at 5:56 AM on May 7, 2006

Thanks for clearing that up. I'm not familiar with the JDM hardware, but I'll bet 1/4 of the problems I have had in 32+ years of engineering have been comms related!

Local loopback failing in hyperterm is 99% almost conclusive. Even though digging up the p2-66 is a pain, it's one good reason to keep them. I have an old thinkpad with win 98 and dos 7 on it for just that reason.

Also, I have had a lot of silly problems with hyperterm. I prefer something that makes serial IO a little easier. For instance, want to change the baud rate in hyperterm? You have to create a new connection.

For troubleshooting framing errors, handshaking, baud rate mismatch, etc. I am very fond of Procomm Plus. I checked and there are a bunch on ebay for less than 10 bux. I cannot count how many times I have had my rear saved by having a fast method of manipulating serial ports.

Also, as regards your first post, the fact that you installed something between the pre-failure and post-failure circumstance lends support to an OS change being responsible. Windows has a lot of crap going on, and nowhere near enough visibility.

I'd pare down the system to bare essentials (e.g., safe mode) and see if the serial IO suddenly begins to work. Also, you can boot to DOS and use the mode command to set the port parameters.

THe Mode command also has some switches for redirecting a serial port to be the console. I have forgotten the syntax, but it might be useful to validate your hardware before going off and debugging the OS. You have to get 100% confidence that you are working with good hardware FIRST, or you may work on the wrong thing.

Good luck.
posted by FauxScot at 10:11 AM on May 7, 2006

Thanks, I think I have an old copy of Telix floating around somewhere believe it or not. Procomm plus (the software, I take it?) might be in here somewhere too, not to mention several other clones. I kept an amazing collection of old DOS software on floppy's from the early nineties and rcently transferred it all to on CD (Hundreds of these little disks, I'm still amazed at the giant amount of bloat windows created for comparable software). This should be a blast from the past, but I need to get some sleep for now. BTW, there is no handshake, it's straight software. i.e.

onserialport1.recieve(args) { if (serialport1.readexisting="M:"){send.next();}}

in psuedo code but you get the idea. Not elegant, but it worked. I'll give this a shot and try to get a PCI serial port card if all else fails. Would be nice to know how this one died, if indeed that is the case.
posted by IronLizard at 10:28 AM on May 7, 2006

Just an update: Nothing seemed to make any difference on the port (including hooking up an old 28.8 modem), so I picked up a used PIC serial card for 5 bucks. Lo and behold the programmer would once again read a chip. The interesting part here is that the loopback test now works on the motherboard port (I checked in on a lark while testing the new card). Just what changed? Nothing. I'm going to continue using the card, just for added safety but the erratic port on my MB is a mystery to me. Oh, and the pic itself still puts out gibberish, but it's consistent gibberish now and should be simple to figure out. Thanks for your help, FS.
posted by IronLizard at 4:15 AM on May 9, 2006