Hi Guys,
My Isopod is behaving oddly... The autostart works great but when I turn off the unit and leave it off for a few hours then it starts up normal but quicly gives me garbled text on the LCD. The only solution is to reload the code. I can turn the unit on and off endlessly with proper operation as long as I do not wait for some hours...

Also, the code involving "PB1...7" is not working with autostart.. It works when I do not load the code with autstart included. I only read the condition on the PBx pins which are connected to some switches and defined as input. The defined Forth word is not recognized with autostart.....
Any thoughts? I am puzzled...

Cheers,

Per

Hi Per! Great to hear from you. Unfortunately, my spam filter pidgeon holed your post. Pure luck I decided to check before emptying the spam mail. So I'm just seeing it now.

First question I'd ask, what do you have for power supply? Any chance you've missed a word that didn't get moved to Flash? That's the most common source of such problems.

Consider this, maybe the word not moved is seldom used. So if it drops out of memory, but isn't called for a couple hours, or the powersupply is bleeding just enough to keep the RAM alive for a few hours, then you'd see the behavior you describe.

It's hard to remember all definitions, even variables and constants, and all transitions, must be preserved in Flash. Any of them falling out blows the dictionary linkages.

Hi Randy,
It is a peculiar problem. The autostart procedure is OK as the LCD comes up with a proper display..before becoming corrupt...
If I start up the system and let the screen be populated with radom characters for a few minutes and then switch off for a few seconds, then it will start up with the proper LCD characters and remain OK.
I can then turn the system on and off repeatedly with a proper screen function. But, if I wait a few minutes before turning the system on then it again becomes corrupted. Very strange.
Power is not a problem and the Pod is fed with a 1A 7808 regulator..
I asked the question just in case you had run into this before.
I guess I have to pull things apart to see if there are any odd voltage behaviours related to the LCD control wiring. However, that does not make sense as everything is rock solid once the LCD is clean.....

Must be the good old gremlins......

Cheers,

Per

PS. How is your Pod V2 or V3 inventory?

Well, I would not open things up first. I'd search for the un-Flash-ed word first. I mention this because I have run into this odd behavior every time I've forgotten to move something to flash. The taking a few minutes is different. But I think it still fits well. The Autostart can work, and not reference the words in the dictionary that aren't there. Everything will seem fine. They somewhere down in the program, something gets referenced that goes to execute the work that is not there. >Poof< Things get weird. May seem like gremlins, but not be real. Or not, of course.

Just wanted to let you know it wasn't a casual speculation, I've seen this before to be this cause. Usually, the crash/trouble is more immediate. But it doesn't have to be.

Is there anything in the program that only gets called every few minutes?

No V2's in hand. We have V3 stock PCB's in house. Don't know off the top of my head how many. Should be about 10. May be they're already assembled and tested. Unfortunately BC has already left for the day so can't give more accurate answer right now.

Hi Randy,
the code bit did not make sense as it behaved properly on start-up.
I ended up opening the unit and after some frustration found a Gremlin....
A tiny hidden one in the form of a erratic wire ground connection...
Now it works as it should....
For a while I wondered if there was a peculiar problem with the Pod given the start-up beaviour but, I was wrong.
Time for creating a PCB.... Once that is done then I will get to a Pod v3 or a plugapod order.

Cheers,

Per

That's good news. I was thinking I needed to write a utility that looked for definitions not in the Flash. But if you've caught the problem elsewhere, great. Remember we do custom layouts and boards if you want something like that and we can help.

It works fine but I now have another question...
While the program runs I occationally do an ADCx ANALOGIN . to watch some values. An odd thing happens though... The output on the computer shows one of the 4 digit variables displayed on the SPI LCD added to the output as extra digits or simply superimposed. It also happens if I look at a stored variable..
Why is that?
As for PCBs I already own an CAE package for that purpose... Prototype boards are more reliable than wires and solder on a multipurpose board.

Cheers,

Per

Now that is something I haven't heard of or seen before. I do have an idea though. If you're doing printing in the foreground, and printing in the packground at the same time, you only have on PAD area to construct numbers for output. So the background routine will overwrite the area you were setting up in the foreground. User Area values are vectored, so you could try changing UPAD to another temporary spot during the background. As I recall, the output string is built from the PAD address-1 down. So it is below PAD. You need a free spot of memory below where UPAD points.

Does that sound like it?

Oh, too, I wanted to mention we have the SuperPod(TM) in stock now. I haven't done the press release yet. But this is just bigger than a PlugaPod(TM) (We called it the SuperPlugaPod(TM) elsewhere on this forum) but has all the features of the IsoPod(TM) and ServoPod(TM), many times more memory, and half again the speed. We're introducing them at $199, have a limited number on hand, and we can ship today.