New Propeller Tool v1.3.2

Jen J.

We have a released Propeller Tool v1.3.2 today.
Special thanks to Jeff Martin.

Get the download here.

Rayman

Thanks. Looks like you don't need that pullup resistor for Quickstart with this new version...

Daniel Harris

I believe this release specifically targeted that problem.

prof_braino

Just noticed there are two threads of this name, and I posted this to the other one:

I notice the Parallax semiconductor downloads page
http://www.parallaxsemiconductor.com/software#Downloads
still has a link to the v1.3, and does not have a link to the list of propeller tools versions
http://www.parallax.com/ProductInfo/...9/Default.aspx
Is this still an "unofficial" release? I would think that since this addresses a quickstart issue, that the page linked from the quickstat board would be the FIRST place to have the new tool.

MacTuxLin

Daniel Harris wrote: »

I believe this release specifically targeted that problem.

Hmm ... I don't get it, how does a software update eliminates the need for these pull-up res?? Don't see anything obvious in the bug fixes section...

Phil Pilgrim (PhiPi)

MaxTuxLin wrote:

... how does a software update eliminates the need for these pull-up res??

When the Prop is in reset, and before the bootloader starts, the serial output pin floats. During that time, any excursions across the serial output buffer's logic threshold would produce garbage and, possibly, be interpreted as actual data. By ignoring the garbage in the Prop Tool, Parallax has produced a work-around -- not a solution -- until they can actually fix the problem by adding a pull-up to the QS. At least that's my hope.

-Phil

MacTuxLin

Got it. Thanks Phil.

RobotWorkshop

Did you happen to add a command line switch to specify the COM port to use?? That is a feature that would be a HUGE help when working on projects with Multiple Propeller boards. With that you can just create desktop shortcuts that will automatically start the Propeller tool with the proper COM port ready to go.

Robert

David Carrier

Phill,
There is a bit more to it than a floating I/O pin. The update in the Propeller Tool went from an unintentional workaround to a solution that wasn't fully implemented.

All of the I/O pins on the Propeller are identical, so that no I/O pins are limited in their functionality. In practice though, there are a few exceptions. The video generator can only connect to the I/O pins as four eight-bit blocks, some I/O pins have more latency than others, depending on which cog is writing to them, and the code in the boot ROM only boots serially from pins P30 and P31 or from an I2C EEPROM on pins P28 and P29.

The Propeller needs an external source for the program, since it cannot store it internally, but it doesn't need both a serial connection and an EEPROM. The PropScope, for example, doesn't store its firmware on the EEPROM, it just stores calibration data there and gets its firmware through a serial connection from the computer. It could work with the EEPROM on any other I/O pins, as long as the firmware read from it there. Pins P28 and P29 could then be used for anything else. If the Propeller fails to load firmware from the serial port, it will drive and toggle both P28 and P29, so anything connected to those I/O pins does need to be tolerant of such conditions.

The serial pins, P30 and P31, on the other hand, are never driven unless the Propeller is receiving a program through those pins. This means that an application only needs to dedicate two of the I/O pins to an I2C bus, and the remaining 30 I/O pins can be used for anything and will not be affected by the ROM.

To accomplish this, The Propeller ROM has to be absolutely sure it is receiving a program on its RX pin before driving its TX pin. If it were to have a false positive, it could end up driving its TX pin in away that negatively affects the circuit connected to it. To ensure the Propeller is receiving a program, it checks for 250 contiguous bits of a pseudo-random sequence generated by a linear feedback shift register. Only after receiving the sequence will it drive its transmit pin, at which point it will respond with the next 250 bits in the same LFSR-generated pseudo-random sequence, to prove to the device sending the program that the Propeller has begun driving its transmit line.

Versions of the Propeller Tool prior to 1.3.2 used a shortcut and cleared the receive buffer after transmitting the pseudo-random sequence, then began receiving the next portion of the pseudo-random sequence from the Propeller and aborted if any bits were incorrect. This didn't really work with USB to serial converters, because the Propeller Tool could only clear the data in the buffer that the driver used to send data to the Propeller Tool, but it couldn't clear data in the USB to serial converter itself.

Originally, this problem only became apparent when a program was transmitting data, at a high baud rate, to the USB to serial converter immediately before the computer initiated programming. It would work if the Propeller was Reset within one second of initiating programming, since it wouldn't be transmitting. The FT232R, which is currently used in all production Parallax products that include a USB to serial converter, has enough input bias current on its receive pin to prevent it from receiving invalid data while the Propeller is restarting and its transmit line is floating. The combination of the Propeller transmit line floating and the FT232R weakly holding the pin steady generally covered up the problem by prevent any data from getting into the buffer in the first place.

The QuickStart uses a buffer to isolate the FT232R from the Propeller when there is no USB connection, to free up the pins as intended by the Propeller booting protocol, but the buffer forwards the state of the floating transmit pin to the FT232R, overpowering the FT232R's input bias current. This allows the FT232R's input buffer to fill even when the Propeller isn't driving its transmit pin, so the problem manifests itself far more often on the QuickStart than on other boards without the buffer.

Version 1.3.2 of the Propeller Tool ignores all data before the LFSR sequence it is expecting, instead of aborting, so it is unaffected by data lingering in the FT232R's buffer, completely solving the problem.

If you need pins P30 and P31 to always act as a UART, such as when using a debug tool that always expects a UART to be attached to the com port, you can pull the transmit line high, which in versions of the Propeller Tool prior to 1.3.2 would have prevented the floating transmit pin from aborting programming due to random data in the buffer. The fix was still needed though, because the pull-up resistor didn't prevent the Propeller Tool from abort programming when the Propeller was transmitting at a high baud rate immediately before the computer initiated programming.

— David Carrier
Parallax Inc.

Rayman

Thanks David for that very detailed explaination.
Sounds like that in addition to solving the Quickstart issue, this may solve other issues as well.

Publison

Very good description of the inner workings.

Thank You!

Jim

Phil Pilgrim (PhiPi)

David,

Thanks very much for the more detailed explanation. Wow, there's a lot more going on after reset than I imagined!

I still contend, however, that as a general design rule, it's best to pull all of P28-P31 high on any Propeller module. The circumstances under which a pull-up will interfere with alternative uses P30 and P31 are rare and, IMO, are outweighed by the benefits of having a default MARK state imposed on these pins during reset or when the USB chip is either unpowered or, in the case of a Prop Plug, disconnected.

-Phil

MacTuxLin

Wow ... thank you David.

Now I also understands why there was the

  repeat 250                   
    if WaitBit(1) <> IterateLFSR
      abort ErrorConnect

In Chip's Loader program when I was doing the uSDLoader...