• Resolved

DLPC150: Development of PCB for basic operation of DLP2010NIR

Prodigy 50 points

Replies: 8

Views: 81

Part Number: DLPC150

Hello Everyone ,

This is my first time dealing with TI DLP Products . I am currently trying to build a PCB using DLPC150 and DLPA 2005 for DLP 2010NIR

My intention is to move all the micromirrors in a fixed postion and leave it at that . There isn't a need to control  the micromirrors . Hence , to achieve this I am building a PCB on KiCAD containing DLPC 150 and DLPA 2005 and a small PCB to hold DLP2010NIR.

I am building the circuit using DLP Ultra-mobile NIR Spectrometer for Portable Chemical Analysis with Bluetooth Connectivity (2514151E_NIRSCANNANO_DLPC150_Board_ESD) as a reference.I am facing a few roadblocks and have hence turned to the community , it would be great if someone here could assist me with these issues :

1. My intention is to use I2C using arduino + LabVIEW . For this purpose is it enough to have just DLP2010NIR , DLPC150 and DLPA 2005 with the necessary components and a header pin for connection to the I2C cables. Is there an alternative way to communicate with the DLPC 150 ?

2. The datasheet mentions the use of external parallel flash (pg 35 DLPC150 datasheet) . Can the system run without the use of DLPC150 configuration firmware and flash memory ? my application does not call for dynamic feedback and control . Would it be possible to just send the commands via I2C ? In the reference design is the configuration firmware loaded onto the Tiva Board ?

3. Alternatively , If I were to build the entire reference design would it be possible to just move the micromirror in a desired angle via the GUI  ?

  • Hello Srinivas,

    Welcome to the E2E forum!

    Let me address your questions in order.

    1. Is there an alternative way to communicate with the DLPC 150?

    I2C is going to be the only way to communicate with the DLPC 150 as it is the communication protocol the software has been built around.

    2. Can the system run without the use of DLPC150 configuration firmware and flash memory ? 

    The flash memory is necessary to hold the firmware, which in turn is crucial for the functionality of the controller as well as to interpret I2C. These both are needed for the system to run.

    3. If I were to build the entire reference design would it be possible to just move the micromirror in a desired angle via the GUI?

    This specific of control is not typical of the DLPC150 Gui and would be more accessible with a Light Control model from the DLP product line.

    Please let us know if you have any further questions.

    Regards,

    Austin

  • In reply to Austin Snyder:

    Hello Austin ,

    Thank you for welcoming me and for the quick help.

    On point 2 , I am planning to use I2C via LabVIEW (maybe switch to stm32 if it doesn't work) . If I load the configuration firmware directly on the flash memory it would be possible to send IC commands directly upon powerup of the DLPC150 and DLPA2005 right ?

    On Point 3 , I found DLP Discovery 4100 Explorer GUI . Were you referring to this ? We work with NIR and hence settled on DLP2010NIR.

    I switched my PCB design from KiCAD to Cadence OrCAD . Would it be okay to have all the connections and power supply on the top layer of the PCB (build a 1 layer PCB ) or should I opt for 3 layer design where I have separate power supply layer , ground layer and Signal layer (not very experienced with <2 layer PCB)

    An additional question concerning point 2 : Upon further reading the datasheet of DLPC150 (pg30 Table 8 and section 8.3.3) I understand that I have to hold RESETZ in low logic state inorder to program the flash memory . Assuming that I use W25Q40BWUXIG from Winbond how can I program the flash . i.e how does the loading process happen ? it would be great if you could point me towards any resources or provide your feedback on it . Apologies in advance if this question is beyond the scope of this forum. Alternatively , would it be an issue if I load the program via an external flash programmer (eg: https://www.embeddedcomputers.net/products/FlashcatUSB/) and then mount the flash chip ?

    Looking forward to your response ,

    Best,

    SP

  • In reply to Srinivas PRABHU:

    Hi SP,

    Point 2. Yes with valid firmware in the SPI flash, yes you should be able to communicate via I2C. Refer to DLPC150 controller datasheet power-up and power-down timings, typically soon after releasing the HOST_IRQ signal the controller is ready to receive the command.

    Point 3, Discovery explorer GUI is used for some other chipset, it cannot work for DLPC150NIR chipset.

    rest my colleague get back to you.

    Regards,

    Sanjeev 

    If a post answers your question, please click on "Verify Answer" button

  • In reply to Sanjeev:

    Hello Sanjeev ,

    Thank you for your reply . 

    Best,

    SP

  • In reply to Srinivas PRABHU:

    Hello Srinivas,

    I have included some procedures and pseudo-code that should help you with the flash upload below this message. Please keep in mind that these steps are meant for another EVM, but should serve the DLPC150 well.

    Please let us know if you have any further question.

    SPI Communication – SPI Write Procedure
    1. Install drivers and application for Cheetah. (Included with Cheetah purchase or downloaded from www.totalphase.com)
    2. Download the Flash Part file “winbond-spi-flash.xml” from TI.
    3. Copy “winbond-spi-flash.xml” to wherever parts .xml files are installed. This is typically in \parts sub-directory wherever the Flash GUI application resides.
    4. Connect Cheetah box to PC with USB cable
    5. Turn on power to EVM and turn Projector ON (i.e. SW_ONOFF). You should see default test image on screen.
    6. Connect Cheetah box cable to EVM header J6. Image on screen disappears as this holds the DPP343x in Reset.
    7. Run Cheetah “Flash GUI” application on PC.
    8. On Adaptor menu, click “Add Adapters” and if drivers are installed properly you can select SPI Adapter.TP1363-923331
    9. On the Adaptor section, click “Power Button” next to TP1363-923331 to turn power on the adaptor.
    10. On the Operations menu, click “Choose Target” and choose the manufacturer and part number. Bit rate should be limited to 4000 KHz.
    11. On the File menu, click “Load File” and browse to the location of the Flash Image. Choose the “Binary Files” in the “Files of Type” and you should see the image files with .img extension. Chose the .img file and click “Open”. This will load the data.
    12. On the Operations menu, click “Program + Verify”. Wait for the system to complete the process.
    13. Remove the Cheetah cable. You should see default image reappear on the screen. This means Flash has programmed properly and DPP343x has come out of Reset and is executing the new software.
    14. Verify the new software version is correct by reading system status via I2C command.

    I2C Communication
    Instead of communicating with the EEPROM device direct over SPI, it is possible to write to it indirectly by sending I2C commands to the controller. These I2C commands allow the user to use the controller as a SPI host, and encode the flash image in I2C instead of SPI. In this case, the controller serves as the SPI host (instead of a Cheetah or equivalent device) and allows the user to execute a flash write without needing to implement an external SPI interface.
    WARNING: This method will only work if a “working” flash image has been booted to the controller and the system is running. If the EEPROM flash device is empty, or contains incorrect firmware, then the controller cannot boot and thereby cannot execute these I2C-SPI commands.
    The following I2C commands are available for flash read/write operations (seen in DLPC343x Programmer’s Guide):
    Command I2C Opcode Read Short Status 0xD0 Read Update Pre-Check 0xDD Write Data Type 0xDE Write Data Length 0xDF Write Erase Flash 0xE0 Write Start Data 0xE1 Write Continue Data 0xE2 Read Start Data 0xE3 Read Continue Data 0xE4

    Pseudo-code for “Flash Download”:
    ReadUpdatePreCheck(imageSize) if( precheckReturnBytes != 0 ) { // Error, image is too big to write }

    WriteDataType(0) WriteDataLength(stepSize);

    while (sentBytes < image_size) { if (sentBytes == 0) WriteStartData(dataBytes[stepSize]) else WriteContinueData(dataBytes[stepSize])

    sentBytes += stepSize;

    // recommended to check flash download status periodically (every 4096 bytes) if ((sentBytes % 4096) == 0) { ReadShortStatus() // check status every so often, to make sure all's well if (statusCommunicationFailure = True) { // Error has occurred in Flash Download } }

    Delay(m_writedelay); }
    p-dollo@ti.com DPP343x EVM Flash Setup Guide July 23rd 2020
    // Success! System may now be rebooted with new flash image

    Pseudo-code for “Flash Read”:
    WriteDataType(0) WriteDataLength(stepSize);

    while (readBytes < image_size) { if (sentBytes == 0) dataBytes[stepSize] = ReadStartData() else dataBytes[stepSize] = ReadContinueData()

    readBytes += stepSize;

    // recommended to check flash download status periodically (every 4096 bytes) if ((readBytes % 4096) == 0) { ReadShortStatus() // check status every so often, to make sure all's well if (statusCommunicationFailure = True) { // Error has occurred in Flash Download } }

    Delay(m_writedelay); } // Success! System may now be rebooted with new flash image

    Kind Regards,

    Austin

  • In reply to Austin Snyder:

    Hello Austin ,

    Thank you for the detailed procedure , it has provided me with a good path to start with.

    A final question concerning the flash memory . Would it be okay if I program the flash memory using the programmer separately  and then solder the flash onto my board ? Would the DLPC150 controller work correctly if I follow this approach ? 

    Once again , thank you for all the assistance you have provided it's been of great help.

    Best,

    SP

  • In reply to Srinivas PRABHU:

    Hi Srinivas,

    Flashing the memory before soldering to the board should not be any problem. In fact, the firmware is typically flashed separately in the SPI Write Procedure. However, I would warn that soldering the flash in place may make it more difficult to re-flash in the future if any changes need to be made to the firmware.

    I am very glad to help! Thank you for using the forum.

    Regards,

    Austin

  • In reply to Austin Snyder:

    Hello Austin ,

    Perfect , I will keep your suggestion in mind . Thank you !

    Have a nice day ,

    Best ,

    SP.