How does the propeller tool write to the propeller?

turbosupra

Hello,

I've found the information below and I have a few questions about the step by step process that occurs.

Does the propeller tool first build a .eeprom or .binary file out of spin code and then write it byte by byte to the uC?

Can someone also expand in detail the last paragraph of my quote, with a short binary example and why it does that?

First the Propeller Tool seems to open the serial port in 115200-8-N-1 mode. After toggling the DTR line to reset the Propeller, it transmits 0xF9 followed by a sequence of 0xFEs and 0xFFs. This sequence is followed by a large block of 0xF9s. I'm sure all this corresponds to the 250 iterations of the LFSR but I don't see how. When I tried to duplicate the LFSR in Python I couldn't get anything even remotely close. Then the Propeller responds with a similar (but different) block of 0xFEs and 0xFFs. Again I'm
sure this corresponds to the LFSR somehow. The Propeller then sends 2 bytes 0xFE 0xFE which I believe is the version number?

After this the Propeller Tools sends a command byte (RAM or EEPROM) followed immediately by block of data which corresponds to the binary image of the program. I haven't spent alot of time analyzing the format of the this data, but it doesn't seem to directly match up with the bytecodes of the program. Something weird is going on here and I think has to do with how the Propeller is "reading" the serial data.

Finally the Propeller Tool sends 0xF9 periodically (every 50msec seems to work) until the Propeller responds with 0xFE. This acknowledgment protocol can be repeated twice more if the command code was programming to the EEPROM.


The $F9 (249) is the 'calibration pulse'. The start pulse is a short (one) pulse while the two zero bits in the $F9 (249) is a long (zero) pulse. After that, the least significant bit of the LFSR is sent by the Tool, one per character, for 250 bits, with the $FF (255) being a short (one) pulse and the $FE (254) being a long (zero) pulse. Then the Propeller sends back the next 250 bits in the LFSR, also one bit per byte by echoing the $F9 (249) characters, changing them to $F8 (248) to indicate that they were processed properly.

After all the LFSR bits, the Tool and the Propeller shift into a 3 bits per byte mode with each bit cell being 3 bits and the start bit counting as one bit of the first cell (which is always zero). As you might expect, a one is a short (1 zero pulse time) and a zero is a long (2 zero pulse times) and the Propeller echos the data. There's a mix of 8 bit and 32 bit sequences, etc

Tracy Allen

Look back at the original thread where Chip Gracey posted "proploader.spin". He adds some comments in the thread, and the program explains itself. The loader uses a ratiometric scheme to represent the 0s and 1s that are transmitted serially. A "1" is a pulse of duration t, and a "0" is a pulse of duration 2t, where the exact value of t does not matter. It is done that way because the Prop is running in its RCFAST mode and there is not a certain clock frequency on the prop side. On a standard serial port, one byte of eeprom data becomes several bytes of transmitted data.

turbosupra

Hi Tracy,

Thanks for the reply.

I'm trying to make sense of the protocol, it says the $F9 is a calibration pulse, the "start pulse is a short (one) pulse while the two zero bits in the $F9 (249) is a long (zero) pulse". So in binary that is 11111001 and it's feeding it from right to left? After that, the propeller tool takes the remaining bytes left in the 251 array byte array (250 of them) and strips off the left 7 bits sending only the remaining single right hand bit? Then somehow the propeller echos back either 11111000 or just 0, for 250 times as part of the identification procedure?

The it uses a 3 bit per byte scheme, with all 3bit bytes starting off with a 0 for the first clock cycle, and it sends data serially by being 010 or 001? This is done to bypass any clock frequency mismatches?



With this private method, I'm trying to wrap my brain around all of the bit wise shifts to the left and Xor comparisons, I'm hoping if I stare at it long enough, it'll click.

PRI IterateLFSR : Bit

'get return bit
Bit := LFSR & 1

'iterate LFSR (8-bit, $B2 taps)
LFSR := LFSR << 1 | (LFSR >> 7 ^ LFSR >> 5 ^ LFSR >> 4 ^ LFSR >> 1) & 1

LFSR := (LFSR bit wise shift 1 to the left) OR ((LFSR bit wise shift 7 to the right XOR LFSR bit wise shift 5 to the right XOR LFSR bit wise shift 4 to the right XOR LFSR bit wise shift 1 to the right) & 1)

So it is LFSR bit wise shift 1 to the left, unless the 8 bit binary value passes the XOR comparisons ... what's with the & 1 at the end?

Tracy Allen wrote: »

Look back at the original thread where Chip Gracey posted "proploader.spin". He adds some comments in the thread, and the program explains itself. The loader uses a ratiometric scheme to represent the 0s and 1s that are transmitted serially. A "1" is a pulse of duration t, and a "0" is a pulse of duration 2t, where the exact value of t does not matter. It is done that way because the Prop is running in its RCFAST mode and there is not a certain clock frequency on the prop side. On a standard serial port, one byte of eeprom data becomes several bytes of transmitted data.

Cluso99

turbosupra: The source code of the prop end has been posted. Its called "booter.spin" and was posted with the spin interpreter. Maybe that may help you. I dont have a link - perhaps the links in my Faster Spin Interpreter may have a link (see the tools link in my signature for an index)

jazzed

There are C, Python, and Spin/PASM source level solutions around for writing to propeller RAM/EEPROM. Maybe you could just adopt one of them?

The Propeller-GCC loader is open-source, multi-OS, fast, and reliable.