Test Circuit Problem 28X1

[pao]

So I've just hooked up a brand spankin' new 28X1 on my breadboard, with a solid meter-checked 5V power supply, reset pin tied high through a 4.7k resistor, and a 330 + LED combination on Pin 7. I'm running slightly modified test code, which doesn't work properly:

<code><pre><font size=2 face='Courier'>main:
high 7
pause 1000
low 7
pause 1000
goto main </font></pre></code>

I can Run the code through PE, and the LED blinks on for about two seconds, then blinks off, and does not come back on. The results are identical with <code><pre><font size=2 face='Courier'>let pins=%11111111 </font></pre></code> , and the LED doesn't come on if I specify a different pin, so it's not a hookup problem on the output side. If I swap the <code><pre><font size=2 face='Courier'>low </font></pre></code> and <code><pre><font size=2 face='Courier'>high </font></pre></code> commands, the LED never comes on. After the code is downloaded, hard-resetting the PICAXE does not turn the LED back on. I also just tried to set the output and LED on Pin 6 and got the same results (on, off, no loop).

The download circuit (I'm using the breadboard adapter) is clearly OK, since the download does happen. Power and ground have been meter-checked. Both grounds are connected. Other than not having a reset button, this is identical to the minimal 28 pin circuit plus the LED test output.

Any ideas?

 

[Technical]

Sounds like you are not using the correct 'physical leg' - output pin 7 is not the same as 'leg 7'. See the pinout diagram in the manual.

 

[pao]

I'm afraid I may have just been unclear--I have the LED on physical pin 28, output 7. (Physical pin 7 is sort of busy with the download circuit.) From the &quot;picture-worth-1000-words&quot; department: <A href='http://patrick.greentaperacing.us/picaxedebug.jpg' Target=_Blank>External Web Link</a>

That should get everyone on the same page.

 

[pao]

Sorry to break forum reply etiquette, but I should note the other leg of the LED is in fact on the ground rail, and yes, the LED is oriented properly--as noted it does light, but only once, and only if a 'high pin#' is the first command in the code.

 

[manuka]

That picture URL doesn't load for me here in NZ. Stan

 

[pao]

<BLOCKQUOTE><font size=1 face=arial>quote:<hr height=1 noshade>That picture URL doesn't load for me here in NZ. <hr height=1 noshade></BLOCKQUOTE></font><font face='Verdana, Arial, Helvetica' size=2>

Not being in NZ, I can't verify performance from there, but I just checked again and was able to load the link from here in the US. However, here's an alternative I just put up on Photobucket: <A href='http://i203.photobucket.com/albums/aa284/paoleary/PICT0125-small.jpg' Target=_Blank>External Web Link</a>.

I also just noticed that the LED is still on output 6 (pin 27), not 7, from the test in that position noted in my original post. Also, to add to the list of things hidden in the photo, you can't see the jumper from ground to pin 8 running under the breadboard adapter, before someone points that out.

 

[tarzan]

Check this post <A href='http://www.rev-ed.co.uk/picaxe/forum/topic.asp?topic_id=6941&amp;forum_id=31&amp;Topic_Title=Software+update&amp;forum_title=PICAXE+Forum&amp;M=False' Target=_Blank>External Web Link</a> it may be related to your problem.

Original post: <A href='http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=6933&amp;forum_id=30&amp;Topic_Title=%2526quot%253Bpins%2526quot%253B%2Bcommand%2Bon%2B28X1&amp;forum_title=No+new+posts+please%21+22' Target=_Blank>External Web Link</a>

 

[pao]

Well, I'm running 5.1.1 and used exactly the code mentioned as &quot;working&quot; in miba's post in the original thread. I'll go out and play with other output pins and see what happens.

Edit: Confirmed that the LED only turns on if its output pin is addressed. Outputs c0-c7 and 0-7 (pins 11-28) all exhibit identical behavior with code and circuit modified appropriately. I'll add that the LED appears to be on for longer than the commanded 1000ms, and turns itself off even if the entire program is:
<code><pre><font size=2 face='Courier'>high pin# </font></pre></code>
or
<code><pre><font size=2 face='Courier'>high portc pin# </font></pre></code>
as the case may be.

Every single output pin appears to be borked.

Edited by - pao on 26/05/2007 01:08:28

 

[manuka]

<b>Borked </b> <A href='http://www.urbandictionary.com/define.php?term=borked' Target=_Blank>External Web Link</a>- the &quot;passed over since considered too conservative&quot; meaning? I haven't heard that term on the Picaxe forum before, so maybe we should grab it for a specific woe?!

Your latter photo OK. Suggest you next at least try 3 x AA batteries to power the 28X1. The whole Picaxe family are REALLY sensitive to PSU &quot;noise&quot; as you may know &amp; 4.5V battery power could make an easy -erh- &quot;unbork&quot;. Stan



Edited by - manuka on 26/05/2007 01:24:47

 

[pao]

No, the first, more technical definition

Can certainly try a power supply swap, but will take some time, as we are fresh out of batteries in the house, and I don't have a holder in any case. I do have the 5V DC-DC supply I ordered from World Educational Services and can try that tonight. Thanks for the help, manuka.

Update: Guess its battery time. Maybe I can poach some...

Update Update: Found a battery stash, and McGuyvered up a battery pack from some 100 MPH tape, a bar clamp, and some 16 ga. Hooked it up, metered it at 5.27 V, and found I was completely unable to communicate with the PICAXE. Hoping I hadn't killed it, I unplugged the programming cable, pulled the battery supply, and put the original supply back.

Then the LED started blinking.

I plugged in the programming cable, and it stopped.

I unplugged it and it started again.

<i>If this is the way it is supposed to work, then Technical, can you amend Manual 1, in the section &quot;Testing the System&quot; to note that you must *unplug the download cable* to start the program running? </i> The preceding statement is clearly wrong, as the command &quot;debug&quot; would be rendered useless if it were true.

If this is <b>not </b> the way it is supposed to work, then I suspect it's not a 28X1 bug as it would certainly have been reported by now. It could be a PE bug, I suppose, but same reasoning leads me to believe it's a quirk of this computer. Could the PE be modified to explicitly hold the serial port in a state where the program will run?

Thanks to everyone who helped me get my LED blinkie (&quot;the 'Hello World' of the embedded world&quot going this evening (my time; early afternoon for manuka).

Update Update Update: Technical, the PE seems to be holding the serial input pin high by default. Using the comm tester I toggled the serial input back and forth--the LED button in the window starts off with the voltage high, stays high when I toggle it high, goes low when I toggle the button back low, and the program on the PICAXE runs. However, when I close the window, the input goes high again, and the program stops.

Hope this helps.

Edited by - pao on 26/05/2007 03:06:58

Edited by - pao on 26/05/2007 03:33:39

Edited by - pao on 26/05/2007 04:57:58

Edited by - pao on 26/05/2007 05:05:16

 

[manuka]

I still await 28X1 delivery, so am unable to replicate this bizarre effect. However I sensed circuit/flaoting values will be the culprit. Are thus 2 programming resistors in circuit OK? STRONGLY suggest you upload an EXACT schematic of what you've lashed up so we can have a looksee. Cheers- Stan

 

[hippy]

pao : <i>reasoning leads me to believe it's a quirk of this computer. </i>

It does seem to be a particular quirk of your computer, operating system or configuration.

The PE can only control the line level while it has the serial port open and it only keeps the port open when it needs to. This is done to allow other serial port monitoring applications to run while the PE is opened.

It seems to be that when the port closes something else takes control of the serial port line. Make sure that you are not running any PDA hot-sync or similar applications at start-up or in your System Tray.

<i>Could the PE be modified to explicitly hold the serial port in a state where the program will run? </i>

Potentially, but that would have to be done by way of keeping the serial port open which would cause other people problems, so would have to be a user-selectable option if it was changed.

In the mean time, you can add a switch or a Molex link directly between Leg 6 of the 28X1 and 0V ( the rest of the circuit stays the same ), and then it's a simple case of keeping the switch closed or link in place while running your program, rather than having to remove the programming cable. Open the switch or remove the link when you need to download or you will get a &quot;Hardware not found&quot; or similar error.

Alternatively, you can force the PE to keep the serial port open by pressing F6 or F8 to open the Debugging or Terminal Windows. The Debugging window can be forced to always open by putting &quot;ENDEBUG&quot; as the last line of your source code, and an option under View-&gt;Options-&gt;Editor forces the Terminal to open after every download.

It is worthwhile trying the opening of the Debug and Terminal Windows to check that when open your program does run. If not ( when the PE does have control of the serial port line ), then you have a more complex problem to deal with.

 

[pao]

I didn't realize that the PE wasn't holding the serial port open; most serial applications I've used (i.e., Hyperterminal, MegaTune) do keep it open. In any case, closing the PE doesn't switch the output low so that eliminates it as the true culprit.

No other serial applications are running on this computer. I checked with PortMon to be extra-double-sure.

<i>Alternatively, you can force the PE to keep the serial port open by pressing F6 or F8 to open the Debugging or Terminal Windows. </i>

Neither worked. However under some unknown set of conditions, PortMon does knock the line low (starting it did it once--only once--and saving a log file did it again). I'm not sure what exactly those conditions are and replicating is difficult. Let's see what a reboot does.

Post-Reboot Update: Serial unsurprisingly goes low when computer is off. Turn computer on; serial briefly goes high through post, then back low. Windows (XP SP2, if it makes a difference) boots. At the end of the graphical boot screen (the one with the meaningless scrollbar), the line goes back high before showing the user login screen, and stays high through login, application start, etc. So this is definitely not a Rev-Ed related issue, this is now clearly something up with this computer.

Mankuka, I'll get you a schematic if it helps, but to summarize, it is the minimum 28-series circuit shown in the manual plus a test LED on output 7. I'm using the Rev-Ed breadboard adapter, AXE029 (<A href='http://www.rev-ed.co.uk/docs/axe029.pdf' Target=_Blank>External Web Link</a>). I somehow managed to break a test lead for my meter, so I'm going to run and grab a replacement so I can double-check that I soldered it properly.

Final thing is to try another computer and see if I can replicate, which I ought to be able to try. Stay tuned.

Edited by - pao on 26/05/2007 16:43:31

 

[craigcurtin]

Pao, You might be onto something here. I had a similar issue when i converted to a custom board (made by one of the respected regulars on this forum) using a 40x1, whihc i had previously run just fine on an AXE110 datalogger.

Turns out if i have the board connected to serial port 2 on my computer and do not have the debugger running - then the circuit seems to go to sleep - it will however continue processing from wherever it was up to by either disconnecting the serial cable or going into DEBUG.

If i moved the serial cable to Com1 no issue at all. If i ran the same code on the AXE110 no problem.

I built a PC from scratch with XP-SP2 only, disabled the XP firewall Service (and hence ICS) and the problem still continued.

I have not got to the bottom of it yet

Craig

 

[pao]

Craig,

Well, I'll be dinged. I've been running this off of COM2 the whole time. Didn't think it mattered, but I just moved the cable to COM1 and everything works like its supposed to.

Maybe it's a Windows thing? I'll check if it survives a reboot. If it does, then perhaps a note should be added somewhere.

Update: Yep, still works after a reboot. Definitely a COM1/COM2 thing, don't know if its a Windows, chipset, or driver thing. The serial controller is reported as an Intel 82801BA LPC Interface Controller, and this computer has an Intel 815 chipset.

Thanks again for all the help getting me up and running.

Edited by - pao on 26/05/2007 19:41:15

 

[MORA99]

I have had 18-X and 08-M running off both com1 and 2 on a windows xp pro machine.

Dont have any spare x1 parts to test with, just fyi it can work