Inactive Propeller

Vega256 · 2011-02-17 14:24

Hey Guys,

I was testing some of my first drivers that involves input through one of the I/O pins. I applied 3.3V to one of the I/O pins which was acting as an input to emulate a logical one. I tested that driver for quite a while before the Propeller exhibited strange behavior. Not only has it stopped executing that particular driver but the video drivers produce distorted video on the screen. I checked the maximum ratings and the maximum allowed voltage on any other pin with respect to Vdd was -0.3V - (Vdd + 0.3)V.

I seems unlikely, but have I destroyed my Propeller?

MagIO2 · 2011-02-17 14:46

Can the propeller tool still find your propeller?

My first guess is that you have a bug in your code. Of course the code has full access to HUB RAM, so a bug can cause problems for each other COG that relies on data in HUB RAM. Each SPIN COG can show strange behaviour if the stack is corrupted.

As a beginner you should always add an resistor (say 1k) to each I/O pin that you use - no direct connection to other hardware. This protects the pin from a shortcut caused by a bug.

Vega256 · 2011-02-17 14:48

I am not using a Propeller Tool. I have a breadboard setup.

Leon · 2011-02-17 14:51

The Propeller Tool is the Parallax Propeller IDE, not a piece of hardware!

Vega256 · 2011-02-17 14:55

But my Propeller is never in any way connected to the computer. I program the EEPROM, insert it into the breadboard, and connect power. So, the Propeller Tool cannot "find" my Propeller.

MagIO2 · 2011-02-17 15:03

So, what happens if you reset the propeller (or power down/power up)? Does the program run then for a while, showing the same problem again. Then it's your program.

Vega256 · 2011-02-17 15:05

What type of logic bug would cause the hardware to do this?

MagIO2 · 2011-02-17 15:13

For example recursive calls of functions.
Starting SPIN COGs with a stack that's to small.
PASM COGs that write to HUB RAM areas that are used by other COGs (for example the video driver)
....

Post your code and we can tell you ...

Vega256 · 2011-02-17 15:15

var
  word address
  byte data
  byte holdPin
  byte readPin
  byte holdAckPin
  byte addressBitIndex
  byte pinAckIn
  
pub first
  holdPin := 3
  holdAckPin := 4
  readPin := 5

  address := 0

  dira [31..16] := %11111111_11111111
  dira [15..8] := %00000000

  dira [holdPin] := %1
  dira [holdAckPin] := %0
  dira [readPin] := %1
  
  waitcnt (cnt + 7_000_000)

  outa [holdPin] := %1
  pinAckIn := ina [holdAckPin]

  repeat while ina [holdAckPin] == %0

  repeat
    outa [31..16] := address
    if address == %11111111_11111111
      address := 0
      address ++
    waitcnt (cnt + 5_000_000)

MagIO2 · 2011-02-17 15:31

You should always post the whole code! You talked about a video driver. If you have more then one SPIN file, simply archive your project in the propeller tool and attach the ZIP-file to the post.

First comments to this code:
I think it's a bad idea to use pins 16...31 like this, as pins 29 and 28 are used for the EEPROM. Pins 30 and 31 are used for prop to PC connection during boot of the propeller.
The indentation of
address++
seems to be wrong. It's "inside" the if and will never be executed.

Vega256 · 2011-02-17 15:39

I did not use the said video driver in this object. I loaded it separately to test to see if my Propeller was burnt. The objects are here. Doesn't the Propeller know when and when not to use certain pins?

Mike Green · 2011-02-17 16:21

The only way the Propeller "knows" which pins to use is what your program says. I/O pins 28-31 have special uses while the Propeller is initializing itself. Pins 30 and 31 are used to connect to a copy of the Propeller Tool or equivalent program running on an attached PC or some other device. If the Propeller doesn't get a specific response on these pins within a short period of time, the Propeller's initialization routine assumes there is no PC attached. Pins 28 and 29 are used to control an attached I2C EEPROM if present. If attached, a program is loaded from the 1st 32K of the EEPROM. If neither option is present (PC or EEPROM), the initialization routine stops the Propeller.

Once the initialization routine loads a program from either the PC or an EEPROM, these special I/O pins are no longer needed for this use and they can be reinitialized and used for other purposes.

Vega256 · 2011-02-17 17:08

MagIO2 wrote: »

First comments to this code:
I think it's a bad idea to use pins 16...31 like this, as pins 29 and 28 are used for the EEPROM. Pins 30 and 31 are used for prop to PC connection during boot of the propeller.

I was only questioning this comment. Why is it a bad idea to use these pins if the communication between the Prop and EEPROM ends before the program uses them?

Mike Green · 2011-02-17 17:21

Pins 28-31 are the issue. For a period of time, the initialization routine in ROM will make some of these pins outputs. Pin 30 specifically is set to output mode and its state will go from high (1) to low (0) as the routine attempts to communicate with a possible attached PC. Pins 28 and 29 are both set to output mode at times in an attempt to control an attached EEPROM. As long as what you have connected to these pins can tolerate this sort of use for a time, you'd be fine attaching something else to the pins. Most of the time, it's easier just to not use them for anything else than their boot functions. Commonly, pins 28 and 29 are used for other I2C devices like a RTC or I/O pin expander.

MagIO2 · 2011-02-18 05:58

Ok ... you can reuse those pins if you know what you're doing!
So, tell me ... what do you do to make sure that the signals you send on pins 28 & 29 do not look like a EEPROM-read instruction? Or even worse an EEPROM-write instruction? The best case is that you recognize those kind of problems immediately. Worst case is that your project is compleded and after months you have one occurrence of a write EEPROM and you will never figure out what happened ;o)

You should spend some $, € or whatever currency that's used in your country to buy a propeller plug or any other USB 2 serial converter. Your current programming cycle is wasting a lot of time and sending debug-information to the PC is so easy and helpful.

What do you expect from the first code you posted in the [ code ] - segement? As I said ... if this is really what you have in the propeller tool, the position (intendation) of address ++ avoids it from outputting anything else than 0 on the address-lines.

Do you run your propeller with a chrystal or with the internal clock?

Vega256 · 2011-02-18 06:46

MagIO2 wrote: »

Ok ... you can reuse those pins if you know what you're doing!
So, tell me ... what do you do to make sure that the signals you send on pins 28 & 29 do not look like a EEPROM-read instruction? Or even worse an EEPROM-write instruction? The best case is that you recognize those kind of problems immediately. Worst case is that your project is compleded and after months you have one occurrence of a write EEPROM and you will never figure out what happened ;o)

You should spend some $, € or whatever currency that's used in your country to buy a propeller plug or any other USB 2 serial converter. Your current programming cycle is wasting a lot of time and sending debug-information to the PC is so easy and helpful.

What do you expect from the first code you posted in the [ code ] - segement? As I said ... if this is really what you have in the propeller tool, the position (intendation) of address ++ avoids it from outputting anything else than 0 on the address-lines.

Do you run your propeller with a chrystal or with the internal clock?

After realizing the issue with the TX/RX and EEPROM pins, I devised a solution. I will multiplex some pins so that pins 28-31 can be left alone. I did find the bug in my code. Thank you; I must have tabbed that line over by mistake and the indentation format of SPIN/ASM does not help. I come from C/C++. I use a crystal, by the way.

max72 · 2011-02-18 09:06

Did you activate the block indicator in the propeller editor [CTRL+I]?
It helps a lot with indentation..

I also second the suggestion to have a serial connection with your PC. This way you can program the RAM, speeding thing a lot things, and you can use the terminal for debugging. The prop plug is the easiest solution, but not the only one.

Massimo

Inactive Propeller

Comments