SX SX/B Freq and crystal changes
Rsadeika
Posts: 3,837
Has anybody run into problems, like a program not running correctly, while making DEVICE crystal/oscillator changes. This became very evident when I was trying to run Jon's SIRC program in stand-alone.
The problem that I am having is, sometimes, when you 'Run' a program it works fine, then you do 'Program', and then run it in stand-alone, the program does not work correctly, or does not run as expected.
Just today I discovered that if I 'Run' a program, then make a DEVICE crytal/oscillator change, and 'Run" it again to make sure the program works. Then·'Program', and run it in stand-alone, The program does not work as expected.
I have tried different combinations of this, but the one that really breaks down consistantly is, you have·DEVICE OSC4MHZ,·'Run' it, program works. Change to DEVICE OSCOSCXT2, or any of the other selections, 'Run' it, the program works. 'Program' it, run it in stand-alone, program does not work, do a 'Run' again, and now the program does not work in this situation either. From this point you can do anything that you want, and the program will not work correctly. The only remedy, that I found was to unplug the power, plug it back in again, do a·'Run' again, and the program works again.
I have tried ·other short programs, in asm and SX/B to make sure that I can get something to run in stand-alone, these seem to work, even with·a DEVICE crystal/oscillator changes. I did notice that most of the problems did occur when the program made use of·the PULSIN command. I do not know if this has anything to do with the problem. I do not have the programming knowledge to see if some other commands would have an effect like I just described.
Since I do not have a SIRCS in assembly, I could not check it in asm to see if the same problem occurs. So, my guess is that their may be a problem in the 'Run', 'Program' part of the IDE compiler program, just a guess. The equipment that I tried this with is the SX Tech board and the SX52 proto board, used the proper crytal/oscillator when applicablle,·similarities do exist between the two boards, although the SX52 proto board was more susceptable to the problem. I am not attaching any code, because the problem is not the code per se, the code works in a 'Run'. Any ideas or suggestions.
Ray
Thanks in advance
The problem that I am having is, sometimes, when you 'Run' a program it works fine, then you do 'Program', and then run it in stand-alone, the program does not work correctly, or does not run as expected.
Just today I discovered that if I 'Run' a program, then make a DEVICE crytal/oscillator change, and 'Run" it again to make sure the program works. Then·'Program', and run it in stand-alone, The program does not work as expected.
I have tried different combinations of this, but the one that really breaks down consistantly is, you have·DEVICE OSC4MHZ,·'Run' it, program works. Change to DEVICE OSCOSCXT2, or any of the other selections, 'Run' it, the program works. 'Program' it, run it in stand-alone, program does not work, do a 'Run' again, and now the program does not work in this situation either. From this point you can do anything that you want, and the program will not work correctly. The only remedy, that I found was to unplug the power, plug it back in again, do a·'Run' again, and the program works again.
I have tried ·other short programs, in asm and SX/B to make sure that I can get something to run in stand-alone, these seem to work, even with·a DEVICE crystal/oscillator changes. I did notice that most of the problems did occur when the program made use of·the PULSIN command. I do not know if this has anything to do with the problem. I do not have the programming knowledge to see if some other commands would have an effect like I just described.
Since I do not have a SIRCS in assembly, I could not check it in asm to see if the same problem occurs. So, my guess is that their may be a problem in the 'Run', 'Program' part of the IDE compiler program, just a guess. The equipment that I tried this with is the SX Tech board and the SX52 proto board, used the proper crytal/oscillator when applicablle,·similarities do exist between the two boards, although the SX52 proto board was more susceptable to the problem. I am not attaching any code, because the problem is not the code per se, the code works in a 'Run'. Any ideas or suggestions.
Ray
Thanks in advance
Comments
I've worked on numerous project and I haven't seen this.
In your explaination, you need to say if you are running it with the SX-Key or with the SX-Key removed and with what clock source. "Proper resonator" doesn't tell me anything. Is it the resonator that Parallax sells ? What frequency ?
If the SX-Key is installed it will clock the device.
Here is what I do:
Click RUN wait the device to finish programming, then turn off the power, then remove the SX-Key, then install the resonator then re-apply power. If I'm not debugging then I just leave the resonator in.
Please post a program (even if it is very simple) and tell us exactly the steps that cause the program including what is connected (SX-Key, resonator, xtal, ect.)
I will attempt to re-create the problem.
Possibly you have incorrect DEVICE settings.
The SX-Key will work with ANY device settings (I think), but a resonator or crystal needs to have the correct setting.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
Forget about the past, plan for the future, and live for today.
·
To quote from another thread:
PLEASE, HOW MANY TIMES DO YOU NEED TO HEAR THIS.....POST YOUR NON-WORKING CODE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
How can we help if we can't reproduce your scenario??
Cheers,
Peter (pjv)
Again I guess I was not explicit enough, everything is Parallax. 'RUN', is with the SX-key installed (no external crytal plugged in). Stand-alone is without the SX-Key, with appropriate crystal/oscillator plugged in, I even tried with the internal RC approach. I am now almost anal with my procedural approach, turn power off, remove SX-Key, install appropriate crystall/oscillator. Turn power off, remove crytal/oscillator, insert SX-Key, plug in or turn power on. Most of the time I stay with the 4MHz (Parallax) crytal, that way I do not have to make to many changes in my routine·when I try it in internal RC.
Peter(pjv),
The reason I did not provide the source is because when I do a normal 'RUN', the program works. I can make changes, and then do another 'RUN', and the program keeps working as expected. The problem starts when I do a 'PROGRAM', turn power off, remove SX-Key, insert crytal/oscillator, if appropriate (I have tried the internal RC method also),·plug in or turn power on. I even did things by using a check list to make sure I was not missing anything. The problems really started to appear when I did start to make changes to the program, and then 'PROGRAM'. The code below you can 'RUN' all day without any problems. The program below is my original SIRCS program, under one circumstance I was able to have this run in stand-alone. I cannot remember what the sequence of events were. Again, the problem is when I start to change the DEVICE setting, do a 'RUN' to make sure the program works, and then "PROGRAM', with the steps I just previously described. Again I have tried this with my SX Tech board, and SX52 proto board.
Ray
*******CODE
' =========================================================================
'
'·· File...... MyIR52.sxb
'·· Purpose... SX/B Programming Template
'·· Author....·
'·· E-mail....·
'·· Started...
'·· Updated...
'
' =========================================================================
'
' Program Description
'
'
' Device Settings
'
DEVICE········· SX52, OSCHS3
'IRC_CAL IRC_4MHZ
FREQ··········· 4_000_000
'
'
' IO Pins
'
·led1 var rd.0
·irpin var re.0
'
' Constants
'
'
' Variables
'
·irpulse var byte
·temp1 var byte
·idx var byte
remotecode var byte
' =========================================================================
· PROGRAM Start
' =========================================================================
'
' Subroutine Declarations
'
·ledon sub
·getcode sub
·processcode sub 1
·gofore sub· 'ChUp button
·goback sub· 'ChDn button
·goleft sub··· 'Vol- button
·goright sub··· 'Vol+ button
'
' Program Code
'
Start:
do
·'ledon·· 'Turn on LED
·getcode
·processcode remotecode
·'goto stop
loop
getcode:
'pause 1000· 'Turn on LED, to make sure I got here
·'ledon
remotecode = 0
irpulse = 0
do· ''*******Get start pulse
·pulsin irpin, 0, irpulse
'loop while irpulse < 240 'Does not work with 220
' loop while irpulse < 216
· loop until irpulse > 216
''*****Get bits
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.0 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
· remotecode.1 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.2 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.3 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.4 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.5 = 1
endif
pulsin irpin, 0, irpulse
'if irpulse > 120 then
if irpulse > 108 then
·remotecode.6 = 1
endif
return remotecode
processcode:
'pause 1000
'ledon
if remotecode = 16 then· ' If ChUp button
gofore· 'Turn on the LED
endif
if remotecode = 17 then·· 'If ChDn button
goback
endif
if remotecode = 18 then
goright
endif
if remotecode = 19 then
goleft
endif
return
ledon:
·tris_d=0
·led1 = 0
·pause 1000
·led1 = 1
return
gofore:
·'pause 1000· 'Turn on LED to make sure I got here
ledon
return
goback:
· 'pause 1000
· ledon
return
goleft:
·' pause 1000
· ledon
return
goright:
· 'pause 1000
· ledon
return
stop:
sleep
Also turn on the brown-out detector BOR42 (for 5 volts) or BOR26 (for 3.3 volts). The SX does not startup sometimes if the power supply rise time is not fast enough (or maybe even if it's too fast). The brown-out reset takes care of that problem.
So I'm suggesting something like:
DEVICE SX52, OSCXT2, BOR42
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
Forget about the past, plan for the future, and live for today.
·
What happened to the clearn IR decoding routines we came up with?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I had a similar frustrating experience when I first started using SERIN/SEROUT. The help pages say at 4MHZ I could get 56K baud. It would work the first time I programmed it but wouldn't after a power off/on cycle. Finially I found a thread where Bean said that these values were only for external crystal/resonators and not SX-Key. I guess I was lucky to get it to work at all on the SX-Key.
So basically it sounds like the DEVICE settings are the culprit as Bean pointed out.
I hope someone would update the SERIN and other FREQ related commands in the help file (hint hint) to mention what DEVICE setting work with the SX-Key.
EDIT: Hopefully the new SX/B book will cover most of this. From other threads·we're not the only ones confused about·DEVICE settings.
Paul
Post Edited (Paul) : 12/22/2005 4:06:31 PM GMT
It is with your SIRC program that I started to notice the problem. Your version, when I 'Run', it works as described, it is when I do 'Program', and try to run the the program in a stand-alone setup that it faulters. Again, stand-alone means no SX-Key installed, proper crystal/oscillator pluged in, of course I turn power on/off at appropriate times.
Since your program is cleaner, but more complex, code wise, I decided to get the code down to a level where I can sort of understand. That is why I am using my code, just to get it in the simplest form possible. No offense Jon.
Bean,
I tried some of your suggestions, that did not help at all, the the problem still occurs. I have attached two SX/B programs, one for an SX52 proto board, and one for the SX28 Tech board. Basically, they are the same. I use the puslin command in its simplest form to try to see if I can narrow the problem down. The problem still occurs for both setups. So, again, just to keep it straight, I do a 'Run', and the program works, on both boards. I do a 'Program', turn off the power, pull out the SX-Key, plug in appropriate crystal/oscillator, turn power on again, the program does not work as expected.
One would think that the problem might be with the 'Program' aspect, but I have tried other programs that do not contain the pulsin command, and the program works in both situations, 'Run' and stand-alone. The other point that I verified today was that when you do the 'Run' and 'Program' sequence, things really get sticky. After doing that sequence, I went back and tried to do a 'Run' again, and the the program no longer works, when it just worked moments ago. I double checked my LED circuit, and my IR detector circuit for loose wires, everything was in tack.
So, I am still leaning towards a possible combo of problems, when using the pulsin command and 'Program' combination, some weird things·are ocurring during the 'Program' process, and then spills over into the re-'Run' process. I had mentioned in my original post, I am not good enough of a programmer to write some code in assembly to see whether the same thing occurs under·under the same·circumstances, using straight up assembly code. That is I why last week I started the small asm program, trying to simulate the pulsin equivilant in asm, before a ran into some major coding problems. Enough on that subject.
So, I am at a loss, I know its not circuitry, I checked that. I know its not coding style, it works under·'Run'·,and does·not work under the 'Program'·condition. My equipment is not bad, I have run other programs to make sure of that.
The code is a cut and paste.
Ray
******CODE
' =========================================================================
'
'·· File...... Test28pulsin.sxb
'·· Purpose... SX/B Programming Template
'·· Author....· Ray Sadeika
'·· E-mail....·
'·· Started...
'·· Updated...
'
' =========================================================================
'
' Program Description
'
'
' Device Settings
'
DEVICE········· SX28, OSCXT2, TURBO, STACKX, OPTIONX
FREQ··········· 4_000_000
'
' IO Pins
'
· irpin var rc.0
· led1 var rb.0
·' led2 var rb.2
'
' Constants
'
'
' Variables
'
·· temp1 var byte
' =========================================================================
· PROGRAM Start
' =========================================================================
'
' Subroutine declarations
'
·LEDON sub
·'LEDON2 sub
' GETSOME sub
'
' Program Code
'
Start:
·' PLP_A = %0000
· 'PLP_b = %00000000
· 'PLP_c = %00000000
·' temp1 = 0
Main:
·do
·''GETSOME·· 'Get a pulse reading
·pulsin irpin, 0, temp1
·loop until temp1 > 216·· 'Wait for signal from remote
·LEDON···· 'Turn the LED on/off
' LEDON2
·goto Main
END
'GETSOME:
' pulsin irpin, 0, temp1
'return
LEDON:
·TRIS_b = 0
·led1 = 0
·pause 1000
·led1 = 1
' pause 1000
return
'LEDON2:
·'TRIS_b = 0
·'led2 = 0
·'pause 1000
·'led2 = 1
'' pause 1000
'return
' =========================================================================
'
'·· File...... Test52pulsin.sxb
'·· Purpose... SX/B Programming Template
'·· Author....· Ray Sadeika
'·· E-mail....·
'·· Started...
'·· Updated...
'
' =========================================================================
'
' Program Description
'
'
' Device Settings
'
DEVICE········· SX52, OSCXT2, BOR42
FREQ··········· 4_000_000
'
' IO Pins
'
· irpin var re.0
· led1 var rd.0
·' led2 var rb.2
'
' Constants
'
'
' Variables
'
·· temp1 var byte
' =========================================================================
· PROGRAM Start
' =========================================================================
'
' Subroutine declarations
'
·LEDON sub
·'LEDON2 sub
' GETSOME sub
'
' Program Code
'
Start:
·' PLP_A = %0000
· 'PLP_b = %00000000
· 'PLP_c = %00000000
·' temp1 = 0
Main:
·do
·''GETSOME·· 'Get a pulse reading
·pulsin irpin, 0, temp1
·loop until temp1 > 216·· 'Wait for signal from remote
·LEDON···· 'Turn the LED on/off
' LEDON2
·goto Main
END
'GETSOME:
' pulsin irpin, 0, temp1
'return
LEDON:
·TRIS_d = 0
·led1 = 0
·pause 1000
·led1 = 1
' pause 1000
return
'LEDON2:
·'TRIS_b = 0
·'led2 = 0
·'pause 1000
·'led2 = 1
'' pause 1000
'return
What is occuring right now is the program starts up, in the 'Run' mode, and the LED starts flashing in a random manner. The way I think I coded it, the LED is supposed to be off until the IRpin detects a signal, then it goes and does the delay routine which turns the LED on for 1.35 secods, turns·LED off, and goes back to the top and waits for another IR signal. Because of the LED flashing in a random fashion, it seems like the IR detector is way to sensitive or the pin itself is overreacting. This is interesting because in SX/B that random flashing does not occur.
Now when I remove the delay subroutine, place the proper code to turn on/off the LED, the again loop works properly, sits and waits for an IR signal. And the program works as expected. Is their something about the delay sub that is having an effect on how the snb command works on re.0. Any ideas?
Ray
*****CODE
device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
;IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000··· ;Need this at 50MHz so delay works ~ 2.7 seconds
reset Main·····
;; Variables
·org $0A
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1
IRpin = re.0···· ;IR detector
LEDon = rd.0···· ;LED
·org $0
Main
·mov w,#$1F
·mov m,w
·mov !rd,#%11111110 ;Set rd.0 for output
again
·snb IRpin········· ;Waits for IR signal
·jmp again········· ;
·call delay········ ;Go do delay
·jmp again····· ;Comes back from delay
······················ ;goes to again and waits for IR signal
;;This is my delay loop, ~2.7 seconds @50MHz freq
delay:
·clrb LEDon
pause·· ;~ 1.35 seconds @50MHz freq
·decsz Counter1
·· jmp pause
·decsz Counter2
·· jmp pause
·decsz Counter3
·· jmp pause
;·clrb LEDon····· ;Turn the LED on
;pause1
;·decsz Counter1
;·· jmp pause1
;·decsz Counter2
;·· jmp pause1
;·decsz Counter3
;·· jmp pause1
·setb LEDon····· ;Turn the LED off
ret··················· ;Go back to where you were called at
jmp $
end··············· ;End of code
The next thing I did is 'Program', unpluged the power, unpluged the SX-Key, pluged in the 50MHz crystal, pluged in the power, and the LED goes on and stays on, not what is expected. I think that there is a problem with the way the compiler is handling the different IDE modes of 'Run', 'Program', ..., etc. I know that it is a bold accusation, but thats where the trail took me. I am really surprised that something like this has not occured to someone else. I am pretty certain that the equipment is OK because when I 'Program' other programs everything seems to work as expected, while it is done in the 'Run' mode. Now, if I can get a confirmation about this, then maybe I can work on something else. Any comments from anybody.
Ray
*****CODE
;;;
;; New28IR.src
;;;
device sx28,stackx,turbo
device oschs3····· ;High speed crystal, 1MHz - 75MHz
;IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000··· ;Need this at 50MHz so delay works ~ 2.7 seconds
reset Main·····
;; Variables
·org $08
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1
IRpin = rc.0···· ;IR detector
LEDon = rb.0···· ;LED
·org $0
Main
;·mov w,#$1F
;·mov m,w
·mov !rb,#%11111110 ;Set rb.0 for output
again
·snb IRpin········· ;Waits for IR signal
·jmp again········· ;
·call delay········ ;Go do delay
·jmp again····· ;Comes back from delay
······················ ;goes to again and waits for IR signal
;;This is my delay loop, ~2.7 seconds @50MHz freq
delay:
·clrb LEDon
pause·· ;~ 1.35 seconds @50MHz freq
·decsz Counter1
·· jmp pause
·decsz Counter2
·· jmp pause
·decsz Counter3
·· jmp pause
·setb LEDon····· ;Turn the LED on
;pause1
;·decsz Counter1
;·· jmp pause1
;·decsz Counter2
;·· jmp pause1
;·decsz Counter3
;·· jmp pause1
;·setb LEDon····· ;Turn the LED off
ret··················· ;Go back to where you were called at
jmp $
end··············· ;End of code
No, you're NOT going crazy, there indeed seems to be a problem if one sequences the programming function of an SX28 (don't yet know about 48/52) exactly the wrong way.
I have been able to get similar results to yours, although not yet identical, and I think I am homing in on what's causing it; it's taking asome time.
Tim experiences similar problems. I hope to have the exact sequence or cause nailed tomorrow, and then hopefully PJMonty can fix it, or at least get us a work-around.
Don't get too frustrated.....I'm sure we'll get this licked!
Cheers,
Peter (pjv)
I am not going "crazy', but I am getting very very frustrated. And the worst part is, because I am new with the SX, I can not come up with a good work-around to resolve the issue. And, when I think about it, I am not sure if I want to go down the work-around road, while I am still learning this stuff. But, I also do not want get stuck in a stall, while I have to rely on other people to verify if their is a 'real' problem. I still think that the SX will be the product of choice down the road, but it is very frustrating.
The other general observation that I have made is, you are saying that you can not replicate Timothy's or my problem exactly. I can not replicate Timothy's problem exactly. Timothy is using a PDB, I am using an SX28 Tech and SX52 proto board. Since you have not mentioned your hardware, I will assume that you are using the same hardware. I am wondering if it could be a combination of hardware and software. The reason I mention this is because I got two different outcomes when I ran the same program on the SX28 Tech board and the SX52 proto board. There definetily is a problem, but it does not show up exactly.
The other concern that I have is, is this the tip of the iceberg. As I start to get familiar with other commands, in SX/B, will they also start to show up as a problem under certain situations. The thought that I have, it is not a popular one, maybe Parallax should have an errata sheet listed on the web site. It would list known problems, problems that are perceived, and maybe a resolution status. That way I could look at the sheet and see if it would affect a project that I am thinking about. I am not trying to bash Parallax, just come up with some ideas as to how, with user participation, make the product more responsive to the user. But, I also do not want to become an unofficial BETA tester.·This is only my opinion.
Thanks
Ray
I promise that we do the best we can, and yet there will be times when one customer or another gets frustrated. It sounds like a simple matter to produce an errata sheet, but it's not when you don't have something concrete (i.e., repeatable every time) to print. I swear to you that I have not personally experienced the problems you're seeing -- I guess I've been very lucky because I run projects with the SX-Key and then switch to resonator to make sure everything is a-okay in a stand-alone situation (I've done this with a few projects that have become Parallax EFX products, and all are programmed in SX/B, and for obvious reasons must run reliably with a resonator).
When we can reliably duplicate a problem then we can document it and move forward toward fixing it. Honestly, we don't want you or anyone else to have troubles -- this is supposed to be fun! If you had any idea how much effort my boss (Ken) has put into revitalizing the SX and making the tools more affordable you'd be amazed; I don't think the guy has had more than a few hours sleep each night for the last year.
And no, there is no lurking iceberg. Have a look at our main product line: BASIC Stamps. Do you see what we use as the core (on most of the modules)? The SX28 and SX48 -- and those controllers get programmed with the same tools that we provide to you.
Happy Holidays ... I have to get back to packing (uugh!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
I think Jon said it well.
At this point I think the problem is not specific hardware related; I'm creating the (similar) problem on all together different hardware as well as on the SXTech board and on the PDB.
I hope there is enough time today to get to the bottom of the sequence that is causing this frustration for you. Please don't shoot me if I can't get it figured! Especially at this time of year things are quite busy here at work, and the money making things DO have to come first.
Cheers, and a Merry Christmas,
Peter (pjv)
I hope that I do not sound like I am holding you or anybody else personally responsible. If my posts give that impression, tell me, I will try to re-think how or what I am writting. It is frustration that is surfacing in my posts. Things like this happen, I know I will just have to make some adjustments. I do not expect or request that people make some special efforts. I guess all· that I was looking for is for somebody to say, yea, their may be a problem, with my particular setup.
So, take a deep breath, and take care of business first. Maybe, in the mean time I will come up with some really clever way of resolving my problem, the world will notice how clever I really am, the cash will start to flow ... LOL
Thanks and a Merry Christmas to you
Ray
I copied your SASM code from your post and pasted it into the SX-Key editor just to make sure that I'm using an exact copy of your code. Then hooked up a pushbutton for the IR input and an LED on the Professional Development Board. Then I did a "Run", and the program worked as expected. Next, I did a "Program", powered down the system, removed the SX-Key, inserted a 50 MHz resonator, and powered up the system again. On my setup, the program still runs as expected.
Actually, "Program" and "Run" are very similar SX-Key operations: Both first launch SASM to assemble the source code, and then start a programming sequence. "Program" terminates after the device has been programmed. "Run" automatically starts the clock generator that is on-board of the SX-Key. The clock frequency is set to what you have specified with the FREQ directive in your program. The clock signal is fed from the SX-Key into the SX via the OSC1 pin. In both cases, the SX program memory should contain the same code, and this is exactly the code also required to run the SX stand-alone with a resonator attched. (For debugging, the code will be a bit different though, but this is not the question here).
Just a crazy question: Did you check if the resonator you are using is a 50 MHz type, or did you plug in the 4 MHz type that also comes with the SXTech board by mistake?. When using the 4 MHz resonator, the program should work as well but the LED will stay on over 32 times longer, making you believe that the program does not work correctly.
Merry Christmas to you and all the others on the forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thanks for taking time out to help in my effort, I thought about your suggestion. I will try it later, but I am pretty sure that I had the correct resonator installed. I learned that lesson a couple of weeks ago when I was working with your code on the SX52 proto board. I stuck in a 4MHz resonator and the LED just seem to ether stay light, or it would be off for, according to my calculation, 16 seconds if I recall correctly, on each loop cycle. I thought that, like in SX/B, everything gets adjusted, when you change the resonator.
In one of my trial runs, in asm, I had the delay code removed, so all I would expect to get is a quick flashing of the LED when the button was pushed. When I did the 'Program' I did not get anything, the LED never came on. I think in that situation, if I am correct, the frequency would not matter.
I think that what I will have to do is, solder some headers on a new SX52 proto board, and start working with that one, if the problem disappears then I will know that something was wrong with the other board, I am hoping for that. As for the Tech board, I can still use it for 'Run' only situations, and avoid the 'Program' part of it. Then when your prototype board becomes available, I will just solder in the necessary stuff to make it a programmer.
I think at this point I have to put an end to this thread. It has gone beyond a learning lesson, and it is starting to waste peoples time. So, lets start thinking about something else.
··· THE END
Thanks
Ray
No, there IS something wrong. I'm not yet on top of it, but it seems to have something to do with the sequence of things when programming. I can cause something similar to happen, and cause that to go away.
I don't want to be premature in posting my findings until I have it nailed.....hopefully later today.
So, don't drop this thread; this situation needs to be fully explored and understood.
Cheers,
Peter (pjv)
From a learner, thanks for this thread. It means more than you might know for someone new to the game to "listen" to a discussion amongst knowledgeable people. Things become clearer. This is a great Forum. To all of you a Merry Christmas, Happy Hannukah, Great Holiday...you get the point. You've given me a gift with your discussion.
Thanks,
Jim
"hammering" an LED on and off w/o any delay from a 50 MHz-clocked SX really does nothing - the LED won't even "glow" because it is too slow to follow the state changes (due to its internal "parasitic capacity") (see the very first sample in my book).
Hard to believe that your board has a failure but you never know... After making sure that you really use a 50 MHz resonator, pull the resonator, and have an Ohm-Meter handy. The center pin of the resonator socket should be contacted to ground (the Ohm-Meter should read almost zero when you touch this center pin, and the center pin of the voltage regulator IC). The meter should also read almost zero when you touch the SX pin 27 (OSC1), and the corresponding pin of the resonator socket. The same should be true when you touch SX pin 26 (OSC2), and the other outer resonator socket pin. You may also verify that the two outer resonator socket pins don't have a short to ground (Vss), or a short between each other.
While you have the ohm-meter handy, it might be an idea to measure the resistance between SX pin 28 (/MCLR) and SX pin 2 (Vdd). You should measure some value between 0 and 10 kOhms - higher values indicate that the /MCLR pin is not properly pulled up to Vdd.
Yes, I know - this is all guesswork but - as we say in German "auch ein blindes Huhn findet manchmal ein Korn" - "even a blind chicken sometimes picks up a corn" - maybe, this helps...
Merry Christmas, Happy Hannukah, Great Holiday to you, and all the other forum members!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
Forget about the past, plan for the future, and live for today.
·
After everything cooled down I decided to see if, for the last time, the board, the KEY, and everything else·were really fried. This time I pluged in my 6V 4.0Ah battery, not trusting the wall-wart, low and behold everything still looks like it's functioning, I guess the regulator did its job. I did a 'Run' on some code, and that still worked, as expected.
This morning I took a step back, and decided to try to get a fresh look as to where to begin again, back to basics, if you will. After reading Timothy's problem, as stated in the '... debugger ...' thread, a question comes to mind, how do I really know if my SX-Key isn't the culprit of my problems. I suggest reading his thread to get the full appreciation. So, I guess I ask the question, here, again, is their some way, at home, to verify that the SX-Key is still functioning properly. Maybe, some of you asm gurus, when you have nothing else todo, can come up with an asm diagnostic tool that gives a prelim check of the SX-Key, if it is possible and economical to do. Even though this is a hobby, I would still like to know when my SX-Key, or the board·is at fault, and not me.
I do not want to make this thread any longer than it has to be, any comments are appreciated as always.
Thanks
Ray
Well, I've put in a ton of time chasing this issue, and I thought I was onto something, but it turned out to be a false trail; I'm sorry to not be of more help.
There are a couple more things I would like you to try please.
Please do exactly the following sequence:
1. Load your SX source.
2. Assemble it by pressing ctrl-A.
3. Press ctrl-I to invoke the "Device" widow.
4. Save a screen shot of the "Device" window. (I don't know how Timothy did this, but evidently there is a way; hopefully you know how).
5. Press the "Save Hex" button in the "Device" window.
6. Open up the saved hex file with the Notepad viewer, zoom to the end of the file, and capture a screen shot of this end. What I'm looking for is the values of the Fuse and FuseX registers near the very end of the file.
7. Return to the "Device" screen.
8. Press the "Read" button, and then again do a screen capture of the "Device" window. This is to confirm things DID get programmed the way we expected them to.
9. Post the three captured screen shots; well have a look at the fuse settings when you get this done.
10. Eat lots of turkey!
Thanks for your help, and cheers,
Peter (pjv)
Post Edited (pjv) : 12/25/2005 8:41:13 PM GMT
I hope this did not spoil your Christmas, you should of just left it for another time. I am starting to think that it is my SX-Key. I was fiddling around with this for the last few days and I am starting to think in terms of, get the new SX-Blitz when it becomes available, maybe by the dozen LOL.
I got the screen shots for you, I think. Learn something new everyday. Let me know if their is something wrong with the screen shots, this is the first time I am doing this.
Ray
Thanks for that.
Naw, Christmas is never spoiled by SX work ........ only enhanced!
I happen to note on your screen shots that you are now using the internal oscillator running at 4 Mhz.
From your earlier posted code we discerned you had this problem with 50 Mhz, so we're not doing the same thing just now.
Could you please repeat the tests and screen shots, with frequencies and parameters as coded in your original post; we both need to be doing EXACTLY the same things; anything else is comparing apples and oranges....
Also please add in a line in the capture sequence 8.1 as:
8.1 Press the "SX28" button on the "Device" window.
Also, how do you get those screen shots? (I'm PC illiterate).
We're off now to chew on some turkey....
Cheers,
Peter (pjv)
It does not matter what freq I use,·so I decided to use the internal RC, that way I know I will not mess up by putting in the wrong resonator when I do a stand-alone. I use·the internal RC·with the SX Tech and SX52 proto board now. Today I tried leaving in the SX-Key, instead of pluging in a resonator, same results, program did not work as expected. A question came to mind, how do you know if your SX-Key is working correctly? What I expect is a message like "SX-Key not found on com1", when the SX-Key no longer functions.
Actually the screen capture is pretty easy, all you need is the software. I went to CNET.com, and downloaded ScreenPrint32, although their might be other progs available.
Thanks
Ray
Waaay too much turkey; but so yummy.
Can you confirm you did things EXACTLY as I asked, including the 8.1 step?
If so, then we might be onto something. The first screen shot shows programming HS3 oscillator at 50 MHz, yet the last screen shot shows internal RC oscillator at 4 MHz is being used.
So if you programmed it as per screen 1, and it reads back as per screen 3 then..........
Please repeat and confirm.
Cheers,
Peter (pjv)
Sounds like you had a nice Christmas dinner; today you have to deal with leftovers.
I went back and repeated the steps, as it stands I got the same results. Now, in your post you mentioned the word 'programmed', in your list you did not request a ctrl-p or a ctrl-r·to be done. Was that an oversight? Because once I did a ctrl-p, did the read, the device window now listed HS-3 as the crystal. This only tells us that the HS-3 is the setting, but does not tell us that in fact it is woking at 50MHz. Does that make any sense.
Thanks for the prelim lesson in how to use the device window to do some diagnostics. I hope all the begginers that are reading these posts are learning as miuch as I am.
Going along this line of thought, is their a way of getting the hex code of an assembled code listing, hex code of a ctrl-r code, and ctrl-p code, specifically in that sequence. Then I guess, compare the hex files and see if there are any differences (this could be tricky). I am not sure if this would accomplish anything. So far, it does not look like anything of signignace is jumping out at me.
Thanks
Ray
OOPS, I screwed up!
Could you please repeat the whole process, including 8.1, and add a:
5.1 Press the "Program" button.
What I'm looking for, is something going amiss with the erase or programming procedure, and the read-back hex file being not identical to the program hex file.
The assembled hex file you are asking about is the file viewed with NotePad under point 6. The last line is for file checksum-like validity; the line above that holds the FUSE and FUSEX entries, the line above that holds the user's program ID.
The first number of characters of each line identify the length of the line, and where in memory to store it, and the last 2 characters are a line checksum.
Right, the oscillator settings in the window only show the Drive Level that is programmed into the oscillator amplifier; not it's operating frequency, as that is determined by the frequency of the what you plug onto it.
However, when the internal RC oscillator is selected, of course it's frequency is pre-selected.
I must say that I'm starting to grope at straws now.....
Is it possible you might somehow have a small capacitance inadvertently connected to the OSC1 pin? That was what was earlier screwing me up when I thought I was on the path of something. The 8 picofarads of my scope probe was enough to prevent the resonator oscillator from running.
Also I'm looking for your "IFDB" (10 MegOhm internal feed-back) resistor to be enabled. Without it the resonator won't run.
Do you have another SX28 chip to plug into the board so you can confirm it is:
1. Always the same chip that gives trouble, or
2. Always the same board, or
3. Any chip/any board.
Do you have an oscilloscope to confirm the level of the 12.5V programming voltage?
This is all very strange indeed.
Cheers,
Peter (pjv)
Post Edited (pjv) : 12/26/2005 5:36:45 PM GMT
I tried your suggestion about putting in a new chip, I did your steps, and step-8, there is a problem. When I hit the read button, it comes up with, "SX-KEY not found on com1". The chip is new, or at least it has only been·programmed once. I hit the read a couple of times, and nothing. Since it did a program succesfully, that means, I guess, that com1 was available for programming.
So, now does my SX-Key get a reprieve, and my SX Tech board is the culprit. Or is this just another false lead. I think we will have to call it quits on this one. There are just to many factors in play now that could be contributing to the problem.
As a last ditch effort, later on today, I will solder some headers on a new SX52 board, and see if the problems go away. If they do not, then I will have to do a reassesment of this situation.
Thanks
Ray
(Note that yor 6V battery is likely to be slightly too low a voltage - the regulator will (has to, in fact) throw away a certain voltage in order to do its job, so it's poosible that, when running from the battery, your SX-key isn't getting the 5V it needs. While yiou're chasing all sorts of other problems, I'd strongly recommmend you make everything that _is_ under your control as good as possible, and supply voltage definitely counts...)
Steve