SX28 not running; seems to be stuck in reset?

Joel Friend

I am implementing an SX28 into an RS-232 application. The breadboard version on the SX Tech Board works perfectly; the program is not the issue. However, the PCB version does not appear to run. I can write the program to the chip on the PCB without any trouble using the Key, but there is no signs of life past the programming. If I run the same program on another chip on the Tech Board, it works. Once soldered to the PCB, it doesn't.

Now here's the interesting part. If I try to debug the PCB chip, the program downloads but then the debugger will open with Running in the status, and none of the control buttons enabled (I cannot click 'Stop', 'Step', etc.). The Reset button (on the debugger) is enabled, but does nothing visible when clicked. This is exactly the same symptom as post #3 in THIS THREAD.

I have found I can duplicate this scenario by holding down the reset button on the Tech Board and then debugging (Ctrl+D). The debugger opens in exactly the same state - Running, no buttons enabled. So naturally it seems maybe my PCB chip is doing somewhat the same thing, although I have MCLR pulled high via a 10K.

I might insert that even a simple program does not work either. I wrote a fast turn-an-LED-on program to test the PCB, and it still does not work. I am using the internal 4MHz clock, so there is nothing external. In fact, once it is programmed to run, the Tech Board chip will work every time when removing / applying power. It is completely self-contained.

Bottom line - Tech Board version works perfectly, PCB version does nothing. I have MCLR pulled high through a 10K. Am I missing something?

Thanks in advance.

Zoot

Greyed out debug buttons are usually a sign of dirty programming header connections, or excessive noise in the programming cable/header.

Besides the debug issue, given that the chip/program work fine on a demo board, but not in your PCB, is it possible the PCB has errors, or some other (subtle?) difference that would lead to failure?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Bean

Joel,
You say you do have the 10K between MCLR and the supply, so that is Ok.

Do you have a bypass cap between Vdd and Vss on the PCB ?

Also, you say you are using the internal 4mhz clock with an RS-232 application. This is a recipe for disaster. The internal clock is only accurate to +/- 8% and can (will) cause problems.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

Joel Friend

I do have a bypass cap on the regulator, simulating the Tech Board, and I have a 1uf directly on the SX supply pins.

Regarding the use of the internal 4MHz oscillator, it works perfectly for my application. I understand the concern for prolonged uses, but my transmission / receive is so short and very far between that it causes no problems. Like I mentioned earlier, it works perfectly every time on the Tech Board.

The lack of debugging functionality really doesn't concern me, but the fact that something is not functioning on the PCB exactly like the Tech Board, does. I know my programming header is pathetic, but I figured (and I could be wrong) that since connection is made and programming is successful, it must be written correctly. Could it be possible that even though the SX-Key and Editor can find and connect to the chip, the program might not copy properly? I don't suppose there is any built-in "checksum" function that takes place to ensure the program is intact after writing.

Post Edited (Joel Friend) : 10/31/2009 3:34:34 AM GMT

Joel Friend

Problem solved. I installed a much cleaner programming header, and that seems to have cleared up the problem entirely. I believe we can conclude that just because the Key and the Editor can connect and download to a chip does not necessarily mean that the program was written correctly. Thanks, Zoot, for that insight.