Bizarre SX-Key Problem

Velocit

I've encountered a strange problem with my SX-Key Rev. F. I can't find any similar cases in the forums and Parallax tech support suggested posting here. Here's the background information:

I have a prototype on the SX28 Proto Board that I've been working on for a few months. The code for this project previously worked flawlessly both in simulation and in-circuit. I was experimenting with a few different output drivers and all of a sudden the pins wouldn't respond to what the code dictated they should do. I figured I must have damaged the chip somehow, so I removed all output circuitry, desoldered the SX28 and re-soldered it. The problem was still present...

I tried another SX28AC/SS... eventually I socketed the connection on the board thinking I was damaging the chip with heat (I keep my iron at about 500*F). Now, even after socketing the connection and swapping about three different SX28AC/DP chips, the problem still hasn't gone away.

Ok... so maybe it's something I missed on the Proto Board itself: either an inadvertent short or broken trace, etc.. I programmed/debugged the same code into my SX Tech Lite board as well as several bare SX28 Proto Boards. No matter what, the pins won't react like they should -- like they used to. For instance, if I tell the RC ports to output a variable containing %0001_0100, it will just output %0000_0000, or sometimes %1111_1111 and still other times just a random (as far as I can tell) combination of pins.

Again, I haven't changed the code at all and it still works fine in simulation.

Since, all of the hardware checks out, I think I narrowed down the problem to the SX-Key itself. The odd part is, is that I can successfully "program" SX chips and I can access the key through HyperTerminal just fine. Additionally, while programming, I connect the SX-Key first, then apply power, then connect the serial cable. Has anyone experienced this type of problem before? Am I correct to think the SX-Key is at fault? This really puts a damper on the project as I'm trying to get the prototype into testing for an impending release.

Thanks!

John Kauffman

When flipping back and forth between testing and debugging, I sometimes forget to remove/replace the resonator.

Velocit

I'm only using the internal 4MHz clock, though.

Post Edited (Velocit

Shawn Lowe

Try posting your code. Maybe something got changed that shouldn't have

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe


Maybe I should have waited to do that......

Velocit

I'm actually restricted from posting the whole program, but I've included a snipet below. Like I said, nothing has been changed in the code whatsoever from when it was last working to now. Looking below, you would expect that bit3C = 1, bit2C = 0, and bit1C = 0, but instead all three usually equal 0. In case you were wondering, these particular pins are connected to a BCD encoder/buffer for a seven segment display.

bit1C    PIN    RB.0    OUTPUT
bit2C    PIN    RB.1    OUTPUT
bit3C    PIN    RB.2    OUTPUT    

currPos     VAR     byte

...

dispPos        SUB    0

...

currPos = 4
GOSUB dispPos


dispPos:

bit1C = currPos.0
bit2C = currPos.1
bit3C = currPos.2

RETURN

PJMonty

Velocit

Velocit

Hi Peter,

Thanks for your response. From what I can determine, the SX itself and the code check out. The only thing I cannot rule out for sure is the SX-Key. I do agree that it only takes a small mistake to render a whole chunk of code completely useless, though. The code snipet I posted above is taken directly from the original codebase, with only the middle sections removed to protect the content and highlight the main problem areas. As you can see, the pins were correctly declared as outputs.

I do have older code versions, but they do not work either (they did in the past, however). So... I took your advice and wrote a very simple program to cycle through numbers one through nine on a button press (up or down). The result, sent via the bitXC pins, is then displayed on a seven segment LED display though the BCD encoder. The file is attached to this post... Please take note that it works flawlessly in simulation.

Also, I did a little "manual datalogging" and copied the variable and pin states for various button action sequences. The down button is a little finicky because it's a cheap tactile switch and I haven't implemented any button debouncing in either the hardware or this version of the software. I attribute the jump from position 3 to 1 at the end of the log to this button. Also, I have no clue why 8 and 9 are displayed correctly. The BCD encoders have internal latches, so the correct signals must be output at some point, if only for the minimum amount of time to set the latches. Here's what I recorded:

Action  currPos 1C   2C    3C   4C   Disp
X         1     1    0     0    0    1
U         2     0    0     0    0    0
U         3     1    0     0    0    1
U         4     0    0     0    0    0
U         5     1    0     0    0    1
U         6     0    0     0    0    0
U         7     1    0     0    0    1
U         8     0    0     0    0    8
U         9     1    0     0    0    9
U         9     1    0     0    0    9
D         8     0    0     0    0    8
D         7     1    0     0    0    1
D         6     0    0     0    0    0
D         5     1    0     0    0    1
D         4     0    0     0    0    0
D         3     1    0     0    0    1
D         1     1    0     0    0    1

These results are repeatable and they occur on the RB bank as well.

Bean

I sent you some SX20, if you program them with the DEVICE set to SX28 you will get weird results.
Is that what is happening ?

Otherwise, I'd say the SX-Key is bad (if everything else checks out).

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?

www.iElectronicDesigns.com

·

Velocit

Nope, I haven't even begun to program the SX20's yet. I've just been fussing with the SX28 Proto Boards and my SX28 Tech Lite Board. Thank you for your input, that's exactly what I needed to hear. I'll give Parallax a call back and see what we can work out. Thanks everyone!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Paul