DLPU110B April   2021  – August 2022 DLPC6540

 

  1.   Programmer's Guide
  2.   Trademarks
  3. Scope
  4. References
  5. Acronyms
  6. System Boot
    1. 4.1 Data In flash
    2. 4.2 Bootloader Application
    3. 4.3 Main Application
    4. 4.4 Commands supported by Bootloader and Main Applications
    5. 4.5 Debug Terminal
    6. 4.6 HOST_IRQ/SYSTEM_BUSY
    7. 4.7 Heartbeat
    8. 4.8 Low-level Fault
  7. System Status
  8. Version
  9. Power Modes
  10. Display Modes
  11. Source Detection and Configuration
  12. 10Internal sources
    1. 10.1 Test Patterns (TPG)
    2. 10.2 Solid Field (SFG) Color
    3. 10.3 Curtain
  13. 11Display Formatting
  14. 12Image Processing
  15. 13Illumination Control
  16. 14Peripherals
    1. 14.1 GPIO
  17. 15Interface Protocol
    1. 15.1 Supported Interfaces
    2. 15.2 I2C Target
    3. 15.3 USB
  18. 16Command Protocol
    1. 16.1 Command Packet
    2. 16.2 Response Packet
    3. 16.3 Destination Details
    4. 16.4 Error Handling and Recovery
    5. 16.5 System Busy - I2C scenarios
      1. 16.5.1 GPIO implementation
      2. 16.5.2 Short Status response
    6. 16.6 Support for Variable Data Size
  19. 17Auto-Initilization Batch File
  20. 18Command Descriptions
  21. 19 System Commands
    1. 19.1  3D
    2. 19.2  Administrative
    3. 19.3  Autolock
    4. 19.4  Blending
    5. 19.5  Bootloader
    6. 19.6  Calibration
    7. 19.7  Debug Internal
    8. 19.8  Debug
    9. 19.9  General Operation
    10. 19.10 Illumination
    11. 19.11 Image Processing
    12. 19.12 Peripherals
    13. 19.13 Warping
    14. 19.14 Manual WPC
  22. 20Revision History

Error Handling and Recovery

As all physical interfaces support the same protocol, it is difficult to support the start conditions that each interface supports. Also, depending on payload size, a command packet may be sent over multiple packets.

It is also important for the DLP Controller to know the start of a command to be able to parse and execute the command successfully. This means the host and DLP Controller should always be in sync. This will be the case if both host and DLP controller gets reset and powers on together. However, if an error occurs in either side, or if one of host/DLP Controller asynchronously resets then the sync is lost. Since the start conditions specific to physical interfaces are not monitored, we need another mechanism to recover when such an error occurs.

To support this use case, the DLP Controller monitors the time of arrival of each group of bytes. If any group of bytes come outside of a defined timeout (750 ms) compared to the last group, it is treated as the start of a new command.

The timeout is always measured from the last received group of byte and not from the group of byte where it encountered an error. This means, if the host keeps sending command one after the other without a timeout, all of it will be discarded.

It is valid to include multiple commands in a single group, or send commands back to back without waiting for the defined timeout. Both of these cases are controlled by the command handler which execute all such chained commands in the order they are received.