I am having a weird problem with the sx key:

i have the following very small code runnig perfectly in SXSIM. The code assembles without errors and the sx28. When i try to debug the code things start going crazy. First, the interrupts for some reason don't get generated every rollover of the RTCC register (it happens rather randomly every 2-4 rollovers). The RTCC registers updates correctly with every instruction but generates an interrupt very randomly. The second funny thing is that the debug window shows that the contents of the rb, ra, rc or perhaps any other register can get modified during the jmp: loop part even though no command was issued to do anything to these ports. Third, a few times the debug window decided to jump to unused parts of the program memory and started going through that part of the program memory executing random instructions even though there was nothing in them and that happened when suddently the bank changed without my having any command instructing the sx to do that.

Is this the complete program ? I don't see a RESET or DEVICE line.
Bean.

i just put the meat of the code... this problems happens with any code including code that ships in the examples folder.
here is the rest of the code
                               DEVICE                SX28L,OSCHS2,TURBO,STACKX,OPTIONX        
               IRC_CAL                IRC_SLOW
               RESET                Initialize
               FREQ        50_000_000
and i just realized that if let the debugger run long enough eventually the sx will eventually start trying to execute commands in teh unused portion of the memory which i think is probably full of garbage and the execution of those commands is leading to the changes in the port values.

Try running it slower e.g. 1MHz and see if it gets better. If so, the problem is noise on the osc lines.

Are the IO pins floating? Not connected to anything? Try enableing the pull up resistor for each port all pins and see if that makes a difference. If so, the problem is stray EMF toggling the pins or latchup.

Also check the power supply.

1.  To debug an interupt, a break instruction needs to be inserted in the interupt.  Full details in the SX key manual
2.  The I/O registers will change unless you use pullups or pull downs on the pins specified as inputs.  To stop this, you can enable the internal pullups, or add external pullup or pull down resistors, or change disused pins to outputs
3.  Jumping to unused parts of program memory is, in my experience, caused by emf/emi issues.  In one case, the problem was traced back to a pump that drew only 15 watts.  In another case, I had my development board sitting on top of the PC case, as I had loaned out my 232 extension cable.  Is anti good.

0- I tried lowering the speed but that did not solve the problem.

1- I also put a break line in the interrupt routine and the behavior is still the same. However, i noticed that it is not random as i thought it was before. Interestingly enough the interrupts trigger every third rollover of the RTCC. For example: after the first ISR the RTCC is reset to RTCC-50 but the debugger does not show an interrupt being issued on the next rolloff nor on the one after that but indeed on the third one. This happens EVERY time with any program that enables the RTCC.



2- I can avoid the change on the ports by pulling them up so that is indeed solved.

3- I doubt the the problem is due to EMF or RFI in the case of the RTCC as the problem persists in the same fashion in various locations. I tried it at my work computer, my house computer, my laptop, and with different cable lengths and at various distances from the computer. Anyway the regularity of the error kind of makes think it is not a noise issue.

This seems to be a problem in the debugger.
When I "WALK" this:
;-------------------------
DEVICE SX28L,OSCHS2,TURBO,STACKX,OPTIONX
IRC_CAL IRC_SLOW
RESET Initialize
FREQ 350_000

ORG 0
 BREAK
 INC $0E
 MOV W,#-50  
 RETIW
   
Initialize
 CLR $0E
 MOV !OPTION,#%10011111 ;enable rtcc interrupt
Main
:loop  
 NOP
 JMP :loop
;-----------------------
$0E only gets updated the first time RTCC overflows ??
But if I add another NOP in the main loop it seems to work fine ???

Bean.

INTERESTING... I don't know what happened. I am gonig to use the oscilloscope or a logic analyzer to make sure that this is a debugger issue or an sx problem.

I tried adding a NOP in the main loop and thigns did not work as a matter of fact the interrupt got triggered once and never triggered again and $oe never incremented. I needed two NOPs to make it run smoothly exactly like Bean said!!

Then i added two NOP as shown below and the code works like a sharm! all the problems get fixed with just two NOP!! HOW COME?

ammar,
 Probably has something to do with RTCC overflowing during the JMP (which takes 3 cycles) and interaction with the instruction pipeline.
 I would hope that it is just a problem with the debugger.
Bean.

I checked the sx using this program. And it works fine, I measured 10KHz on RC.0 and 78Hz on RC.7
So it seems it is a debugger bug ;)
;----------------------
DEVICE SX28L,OSCHS2,TURBO,STACKX,OPTIONX
IRC_CAL IRC_SLOW
RESET Initialize
FREQ 1_000_000

ORG 0
 BREAK
 INC RC
 MOV W,#-50
 RETIW
   
Initialize
 MODE $0F
 MOV !RC,#0 ; All outputs
 CLR RC
 MOV !OPTION,#%10011111 ;enable rtcc interrupt
Main
:loop  
 JMP :loop
;---------------------------
Bean.

Hi all,
I noticed similar problems in the past when debugging SX code, i.e. that the debugger seems to not always "catch" an RTCC rollover interrupt while single-stepping through the code. Maybe, this really occurs when an interrupt is fired right in the middle of a jmp, call or skip instruction, i.e. in situations where the instruction pipeline needs to be cleared up. Inserting NOPs somewhere in the code cause a slight shift in timing so that interrupts are fired when the main code does not just perform a branch.

On the other hand, by setting a breakpoint inside the ISR, I could verify in RUN mode that the SX per-se does not miss any RTCC rollover interrupts (provided the total execution time of the ISR is below the interrupt period).

I don't think that this is a bug in the SX-Key IDE part of the debugger but that this is caused by some limitations of the SX in-system debugging feature, similar to the fact that you can't set a breakpoint on a NOP instruction, and that program execution stops only after the "breakpointed" instruction has been executed.

I think we will have to live with these "features" but I felt free to not implement similar "features" in SXSim :-) .

I just tried the code and it basically works fine on my system.  I was able to watch RC increment in the debugger just fine.  I hit the RUN button in the debugger, and it would stop on the break line.  This would happen every time I hit RUN.  I did notice that if I watched RC increment, it sometimes would jump ahead due to missed breaks in the interrupt code, but that's a known limitation.

Hi All;
As previously suggested by others, the fact that the debugger will NOT operate reliably in the WALK nor SINGLE-STEP mode is documented on page 73/74 of the SX-KEY/BLITYZ manual version 1.1
My experience is that generally the debugger will follow a single-step/walk into the interrupt only once after a RESET, but after that, not reliably or never. As Peter states, this is a documented limitation, and has somthing to do with the contents of the shadow registers/fifo at the moment the debugger breaks into the mode to display the register contents.