Protocol Proper

Protocol Proper is the pure form of the protocol designed for communication over simple direct-connect digital circuitry. The Spin object PropellerLoader.spin implements Protocol Proper between one Propeller (acting as the host) and another Propeller (the one being programmed). Developers knowledgeable in Spin can gain insight into Protocol Proper by reading this code example; see Appendix B - PropellerLoader.spin.

Metrics

• Reset Pulse - Drive low > 10 μs, then release (hi-z)
• Post-Reset Delay - 60 ms to 210 ms (90 ms to 100 ms is recommended)
• Data Bit Order - LSB-First
• Low Pulse (t) - Represents bit value 1
• Low Pulse (2t) - Represents bit value 0
• Low Pulse (t) Width - 4.3 μs to 26 μs (recommend ≅ 8.6 μs)
• High Pulse Width - 4.3 μs to 90 ms (recommend ≥ t μs)
• Delay Between Bytes - ≤ 90 ms

Protocol Proper Algorithm

The following describes the steps for Protocol Proper from the perspective of the host. The images afterwards contain additional vital information using actual annotated examples.

When implementing this protocol from scratch, try attempting only an identification operation (the first half of the algorithm) then the final steps (in the second half) will generally be easier to implement.

• Reset the Propeller [Image P1, Image P2]
  • Drive RESn low > 10 μs, set Tx high / Rx input, then release RESn (hi-z)
• Wait for Post-Reset Delay [Image P1, Image P2]
  • 90 to 100 ms recommended
• Transmit Calibration Pulses [Image P3]
  • 2-bits (%01) LSB-First
• Transmit Handshake Pattern [Image P4]
  • 250-bits; see Appendix A - Handshake and Connection
• Receive Connection Response [Image P5]
  • 250 iterations of: transmit 2-bit Calibration Pulse, receive 1-bit Connection Response Bit; see Appendix A
  • If Propeller does not respond to any Calibration Pulse pair, or Connection Response bit is invalid, abort communication; connection error
• Receive Version [Image P6]
  • 8 iterations of: transmit 2-bit Calibration Pulse, receive 1-bit Version Pulse
  • If Propeller does not respond to any Calibration Pulse pair, or if Version is bad, transmit Shutdown Command, abort communication; version error
  • Valid Propeller Version = 1 (8-bit value, received LSB-first)
• Transmit Command [Image P7, Image P8 - Image P9]
  • 32-bits; often Shutdown (ID only), LoadRun (RAM only) or ProgramRun (RAM & EEPROM); see Table G1
  • If transmitted Command is Shutdown (aka Identify), success; terminate communication
• Transmit Size of Application in longs [Image P9]
  • 32-bits; this value should come from word 9:8 of the application image, shifted right by 2 bits
• Transmit Application Image [Image P10]
  • Stream of 8-bit bytes
• Wait for Acknowledge (RAM Checksum) [Image P11]
  • Up to 250 ms of: transmit 2-bit Calibration Pulse, check for 1-bit Ack (0) or Nak (1)
  • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; transmission error or RAM verify error, respectively
• If Command is LoadRun [Image P11]
  • Success; terminate communication
• Else, Command is ProgramShutdown or ProgramRun [Image P12]
  • Wait for EEPROM Program [Image P13]
    • Up to 5 s of: transmit 2-bit Calibration Pulse, check for 1-bit Ack (0) or Nak (1)
    • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; EEPROM program error
  • Wait for EEPROM Verify [Image P13]
    • Up to 2 s of: transmit 2-bit Calibration Pulse, check for 1-bit Ack (0) or Nak (1))
    • If no response before timeout or Negative Acknowledge (Nak) received, abort communication; EEPROM verify error
  • Success; terminate communication

The following images are actual logic analyzer captures of Protocol Proper. The example system consists of a “host” Propeller, running PropellerLoader.spin, that is connected to a Propeller to-be-programmed.

Identification Sequence

The first set of images demonstrates the identification process (Reset through Command) which covers the first half of the Propeller Proper Algorithm.

Image P1 - Full Identification Sequence

This image shows a full identification sequence with Protocol Proper. Driven signals rest high; Host Rx isn’t driven by the Propeller until it recognizes the host. Note the approximate 100 ms post-reset delay (after Reset’s low pulse) before host transmission begins (Host Tx). The following are zoomed-in views of this image.

Image P2 - Reset Pulse

The Host-driven Reset Pulse (when connected to the Propeller’s RESn pin) causes the Propeller to stop any activity and perform a boot sequence. The Reset Pulse is shown here followed by an approximate 100 ms delay before Host Tx communication begins. The Host Tx signal (connected to the Propeller’s Rx pin) must “rest” high before the Propeller wakes up on the rising edge of the Reset signal.

Image P3 - Calibration Pulses

Approximately 100 ms after the rising edge of the Reset Pulse, Host Tx communication begins with Calibration Pulses. This is the host’s way of saying, “This is how I talk.” The 2-bit calibration sequence consists of a low pulse (of width t), a spacer (high) pulse, and a second low pulse (of width 2t) followed by a spacer (high).

Image P4 - Handshake Pattern

The Handshake pattern (the host-transmitted pattern of 250 bits) immediately follows the Calibration Pulses. This is the host’s way of saying, “I’m a qualified Propeller host trying to speak to a Propeller.” Pulse widths of the 250-bit pattern closely match the timing indicated by the Calibration Pulses. The contents of this pattern is described in Appendix A.

Image P5 - Connection Response

The Connection Response (a Propeller-transmitted pattern of 250 bits) occurs right after the Handshake. It is the Propeller’s way of saying, “I’m a Propeller that hears and acknowledges the qualifications of the host.” After the last bit of the Handshake, the Propeller transmits one bit of the Connection Response for each Calibration Pulse pair it receives from the host. The host transmits 250 Calibration Pulse pairs in order to receive all Connection Response bits. The host always samples the Propeller’s transmission (Host Rx) during and right after each leading Calibration Pulse bit; the first sample is always 0 if the Propeller responded at all and the second sample is 0 or 1, the actual bit value of the Connection bit. NOTE: The Propeller doesn’t set its Tx line (connected to Host Rx) to output (resting high) until after the last correct Handshake pattern bit is received. The contents of this Connection Response pattern is described in Appendix A.

Image P6 - Version

The Version is an 8-bit value transmitted by the Propeller immediately after the Connection Response; 1 bit (LSB-first) for every Calibration Pulse pair the host transmits.

Image P7 - Command (Shutdown)

After Version is received, the host transmits the Command (the intent of the communication); in this case, Shutdown, aka Identify. The Command is a 32-bit value (LSB-first). If the Command were other than Shutdown, communication would continue as shown in the images below.

Program RAM Sequence

The next set of images expands on the sequence shown above by demonstrating a Program RAM sequence, where the LoadRun command is used and an actual Propeller Application is transmitted. All communication prior to the LoadRun command is exactly the same as before.

Image P8 - Full Program RAM Sequence

This is an entire Program RAM sequence with Protocol Proper (LoadRun Command). The leading signals, up until the LoadRun command is transmitted, is exactly the same as in the Identification sequence shown in prior images. The following are zoomed-in views of this image.

Image P9 - Command (LoadRun) and Application Size

After Version is received, the host transmits the LoadRun command followed by the Application Size. Each are 32-bit values transmitted LSB-first. The actual Propeller Application image is expected to follow.

Image P10 - Application Image

After the Application Size is transmitted, the host transmits each byte of the Application Image. Each 8-bit value is transmitted LSB-first. The small Propeller Application used in this example consists of 44 bytes, transmitted using the same low-pulse method as before: 00 B4 C4 04 6F CB 10 00 2C 00 34 00 18 00 38 00 1C 00 02 00 08 00 00 00 37 03 3D D6 1C 37 03 3D D4 47 35 C0 3F 91 EC 23 04 73 32 00. You can use this same application data during protocol development; when successfully downloaded, it will make the Propeller toggle I/O pin P16 high or low every second (assuming the Propeller has a 5 MHz crystal connected).

Image P11 - Acknowledge (RAM Checksum)

After the last bytes of the Application Image are transmitted, the host polls for a RAM Checksum Acknowledgement by periodically transmitting Calibration Pulses and checking for a Propeller response. Polling may continue for up to about 270 ms with delays between polls of ≥ 10 ms and ≤ 45 ms recommended. The Propeller is ready to respond from about 52 ms to 263 ms after the last byte is transmitted, dependant on process, voltage, and temperature variances. The Propeller responds with an Ack (0) if the received Application Image has been verified in RAM (via RAM Checksum) or with a Nak (1) if RAM verification failed. If Ack is received and the Command is LoadRun (as in this example), this is the end of the download process. If Ack is received and the Command is ProgramRun or ProgramShutdown, communication continues as in the following images.

Program EEPROM Sequence

The final set of Protocol Proper images, below, expands on the previous by demonstrating a Program EEPROM sequence, where the ProgramRun command is used instead. All communication is exactly like above except the Command is ProgramRun and two more polling sequences occur after the positive Acknowledge (RAM Checksum) is received.

Image P12 - Full Program EEPROM Sequence

This is an entire Program EEPROM sequence with Protocol Proper (ProgramRun Command). Communication is exactly like in previous images, except for the ProgramRun command and the extra polling sequences. The following is a zoomed-in view of this image.

Image P13 - EEPROM Program and Checksum Acknowledge

Assuming the Command is ProgramRun or ProgramShutdown, after the Propeller acknowledges the RAM Checksum, it immediately starts the EEPROM programming and verification processes. The host polls for an EEPROM Program Acknowledgement by periodically transmitting Calibration Pulses and checking for a Propeller response. Polling may continue for up to 5 s with delays between polls of > 10 ms and < 100 ms recommended. The Propeller responds with an Ack (0) if EEPROM Programming is done, or with a Nak (1) if EEPROM programming failed. If Ack is received, the host once again polls (this time for EEPROM checksum verification) similar to before, but only for up to 2 s. Once a final Ack is received, that marks the end of the download process. NOTE: If the Command is ProgramShutdown, the Propeller terminates the connection swiftly after final acknowledgement, rather than launching the Spin Interpreter and application.