details about boot procedure

ags

Has the boot code for Propeller1 been made available, and if so, where can I find it?

I'm looking for ways to reclaim pins 28/29 and 30/31 as I've run out of I/Os, so I've been looking more closely at the boot procedure.

Regarding pins 28/29, documentation says:

"If no host communication was detected, the Boot Loader looks for an external 32 KB EEPROM (24LC256) on pins P28 and P29."

but how exactly does it decide there is an EEPROM connected? Does it actually look for a specific signature at a specific address? The other half of the problem is how to enable/disable the EEPROM (using an address line seems obvious) without consuming an I/O to do so (not so obvious).

Regarding pins 30/13, the documentation says:

"[If it] Detects communication from a host, such as a PC, on pins P30 and P31."

but how does it do that? Does it expect to see idle state (high) on pin 31 (Rx) and if so begin communication on pins 31/30 (Rx/Tx)? If so then a pull-down on pin 31 should work; if/when the PropPlug/USB cable is present and powered, pin 31 will be driven high and boot/programming should work. If not, then it will be pulled low (say, 10k) and can be used as an input or output as needed (as long as 3.3v on the FT232R TXD pin is not a problem).

Something that puzzles me is how code I've been using to detect the presence of a serial connection has worked at all. I was given a suggestion to test pins 31 and 30 and if both high, consider the serial connection present. However, closely reading the data sheet for the FT232R does not indicate any pull-up on the TXD pin (output from the FTDI chip). So I'm not sure why this ever works:

if (ina[30..31] <> b11)  'Can't figure out how to get '%' to show up in post, it is dropped apparently as a special character
  <there is no connection>
else
  <there is a connection, start the PropellerSerialTerminal>

If pin 31 is not driven by the FT232R it floats. I would not expect that to reliably be detected as a high input. Can anyone explain this?

Mike Green

Yes, the boot code has been made available as well as the source code of the Spin interpreter. See here.

There are some limitations on how you could use pins 28..31. For example, you have to have a pullup on SDA (29) or the EEPROM won't work. Pin 31 (Rx), if initially low, indicates that there's no serial port present. If it's high, the code checks for specific data from the PC before accepting a download. You'd need a pulldown on pin 31 if you want the Propeller to assume there's no PC present.

If pin 31 is connected to an FT232R or MAX232 or equivalent and the chip isn't connected, it will either appear low or high to the Propeller. If low, there's no PC connection. If high, the Propeller will observe the line for a time looking for specific data and time out if that isn't present.

SRLM

You can reader the booter code here: http://forums.parallax.com/showthread.php/101483-Propeller-ROM-source-code-HERE

ags

Mike Green wrote: »

For example, you have to have a pullup on SDA (29) or the EEPROM won't work.

Thanks Mike. I think I've seen some snippets of the boot code (or derivatives). Is this because rather than setting pin 29 as an output and toggling state high/low, the code sets the state high and toggles direction high/low? Is there any particular reason it was done that way?

If pin 31 is connected to an FT232R or MAX232 or equivalent and the chip isn't connected, it will either appear low or high to the Propeller.

Not meaning to be slow here, but I don't understand. Sure, an input pin will either be high or low. Are you saying that the FT232R is always high (or low) and/or the MAX232 is always high (or low) or that an individual instance of either of these chips will always be high (or low)?

Mike Green

1) No. It's because the EEPROM (and other I2C devices) assume that there's a pullup in that they have an open-drain output that can only pull the I/O line low. This is so you can have multiple devices on a single I2C bus. Strictly speaking, you have to have a pullup on SCL as well. An I2C device will only drive the clock line during clock-stretching when the device is too slow to respond at full bus speed and has to make the bus master wait by stretching out the clock pulse. This isn't an issue with the EEPROMs used and these will never drive the clock line so the Propeller can always drive it and a pullup on the clock line isn't needed.

2) No. It doesn't matter whether pin 31 has a valid state if there's no PC present. If there's a pulldown, the boot loader will immediately check for a high, not find it, and go directly to look for an EEPROM. If pin 31 is read as high, the boot loader will assume there's a PC present and wait for a valid initial sequence to be received. If there's really no PC present, this test will eventually fail and the boot loader will go to look for an EEPROM, but there'll be a delay until the test fails. The pulldown is there to avoid the delay if there's no PC.

ags

Mike, great explanation on item #1 above, thanks. I was not aware of the clock-stretching you discuss, so I've learned something new.

On the other item, I am confounding the issue and obscuring the question. I now realize I asked three questions. The second is how an active UART connection is recognized, and you've answered that and it makes sense. The extra-credit question was "how does my existing code even work at all?". I was looking for a way to determine if there was an active serial connection before starting a serial terminal (PST). I found that if I started and wrote to PST when there is no active connection, my program hung. I attributed that to the Tx buffer eventually filling, and subsequent calls attempting to send data blocking. But further study indicates that this is probably not the cause; without support for flow control, PST will happily send data even when no one is listening (it seems). So my problem may have actually been the known issue when the FT232R is not powered, and pin 30 is raised. Apparently that causes a cycle of reset/release/reset.

In any case, when I asked how I could determine if there was an active connection the suggestion was to check to see if pins 30 & 31 were high; if so, the serial interface is present and powered. (See here: http://forums.parallax.com/showthread.php/129627-Is-there-a-way-to-query-for-presence-of-serial-connection-to-enable-disable-PST?p=977679&viewfull=1#post977679 )

It seems that unless there is a pull-up on the RXD pin of the FT232R (which is not indicated in the documentation) it is sheer coincidence that this method worked, or appeared to work. It seems the appropriate test would be to check only pin 31: if it is high, we can assume that the FT232 is present and powered. Would you agree?

Mike Green

In my programs, if I want to check for the presence of a PC connection, I just check pin 31. If high, I assume there's a connection and I initialize whatever serial driver I'm using with pin 31 as the receive pin and pin 30 as the transmit pin and I set a flag that I test later before trying to transmit or receive using the serial driver.

jazzed

ags wrote: »

t seems that unless there is a pull-up on the RXD pin of the FT232R (which is not indicated in the documentation) ...

According to note 3 in the spec below table 3.4 (Document No.: FT_000053 FT232R USB UART IC Datasheet Version 2.10) all FT232 UART input pins have 200K Ohm pull-ups.

ags

Yes, now that I know more about what's going on, that seems the proper way. I still don't know why

ina[30..31] <> 3

ever evaluated false, with pin 30 floating at the time of evaluation (unless there is a weak pullup on the FT232R RXD pin).

Would you also agree that (ignoring the FTDI reset problem when unpowered) the current PST implementation, which does not support hardware flow control, will allow me to happily send data (Tx) and not complain or block?

ags

@jazzed:

I saw that:

3. When used in Input Mode, the input pins are pulled to VCCIO via internal 200kΩ resistors. These pins can be programmed to gently pull low during USB suspend (PWREN# = "1") by setting an option in the internal EEPROM.

I read and re-read that, and concluded it applied to the configurable CBUS[0:4] I/O pins. I based that on the phrases "when used in input mode..." and "these pins can be programmed..." as the RXD line is always an input, it can't be anything else. This would explain why the code above worked, though. If I had an FT232R around that I could test I would verify that.