https://e2e.ti.com/support/dlp-products-group/dlp/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1636590/dlpnirnanoevm-dlpnirscan-nano-dlpspec_scan_interpret-returns-rc--4-not-a-valid-tpl-file-on-linux/6413192Mon, 13 Jul 2026 01:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:01b8bdb9-4f52-4992-83ee-66aea3942a95Shiva ReddyThanks for the quick response, Aaron. To clarify exactly what &quot;the issue&quot; is : it&#39;s not a later scan failing — it&#39;s the NNO_CMD_SCAN_CFG_APPLY command&#39;s own USB HID reply. Every reply&#39;s first byte is a flags byte where bits 5:4 encode 00=Success, 01=Error, 10=Busy . Every time we send CFG_APPLY , we get 0x50 back immediately — bits 5:4 = 01 (Error), zero bytes of response data — as the direct reply to that single command. We never see 10=Busy . So we never get as far as attempting a scan; the config-apply step itself is rejected on the spot. We tested your status-check suggestion directly : we now poll NNO_CMD_READ_DEVICE_STATUS (cmd 0x03 , group 0x04 ) before and after every step in our sequence ( CFG_ERASEALL → CFG_SAVE → SET_ACT_CFG → CFG_APPLY ), rather than relying on a fixed delay. It consistently returns 0x05 (Tiva Active + SD Card Present, no busy bits) at every single point — including immediately before and after the CFG_APPLY failure. So the device isn&#39;t reporting itself busy or mid-operation when we send it. New finding since our first post — we also checked NNO_CMD_READ_ERROR_STATUS (cmd 0x04 , group 0x04 ) Immediately after a CFG_APPLY failure, which we hadn&#39;t tried before. It returns: error bitmask = 0x00000020 -&gt; Spectrum Library Error This is a much more specific signal than the generic Error flag. Per the firmware source ( cmdProc.c , cmdSetConfig_wr() ), only the branch where dlpspec_scan_read_configuration() itself fails calls nnoStatus_setErrorStatusAndCode(NNO_ERROR_SPEC_LIB, ...) — the downstream Scan_SetConfig() Validation failures (pattern count, repeat count, Hadamard geometry) do not set this specific bit. So this points at the deserialization step itself failing on the firmware , before scan-config validation even runs. That&#39;s puzzling given what we&#39;ve verified: our payload is a byte-for-byte match (aside from the auto-incrementing scanConfigIndex ) to a capture we independently confirmed succeeded three times in a real Windows GUI session. If the same firmware function is parsing byte-identical data, we wouldn&#39;t expect it to fail for us but succeed for the GUI. One thing we noticed while tracing the GUI source ( API.cpp / NNOCommandDefs.h ) that may be relevant here: the wire length for CFG_APPLY / CFG_SAVE is a fixed constant ( sizeof(scanConfig)*2 = 124 bytes / *2+2 = 126 bytes) left over from the flat Column/Hadamard scanConfig struct, not sized for the actual ~155-byte slewScanConfig Serialization of our Slew-type config needs — so the GUI always truncates the real serialized buffer down to this fixed length before sending, for every Slew scan config, not just ours. On the firmware side, cmdSetConfig_wr() in turn calls dlpspec_scan_read_configuration(pBuf, bufSize) with a fixed bufSize = sizeof(scanConfig)*4 (248 bytes) — not the number of bytes actually received over USB. Given both of those are fixed, oversized constants rather than the true transmitted length, our working theory is that the parser ends up reading past the genuinely received 124 bytes into whatever was previously sitting in that static receive buffer, to satisfy the section array&#39;s own internally declared (but not fully transmitted) length. If that leftover buffer content happens to differ between sessions — ours has been through a large number of CFG_SAVE / CFG_APPLY cycles during this investigation — that could plausibly tip an otherwise-identical payload from parsing successfully to failing. Could you confirm or rule out: Is this truncation ( sizeof(scanConfig)*2 used as the wire length for a slewScanConfig payload) expected/intentional, or a known gap in the GUI/firmware interaction for Slew-type scans specifically? Does dlpspec_scan_read_configuration() &#39;s handling of the two-part (head + section array) TPL structure tolerate a section array that&#39;s shorter than its own internally declared length, or does it require the full declared length to be genuinely present in the buffer? Is the firmware&#39;s receive buffer for this command guaranteed to be cleared/zeroed before each transmission, or could its content depend on what a prior command left there? Happy to share the exact byte sequences (captured working payload vs. ours) and our full error-status dump if that&#39;s useful for someone on your side to reproduce. Really appreciate you looking into this. Regards Shiva Reddyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663355/tpsm863257-non-china-products-xxxxxxx-a/6413142Sun, 12 Jul 2026 16:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eededa4b-2d80-4536-8d4a-8e57bb691f39Alla UshasriHi Guela, Can you refer to which thread your saying about? Regards, Usha.https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1663355/tpsm863257-non-china-products-xxxxxxx-aSun, 12 Jul 2026 07:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e4f483d9-280a-411c-a0c4-a73db9541f8cGeula PinchasPart Number: TPSM863257 hi, on cause CS3437614 we received your answer: I understand you are mentioning the MPN was made in China, and upon checking I see that the the assembly location is China however the Fabrication location is in the US. Therefore suffix of .A means the the chip origin is not China. I would like to know if this answer is for all NON CHINA pn&#39;s? and not specific for item TPSM863257RDXR.A thank you GeulaTPSM863257https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1645507/dlpnirnanoevm-dlpc150-program-issue/6411951Fri, 10 Jul 2026 05:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ee7352f3-d341-40c2-921e-e320755815a4chenglqHow&#39;s the progress going?https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1660469/dlpnirnanoevm-dlpnirnanoevm-software-issue/6411940Fri, 10 Jul 2026 05:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8ab5ee2f-843d-4c7c-9951-662f19eb2068chenglqHow&#39;s the progress going?https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661372/dlplcr99uvevm-the-evm-board-has-no-v-bias-18v-voltage-output/6411817Fri, 10 Jul 2026 03:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3feafd48-5d68-47da-a1ef-f5d2dc0e60darichard parkHi Tilden Thank you for your reply I neans Power-up instruction 1,2,3,4, are OK. and 5. 12V power (D1), DLPC964 Power Good (D2), and DMD Power Good (D3) LEDs illuminate indicating that power is present on the DLPLCRC964EVM and DLPLCR99EVM / DLPLCR99UVEVM boards. My Answer =&gt; D1, D2 are OK,, D3 is not OK.( I think it&#39;s because of the Vbias problem of DMD Mirror Board) The DMD Power Good( D3) LED is not OK Now. the Power_en Signal is High for DMD Mirror Board. Please let me now what caused it. Regards Richard Parkhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1657965/dlpc4430-questions-related-to-overlap-on-dlpc4430-led-project/6411772Fri, 10 Jul 2026 01:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:669a40c1-68b2-41fc-b278-09fa51efe4d5Wayne CheungHello Hosiah: Yes, I downloaded this reference project from the Pass you mentioned. I&#39;ll attach the revelant pictures as follows for confirmation. Thank you for your corresponding and concerning. BRshttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6411769Fri, 10 Jul 2026 01:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4832960b-d138-42b6-ae4b-32fd3f5a3cdbjim liuDear Michael, Thank you very much for your prompt reply and for reaching out to your systems engineer on our behalf. I truly appreciate the effort you’re making to check what information can be shared. We fully understand the need to protect proprietary details, and we are more than willing to sign an NDA if that is the required path to obtain the detailed algorithm description and implementation guidelines. Our SoC has ample CPU/GPU headroom, and removing the external FPGA would significantly simplify our BOM and board layout, so we are very keen to make this work. In the meantime, could you please let us know: Whether there is a specific NDA process we should initiate now to speed things up? Again, thank you for your support. We look forward to your further guidance. Best regards, Jim Liuhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1660988/dlpc964-what-is-the-high-output-conditions-for-the-init_done-pin-f23-of-dlpc964zum/6411742Fri, 10 Jul 2026 00:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b11ead39-e37b-463f-9b9c-6b49d965362arichard parkHi Tilden Thank you for your reply I means that If the DONE signal(PIN AB10) is low, then the DLPC964 is not loading the configuration file. My question is (attached photo 2) I want to know the output condition of the init_done signal output from DLPC964(PIN FS23). please let me know that Regards Richard Parkhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1660988/dlpc964-what-is-the-high-output-conditions-for-the-init_done-pin-f23-of-dlpc964zum/6411658Thu, 09 Jul 2026 22:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6412c1d5-9148-4074-aedb-d8ae49dcbf28Tilden ChenHi Richard, Sorry, I am not sure I understand your question. If the INIT_DONE signal is low, then the DLPC964 is not loading the configuration file.https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661372/dlplcr99uvevm-the-evm-board-has-no-v-bias-18v-voltage-output/6411656Thu, 09 Jul 2026 22:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:73e0818e-717c-4fa1-ae45-e38be9f5a55eTilden ChenHi Richard, Thanks for your reply. Normally it is difficult to break the DMD device. Would you please confirm that you also followed step 1 with SW1 in OFF position to park DMD and waited for DS1 and DS10 to illuminate before applying power?https://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1655614/dlpc3479-the-internal-mode-display-of-dlp4710-dlpc3479_dual-is-abnormal/6411639Thu, 09 Jul 2026 22:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4035e89a-cf26-4c99-abda-d6b3c9a2ab65Aaron BlackHello Zhihao, Yes, unfortunately this does explain why the secondary ASIC is in a state of &#39;waiting&#39; for the primary ASIC. Please keep us updated if there are other issues - my team member is also available for contact as I&#39;ve shared offline. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662678/dlpc900-pixel-interface-of-dlpc900/6411571Thu, 09 Jul 2026 21:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ffa36bbc-9714-41cc-a52c-2322a8a9fef0Aaron BlackHello Mohammad, Thank you for coming to E2E with your question! The DLPC900 only utilizes a Parallel Port interface from a front-end. On our controller EVMs, i.e. DLPLCRC900EVM or DLPLCRC900 D EVM, we utilize an IT6535 chip that converts from HDMI or DisplayPort out to Parallel Port. In a dual controller configuration on the DLPLCRC900 D EVM, we utilize an FPGA to bifurcate the data into left and right data to a primary and secondary ASIC - enabling higher data rates to higher resolution DMDs. Data that is sent to the DLPC900 has to exist in the volatile memory of the controller, excluding the case of Pre-Stored Pattern Mode. Video Mode utilizes a frame buffer as well as Video Pattern Mode and Pattern On-the-fly depends on USB/I2C programming directly to internal memory (max of 128MB). I hope this helps! Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1659063/dlplcr65evm-dlp-lightcrafter-6500-video-pattern-mode-unexpected-photodiode-signal-dips-in-255-greyscale-during-16-5-ms-rgb-frame-window/6411557Thu, 09 Jul 2026 21:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2311fe39-6cb5-4b0f-af26-df2e9b66d368Aaron BlackHello Dorrin, Since it&#39;s a laser, you&#39;re likely using it in a continuous mode, but you could be pulsing the laser which could cause these dips as well. Are these wider dips always the same period or match with the amount of time your patterns are being displayed for? Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1658628/dlp670s-dlp6750q1evm-mirror-bias-voltage-changes-have-no-effect-on-mirror-displacement/6411551Thu, 09 Jul 2026 20:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0571c249-aa5f-4949-a980-8e26f341c90fAaron BlackHello Nathan, Thank you for the additional information. 10V is expected for pin 3 of J5 as this is the voltage necessary for the PLM mirrors to move. No, there is no fail-safe here for these pre-release devices, this is why we advise customers firstly to ensure that Mirror Bias is on before powering on the device. We recommend an external power supply even so the mirrors always are safe. Additionally, I&#39;ve operated with voltage limited power supplies as well, instead of current limited. Best, Aaronhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662537/dlpc3478-firmware-layout-of-patterns-records/6411538Thu, 09 Jul 2026 20:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7b6897f0-66f9-4895-8e0b-8b628639cf68Michael LyHi Mark, Very cool! I just did a cursory search on TI&#39;s site, but has your team looked into the API? I assume that the user&#39;s guide only mentioned the GUI as primary software evaluation resource. I hope the API in the link below is helpful--I haven&#39;t downloaded it to view, but it looks like a starting point for what you&#39;re asking for if not the datasheet of the DMD controller. https://www.ti.com/product/DLPC3478#software-development https://www.ti.com/lit/ds/symlink/dlpc3478.pdf?ts=1783629411406&amp;ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDLPC3478 Seems you may need to consult the API and then the datasheet for which function to call and which parameters to provide the functions, though! Regards, Michael Lyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662537/dlpc3478-firmware-layout-of-patterns-records/6411528Thu, 09 Jul 2026 20:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f2fa8b77-a36b-4ea8-9e74-37addfe10a73Mark HanninenHi Michael, Thank you for the fast response! We have, in fact, bought a few EVMs and are happy with them so far! We have been developing core functionality on them in parallel with design of new PCB. We&#39;re confident that the functionality will port well into the new board, but just require the firmware layout to manually write patterns/records at runtime. Thanks again, Markhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1661352/dlp3940s-q1-quincunx-algorithm-details-for-soc-cpu-gpu-implementation-dlp3940s-q1-dlpc231s-q1/6411510Thu, 09 Jul 2026 20:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d2556648-a61f-4d31-ab6c-f44aa088cd71Michael LyHi Jim, I&#39;ve reached out to our systems engineer to see what they have to say. We&#39;d like to share with you what we can, but I want to check how much we can share. Thanks for your patience, Michael Lyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662537/dlpc3478-firmware-layout-of-patterns-records/6411503Thu, 09 Jul 2026 20:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d9d045b0-f0bb-4261-bfef-3b797bea9d17Michael LyHi Mark, Thanks for reaching out. I&#39;ve assigned this to a colleague who can help answer your questions. Please give an additional business day for them to answer. While we wait, may you let us know if you&#39;ve taken a look into the EVM for this chipset to perform initial evaluation? This is a useful first step if you&#39;re able to afford the time and money spent on this phase. If you already are well-into the design, this may not be a necessary step, but it does give a good POC to fall back on. Thank you and regards, Michael Lyhttps://e2e.ti.com/support/dlp-products-group/dlp/f/dlp-products-forum/1662678/dlpc900-pixel-interface-of-dlpc900/6411497Thu, 09 Jul 2026 20:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f96b86b0-7c2f-4c6d-aa76-429097edeca0Michael LyHi Mohammad, I&#39;ve assigned this to a colleague, but as an initial response, do you mind letting us know what you plan on using DLPC900 for, or are you looking for options to evaluate a certain application space and weighing in on what best suits your needs? Regards, Michael Ly