reset process & ...

CannibalRobotics

·s there a difference between a reset using the reset line and a complete power down? The reason I'm asking is that frequently when I load new code, or use the reset button, my ADC, accelerometer and compass return all zeros. If I load that same code into the EEPROM and power·the prop·down then back up, things run fine... most of the time.
Even after that load, I can use the reset button and the same code will return 0's. I know things are running but it seems unpredictable.

Also, I hate to admit it but I'm discovering (the really hard way) I really don't understand 'whose on first'. When a cog is started, does it just load the code segment called in cognew or does it also load the routines "called by" it as well.
If a cog object calls something, does it load in with the cog object or initiate another cog. I've read over the manual and it's just not getting into my head. Any reference recommendations would be appreciated.

Thanks,
Jim-

·

Ken Peterson

I assume you're talking about SPIN. Since nothing exists in the cog except the SPIN interpreter, the routine you call with cognew() doesn't "load" anything except the SPIN interpreter in a new cog, which executes your program from HUB memory. Only with PASM does your code actually get loaded into the cog.

If you do cognew() with a PASM program, then 496 longs get loaded into the cog, starting with the address specified in the cognew() function.

Hopefully that answers one of your questions. Not sure about your reset question. Perhaps it is an initialization issue? A power down might reset your other chips, but the reset button won't. Perhaps they're not being reset properly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Philldapill

I've noticed something similiar, but with an SD Card. Everytime I powerup from a powerdown, The SD Volume doesn't mount. I have to hit the reset button for the card to work correctly. I doubt it's the card not having power because I will leave power supplied to the card when I do this, but disconnect/connect power to the propeller.

CannibalRobotics

I've plugged in some start up delays to make sure all of the control lines have time to settle then reset everything that has a reset gets properly configured but it is still inconsistant. I have noticed that once it starts working, I can generally depend on a RAM load to work the next time around but even that occasionally fails.
It's strange. I am now working very carefully through the code to make sure I don't have any port conflicts on the control lines. All of the A2D's use an active low enable or chip select so I'm thinking it could be a pin conflict since a 0 cant get by a 1 with the wired OR port control. But it seems like that would be consistant, either there is a port conflict or there is not?

Anyway, it's an enigma at the moment. I'll let you know.
Thanks for the input though, glad to know it's not isolated to my little board.
Jim-

Phil Pilgrim (PhiPi)

On the data lines that go to your peripherals, have you remembered to install pullup or pulldown resistors? These are very important, as they keep the data lines in a known state when the Propeller resets and tristates its pins. Without pullups/pulldowns, those lines could be all over the place during a reset, putting your peripherals in weird, unknown states.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Philldapill

@Phil - No, I have forgone the resistors. I've read that the card will work without them, so I tried and it has. I suppose that could be the reason it wouldn't work right on power up. Makes sense. I'll try doing that and stop hijacking this thread from Jim [noparse]:)[/noparse]

CannibalRobotics

No worries,
I went back through my design docs and couldn't find any specific reference to needing pull ups/downs. I do have current limiting resistors between the 5v output devices and the prop. In looking at the code, if it's executing properly there really are not any opportunities for the lines to float. Nothing shows up on the scope.
The accelerometer and compass data lines are bi-directional so I never read them until I've sent something out then switched the port direction. The ADC0838 pretty much just responds to clocks and control lines, it does not have a reset sequence per-se.
I think today the prop has worn me down. I'm going to go swimming.
Have a great weekend everyone.
Jim-

Phil Pilgrim (PhiPi)

CannibalRobotics said...
In looking at the code, if it's executing properly there really are not any opportunities for the lines to float.

Perhaps so, but during execution is not where the problems arise, so your code has nothing to do with it. It's during reset where all the Propeller's lines float, and reset can last a second or two.

Also, the peripheral datasheets won't mention it, because they expect inputs to be driven at all times. Without pullups/pulldowns, that simply won't be the case during reset.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Post Edited (Phil Pilgrim (PhiPi)) : 6/27/2008 8:30:56 PM GMT

CannibalRobotics

Well, it was not a reset issue in the classic sense.
As it turns out, the compass read part of the data acquisition object was stuck in a loop waiting for the "0011" indicator of good a good conversion.
I have found out that even though one resets and restarts the compass A to D on each pass, the A to D does not always get a complete conversion cycle.
Being used to the National Semiconductor A to D's that just clock out the data and let you decide if it's good or bad, it had not occurred to me that data might never show up. Probably would have seen that had I looked a little more closely at the docs.

Sometimes being away from the problem for a weekend does wonders. YaHoo!