This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DLP products forum

Part Number: DLPC6401
Other Parts Discussed in Thread: SEGGER, DLPC350

Tool/software:

We’re having problems trying to boot the DLPC6401.  Several questions have come up while trying to troubleshoot the problem.

  • Where do I find a BSDL file for the DLPC6401?
  • What is the correct pull-down configuration on A21 and A22 for use with a 64Mbit flash?
  • Is the Macronix MX29LV640ETXEI-70G NOR flash supported by the DLPC6401?
  • What would prevent INIT_DONE from ever going high?
  • Where can I find v 2.0 of the DLPC6401 GUI?

Regarding (1), the datasheet says, “JTAG Boundary Scan Test Support”, but this requires the chain definition from a BSDL file.  We’ve successfully connected to the DLPC6401 via JTAG using a Segger J-Link and have been able to read the manufacturer & device ID with several programs (urjtag, openocd, TopJtag probe).  The manufacture & part ID read through JTAG match the DLPC350, but there are differences in the pinouts of the two parts, so I’m not sure if using the DLPC350’s BSDL is an option.

Regarding (2), the datasheet says, “the two most significant address bits (that is PM_ADDR_22 and PM_ADDR_21) are shared on pins GPIO_16 and GPIO_17 respectively”, and “if these GPIO pins are to be reconfigured as Program Memory Address pins, they require board-level pulldown resistors”.

Then there’s this table…

The reference design pulls down both PM_ADDR_21 and PM_ADDR_22.  Is the footnote just reaffirming that PM_ADDR_21 and PM_ADDR_22 are required to be pulled down, or does it indicate that GPIO_35 also needs to be pulled down for selection of the 64 Mbit part?  The reference design doesn’t help, as GPIO_35 and GPIO_36 are not connected to anything.

The datasheet says “until software reconfigures the pins from GPIO to Program Memory Address, upper portions of flash memory are not accessible”.  Is this handled by the bootloader? 

Regarding (3), in the post, “DLPC6401: Flash memory attached to the DLPC6401” by Alex Le in 2018, a response from Sanjeev says, “if the particular flash part is not supported by the controller then we cannot use it.”  The ref design uses a 32 Mbit NOR flash.  The schematic uses the Spansion/Cypress/Infineon S29JL032H and the BOM lists the S29GL032N90TFIR04, neither of which are still available.  We’ve selected the Macronix MX29LV640ETXEI-70G, a 64 Mbit NOR flash.  Will this part work?  Is there a list of parts somewhere that the controller supports?

The bootloader is the precompiled binary from the DPP6401_app_01.03.01_RVDS_3.1 archive we got from TI.  We had the flash preprogrammed with both the bootloader (DPP6401_APP_v1.3.1/dev/DPP6401/BootLoader/bootloader.bin) and the application (DPP6401_APP_v1.3.1/dev/app6401/app6401_data/flash_afe1000), but the device isn’t booting.  We suspect there may have been a problem with how the flash was programmed, so I attempted to use TI’s JTAGFlashProgrammer utility (DLPLCR4500JTAG_v1.0_WIN_2014_04_01.zip) to reprogram it.  We added an entry to the FlashDeviceParameters.txt file for the MX29LV640ET.  I tried to use the FTDI C232HM cable instead of the UM232H module.  I could see the JTAG traffic in a scope, but the TDO data read was inconsistent from read to read.  I've ordered the module so will try that when I get it.

Regarding (4), we’re primarily trying to determine if the processor is ever making it to the point to trying to read the flash, but it’s not clear what occurs within the controller prior to making INIT_DONE go high. We never see INIT_DONE go high.  The voltage rails are all good prior to PWRGOOD going high, and POSENSE goes high after PWRGOOD.

Regarding (5), there’s an August 13th post from Sanjeev in response to Alex Le’s question on Flash memory attached to the DLPC6401 in which he says, “Put the working flash on the board, then use the DLPC6401 GUI version - 2 and experiment with flashing the part.”  We’ve only been able to find version 1 of the GUI.