SX-28 (step) debug problem

phasesync · 2009-07-31 14:38

Hi,

I can't seem to stop the debugger and step through a program (see attachement). I tried different (small) programs f.e. the "Debug_Demo.SRC".

It is possible to program the SX-28 chip without errors in run mode (blue led lit). I have tried the USB SX-Key Rev.A and B and also

tried two SX-28 chips. I'm testing on a breadboard.

Does somebody have or had (and hopefully solved) this problem?

I hope someone could give me some advice.

Thanks,

Joey

Post Edited (phasesync) : 8/7/2009 9:50:19 AM GMT

PJMonty · 2009-07-31 19:00

Joey,

Is there a clock source on your breadboard, or is the SX-Key the only clock?

Thanks,
PeterM

phasesync · 2009-07-31 23:51

Hi PeterM,

There is no external clock attached, the clock is coming from the SX-Key.

It's a basic breadboard setup. The SX-28 chip (power, reset button), the SX-Key (power + OSC1, OSC2) and one led with a resistor.

In Run mode a "flashing led" test program works. It is even possible to program the debug firmware (ctrl-d) and the debugger shows up... saying it is Running, but important buttons to break/stop/step are all disabled. The led does not flash at this point.

It is driving me crazy (for some weeks now) and I tried a lot of things and even got me an extra SX-Key and SX-28 chip.

I have tried the SX software on WinXP, Vista and even Windows 7. Different computers and different USB ports but no debugging.

Thanks,
Joey

PJMonty · 2009-08-01 19:51

Joey,

If you have tried different computers, different operating systems, and different SX-Keys, then the most likely culprit is your circuit. Can you post a schematic of your circuit? I know you say it's basic (I'm sure it is), but there may be some subtle error. Also, a photo of your circuit with SX-Key attached might provide some clues.

Thanks,
PeterM

Zoot · 2009-08-01 20:00

Aside from possible circuit errors, the only times I have ever had this problem (and it does happen with some regularity) is because of dirty connections between the Key and programming header and/or overly long wires between the programming header and the chip. Basically dirty/noisy connections between the Key and the SX will cause this consistently. Short wires and cleaning pin headers usually solves it.

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

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

phasesync · 2009-08-01 21:28

Hi,

Thanks for all the help and information. I took some pictures of the breadboard. Rearranging (shorten) the cables and making it cleaner sounds logical. I also tried lowering the clock frequency.

Thanks again,
Joey

Zoot · 2009-08-01 23:32

Presuming you pull the oscillator/resonator when you want to debug. During debugging, it is required that the Key generates the clock signal *without* any other clock source in the circuit.

Try moving the programming header right next to the SX (just "north" of the chip so you have 4 open breadboard rows) and use very short wires between the prog. header and osc1/osc2 (and use the breadboard holes right next the pins -- breadboards are notorious for introducing stray capacitance into high frequency signal paths).

Lastly, if using the USB Key (as you appear to be doing) you do not need the Vdd connection to the Key, only osc1, osc2 and Vss. Possible that the Vdd line is introducing extra noise, though less likely.

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

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

RS_Jim · 2009-08-02 04:59

Do You have a Break in your software? If so it will grey out the debug controls and only respond to the software break.
Remove the break and reassemble your software. You can put breaks in with a click on the line of code you want the program to stop.
RS_JIM

phasesync · 2009-08-02 17:34

Removing the break in the software didn't work and different breadboard cleanups (shorther wires, component relocation) was no success. I'm very curious if someone managed to get this
SX-Key (step) debugging to work on a breadboard ( please give me a screenshot how to do the breadboard correctly

)?

The SX-Key is probably very finicky and the problem is probably a noise related one because for a PCB version (same led test setup) the debug buttons are enabled.

It is possible now to set a breakpoint and it looks like it breaks but pressing button "Step" puts the microcontroller from "Idle" into a "Sleeping" state. Shouldn't it advance
to the next line?

Thanks,
Joey

Post Edited (phasesync) : 8/2/2009 5:39:55 PM GMT

PJMonty · 2009-08-03 18:21

Joey,

On your breadboard, as others have mentioned, you must remove the TTL clock chip from the circuit before debugging. You can't just disable it via the enable line. Either pull the entire chip, or pull the "clock out" line from it to the SX before trying to debug. The SX-Key will not function properly if the TTL clock line is attached.

Regarding your PCB version, when it goes to "sleep" , what happens when you hit "Reset" on the debug control panel? I have found the USB SX-Keys are somewhat fussy, and sometimes mine will go to "sleep" when I enter debug or try and single step, but hitting "Reset" will make this problem go away. Also, as a test, set the "FREQ" line in your source code to 20 MHz, hit CTRL-D to re-program the chip for debug mode, and see if the problem goes away.

BTW, what is the clock source on the PCB? Resonator or TTL? If TTL, is it disconnected?

Regarding break in software, I find it to cause "sleep" problems, so I never use it. When you enter debug mode, the chip is idling and doing nothing. You can then set a breakpoint in the debug IDE or single step without having to ever use the software "break" function.

Thanks,
PeterM

phasesync · 2009-08-06 15:37

PeterM,

Thanks again for the tips. Sadly I still do not have the debugging working correctly.

>> On your breadboard, as others have mentioned, you must remove the TTL clock chip from the circuit before debugging. You can't just disable it via the enable
>> line. Either pull the entire chip, or pull the "clock out" line from it to the SX before trying to debug. The SX-Key will not function properly if the TTL clock line is
>> attached.

The external resonator component on the breadboard (visible on picture) was not connected to the SX-28. I also removed it completely from the breadboard because
I thought it could be the interfering component. On the PCB (see picture) there is no external resonator componenten plugged in. For both the breadboard and PCB the clock
is originating from the SX-Key. When I disconnect the SX-Key in "Run" mode the lights stop flashing, reconnecting it resumes flashing.

>> Regarding your PCB version, when it goes to "sleep" , what happens when you hit "Reset" on the debug control panel?

- CTRL-D -> state Idle -> click button Step -> state Sleeping -> click button Reset -> state Idle -> (endless loop)
- CTRL-D -> state Idle -> set breakpoint -> click button Step -> state Sleeping -> (endless loop)
- CTRL-D -> state Idle -> click button Reset (many times but slowly) -> always gives state Idle and looking at the instruction pointer it shows randomly 7FF (start vector), 000, 0FA?, 0F0?, 0FD? -> (endless loop)
- CTRL-D -> state Idle -> no breakpoints set -> click button Run (at this moment the buttons step, walk, run are disabled and poll and stop are enabled -> click button Stop -> state Sleeping -> (endless loop)

In all of these tests I have never seen a single led flash (compared to Run mode where it all seems to work correctly).

>> I have found the USB SX-Keys are somewhat fussy, and sometimes mine will go to "sleep" when I enter debug or try and single step, but hitting "Reset" will make this problem go away.

I wish I could say this problem is sometimes :-(

>> Also as a test, set the "FREQ" line in your source code to 20 MHz, hit CTRL-D to re->program the chip for debug mode, and see if the problem goes away.

Tried 20Mhz and some other frequencies but it always goes to the state Sleeping.

>> BTW, what is the clock source on the PCB? Resonator or TTL? If TTL, is it disconnected?

I don't have an external resonator attached.

>> Regarding break in software, I find it to cause "sleep" problems, so I never use it. When you enter debug mode, the chip is idling and doing nothing. You can then set a breakpoint in the debug IDE or single step without having to ever
>> use the software "break" function.

I'm just stupified and don't get it. How difficult can it be... I've used debug, gdb and VS debuggers but never had so much fuzzyness to deal with.

Final thing I will try is installing a clean WinXP and do everything from scratch.

Thanks,
Joey

Post Edited (phasesync) : 8/6/2009 3:45:35 PM GMT

RS_Jim · 2009-08-06 17:52

Joey,

I had a program that kept going to sleep when I tried to debug it on an actual board.· This board had worked with other programs so I ran the SXSIM to see if I could find the problem.· My problem was in a jmp instruction that was causing the program to jmp into the ISR.· Bean told me about using jmp @lable to correct the problem.· My debug no longer goes to sleep.·

RS_JIM

SX-28 (step) debug problem

Comments