Bug in SX-Key software
william chan
Posts: 1,326
There is a very irritating bug in the SX-key software.
This bug is long-standing since version 2.02 or earlier.
Please see the attached error message that pops up almost everytime an SX has been programmed with
IRC_CAL set at 4Mhz.
When this happens, I can't see that the closest freq has been selected, and i suspect it is not b'cos i have to download a few times
to get my SX 1200 bps UART to talk to my PC.
Peter, where are you....
This bug is long-standing since version 2.02 or earlier.
Please see the attached error message that pops up almost everytime an SX has been programmed with
IRC_CAL set at 4Mhz.
When this happens, I can't see that the closest freq has been selected, and i suspect it is not b'cos i have to download a few times
to get my SX 1200 bps UART to talk to my PC.
Peter, where are you....
255 x 128 - 7K
Comments
I have never seen (nor heard) of this bug before this message. Frankly, I've never even seen this message come up from any Windows application. By any chance, are you running XP?
Thanks, PeterM
The form's visible property is set to true while the modal property is being set to true.
This is not allowed. The visible property should be false before setting modal properties.
Either this bug is for real or you have a mix-match of Borland VCL libraries on your machine.
If it is a real bug there is nothing you can do about it.
If it is a VCL issue, try removing the SX software completely and reinstalling.
You say it is a long standing issue. Have you been installing SX versions over each other?
Jack
Thanks, PeterM
The problem also occurs in WinXP without any Service Packs installed.
Yes, I installed SX-Key v3.0 without first un-installing v2.02. Will that cause problems.
Yesterday, I tried un-installing both softwares (by using the ControlPanel/AddRemove Programs), then re-installing SX-Key 3.0 only.
Now, after programming the SX, the progress bar hangs forever and does not go away. See attachment.
This is the second very irritating bug, b'cos it happens 80% of the time.
When it happens, I have to force out the SX-Key 3.0 program. : (
Peter, are you doing development on Windows XP?
No, I use Win2K. XP seems to have enough changes/weirdness that I prefer to stick to an OS that has always been rock solid. As for the hanging progress bar, this is a problem that is being addressed in the next release of the software. It's an extremely difficult problem to debug because any attempt to break into a debugger causes the SXKey to timeout and stop communicating with the IDE.
Thanks, PeterM
When will the next version be released?
Is there a current work-around for the Hanging Progress Bar problem?
Why nobody has mentioned about this problem in the forums when I always get this problem on 5 of my PCs?
When the progress bar hangs, is there a way to un-hang it without forcing the program to quit?
When the progress bar hangs and the closest Freq select dialog did not pop up, did the IDE correctly program in the closest freq?
Thanks.
Even when it hangs, the chip is still programmed and runs perfectly.
I find that when I leave the computer - not touching the mouse or the keyboard - the progressbar usually doesn't hang, so I guess it's an timing issue that causes the bug.
That's just my 5 cents worth of experience.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why spend five minutes watering the plants, when you can spend a lifetime building a robot that will do the job.
There is not a firm date for the next release, but testing is ongoing, so it's not like it's a year away or anything.
The only work around seems to be the on ementioned by Lemon in the prvious post. This problem has definitely been mentioned before in the forums. I guess you just need to hang out here more often!
As for wondering if the chip was programmed correctly if the bar hangs and the frequency dialog doesn't show up, I can't say with certainty one way or the other. Obviously, the safest thing to do is to re-program until the IDE doesn't hang on you.
Sorry about the hand waving here, but I'm working on getting the next version out and addressing this issue.
Thanks, PeterM
Once it loses focus, it can't seem to find it again, even if you click on the progress bar window.· In all cases it does seem to program the chip correctly, for either de-bugging, program or run.· Just that the progress bar window gets stuck and sits on top.· Never gets any update messages.· If you are doing a debug run, just wait, the debugger UI will pop up when the programming is done, even though the progress bar doesn't move.
You can move the progress bar window out of the way and carry on, that's what I do.· I've never had to re-start the program because of it.
Mike C.
Peter (pjv)
On most of my machines when the progress bar hangs,
40% of the time you can't click on either the progress bar window or the main window.
When this happens there is now other way except to force it out.
About 60% of the time, you can still re-program the SX one more time.
Maybe you guys usually use crystals and don't use the IRC_CAL 4Mhz like I do, that's why the problem seems
less serious.
Peter, I appreciate that you are actively looking into this problem.
Maybe you should use XP for your development since it is most common now...
William
Sorry, one more question...
1. When SX-Key programs the SX Chip, how is the closest selected freq programmed in. Is it
a. Programmed in at the begining before the rest of the code or
b. Programmed in somewhere in between the main program code or
c. Programmed in last after the the main code as been inserted
I am facing a lot of difficulties getting the right freq programmed in when either the two bugs shows up, and they show up 90% of the
time.
This is frustrating our development efforts...
I only use assembly code.
If you have a new beta IDE, I would like to test it.
William
What is the application that you need to use "IRC_CAL IRC_4MHZ" instead of "IRC_SLOW" or "IRC_FAST"?
The difference in frequency is not much considering the tolerance.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
Thank you for your time and concern.
My application is a simple software UART at 1200 bps communicating with a PC.
At 4Mhz and 210 cycles per interrupt, I have to sample the bits every 16 interrupts.
Even at a slow 1200bps, I found that setting IRC_CAL to either IRC_FAST or IRC_SLOW can break the communications, even though
the sampling has been timed to sample at the middle of each bit.
This is b'cos at 4Mhz, the speed is just enough for 1200bps, there is no room for the IRC tolerances we get on most sx chips.
If we try 2400 bps, it's even worse, only 8 interrupts per bit sample, reliability and manufacturing reproducibility will be a problem.
Of course the SX can be made to run faster and more accurately with resonators, but in our application, low current consumption is important.
The funny thing is, a PIC with hardware UART can easily do 9600bps when running at 1Mhz only.
But we still like the SX's versatility. I hope this problem with the IDE can be solved soon.
It varies alot depending on temperature and supply voltage.
You would be better off using a slower resonator.
Would a 1MHz resonator have a low enough current draw ?
Try the different OSC setting in the DEVICE line, that will affect the current.
With the precise clock you shouldn't need more than 3 samples per bit.
I would think that 2400 baud would be possible @ 1MHz with 3 samples per bit.
I guess the other question is can you do whatever else needs done at 1MHz ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
Like you said, with an accurate resonator 3 interrupts per bit would work,
so by my calculations, 16 interrupts per bit would be plenty of lee-way for the internal osc tolerances.
The voltage is regulated at 5V using 78L05.
There would be no reason why it cannot work well.
We can use resonators, but we have already made a lot of PCBs without the resonator pads. : (
I strongly believe that this method still can work and the only thing preventing it is the wrong freq selection by the IDE.
From my tests, once the SX is able to communicate with the PC, it will always be able to do so, until it has been re-programmed by the IDE. And then it wouldn't work even with the same code, same temperature, same sx chip and same regulated voltage.
We even tested the boundaries of workability by adjusting the bit sampling to be earlier or later to get the middle point.
But due to the wrong freq selection, establishing the boundaries and middle point is next to impossible.
Our tests covers more than 80 separate SX Chips.
I think this is a good testing ground to separate once and for all the facts and myths of the SX Internal Oscillator.
If you are receiving data, you could possibly sync to the incoming pulses (maybe that's what your already doing). I would think that would require some kind of special prefix be sent that had a known pattern of highs and lows, so you know how many interrupt times each bit is taking. At 8% error you will be off by half a bit-time after receiving 6 bits. 6x.08=.48
If you are only sending data, that is a problem. There is no way to know how far off the oscillator is.
You right, I don't think alot of testing has been done concerning the internal oscillator on the SX. I think that is because it it not really used all that much. I can tell you that with SX/B code I cannot communicate with a BS2 (resonator controlled) using the internal 4MHz (even with IRC_CAL IRC_4MHZ) at 9600 baud. I haven't tried lower baud rates.
MUST the receiving code be done in an interrupt ?
Is is possible to have the PC send a specific header byte before any actual data (do you have a packet structure ?).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.
www.sxvm.com
"A problem well defined, is a problem·half solved."
·
My SX is only receving, not sending any serial data.
The SX actually syncs with the startBit and from there tries to sample in the middle of the rest of the bits.
This is common in all SX UART codes.
I am not surprised that you are having problems with 9600 baud at 4Mhz.
My tests show that even with 2400 baud, I have to get lucky to get it working with any PC, even after fine tuning the middle bit position.
So I decided to play it safe and go with 1200 baud.
From our experience, the closest selected freq, in worst case would be around 3.92 Mhz to 4.08 Mhz. ( as seen in the SXKey freq dialog )
That is only 2% tolerance. So for 8 bits, 8 x 2% = 16%
But 3 / 16 interrupts per sample = 18.7%. So it should not run by more than 3 interrupt times per byte, which is beautiful.
B'cos it has to be out be more than 7 interrupt times to be out by half a bit, which will then definitely fail.
So at 1200bps it should have no problem at all.
That is why I am very certain that the IDE usually did not select the closest freq, b'cos at times when it did, the SX just continues
to communicate well day after day.
I am sure my problem is nothing to do with using header bytes,
bcos the single header byte itself couldn't be received correctly all the time once the freq is out.
You seem to be an expert with the SX. Are you the designer of StampII SX?
Please ask Peter to hurry. hop
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!