• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 884 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

DLPC3470: DLPC3470 Not Booting

DLPC3470: DLPC3470 Not booting Part 2

Scott Grodevant
Intellectual 925 points
Part Number: DLPC3470
Other Parts Discussed in Thread: DLP2010

Hi Kyle,

As you pointed out, my flash data signals were flipped, so I corrected them.  As before, I toggled the PROJ_ON signal every few seconds and watched the SPI bus as the 3470 attempts to boot.  Since I never saw PROJ_IRQ drop (signaling the completion of booting), I probed the four SPI signals (CS, DI, DO and CLK) with a deep memory scope and downloaded the data into a PC.  I then wrote some software to process the collected data to convert the signals into SPI commands and data.

I see the 3470 issue a series of 4 fast read commands (0xb) followed by 24-bit addresses: 0, 0x1000, 0 and 0x2A0A0.  I collected the read data and discovered that there was an extra 0x00 byte proceeding what is correct data from the master file you sent me (dlpc347x_7.0.1.s37).  In other words, if I remove one bytes of 0x00 from the Flash ROM's output that I captured it matches the master file.  I've reviewed the SPI signals in this region to verify that the software isn't lying to me.  I figured this extra byte of zero is the cause of the 3470 not booting.  I can't explain why the zero is present.  The SPI signals look very good (nice 3.3V and 0V levels).

I removed the Flash chip and replaced it with another I'd programmed from the master file.  I also downloaded the content of the removed Flash ROM and compared it to the master.  It was an exact match except of course for the unprogrammed locations (e.g. the master file doesn't contain all 32 MB of data).  The data was perfectly intact.

With the Flash ROM replaced on the board, I see the chip select signal looks the same as it did with the original Flash ROM and IRQ never drops signaling the end of booting.  I have verified that IRQ isn't shorted because I can toggle it as an output from the CX3 (mipi controller) to which it is attached.

We have a second set of boards I will modify and try.

Thanks for your help,

Scott

  • 0
    TI__Mastermind 22830 points
    Hi Scott,
    Thank you for the update and let us know your findings after you have modified second board.
    regards,
    Vivek
  • 0 in reply to Vivek Thakur
    Intellectual 925 points
    Hi Vivek,

    I've modified a second board and captured a new set of I2C data. It is identical to the first board.

    Looking at it today, I finally understand where the extra byte of zeros comes from: the fast read command (0xB) requires an extra byte clocked out before it begins outputting data (according to the Winbond W25Q32 data sheet). I've modified my software to take this into account.

    But still, comparing the read back data with the master file is confusing. As I mentioned in the original post, the 3470 reads a couple of "blocks" twice. The 1st of these blocks is 0-0x20 and the second is 0x1000-0x2a09f. The data read from Flash changes between the first and second block reads. The first time the read data matches the master file, the second time it does not. I am going to examine the timing signals during the second read to see I can explain the difference.

    I'll keep you updated.

    Thanks for your help,
    Scott
  • 0 in reply to Scott Grodevant
    Intellectual 925 points

    Hi Vivek,

    I spent the day yesterday cleaning up my analysis software and now believe it's telling me the correct but confusing story.

    What I see happen on both boards when the 3470 boots is this.  The 3470 reads, at 1.4 MHz, 33 bytes from address 0 through 0x20.  This is the initial 25 ms CS (active low) pulse shown above.  At the end of this read, it switches its clock from 1.4 MHz to 30 MHz that it uses for all the remaining reading.  It then proceeds to read 2255 more blocks using a 30 MHz clock.  Above I've shown a scope trace of the Flash ROM's -CS signal at 5 ms/cm and 2V/cm.  The largest is from address 0x1000 for 89810 bytes then a series of 1-byte blocks starting from 0 through 0x97.  It then jumps to 0x17004 then 0x1A004 and various other addresses up to 0x2B280 where it reads the final 274 bytes.  I have all this data in various forms if it is of use to you to resolve this issue.

    Every byte read (or re-read in the case of address 0) matches the master file Kyle sent me dlpc347x_7.0.1.s37.  After all the SPI activity ceases after a little over 30 ms, the PROJ_IRQ signal remains high and attempts to access the 3470's I2C register at 0x36 are not acknowledged.

    I'm at a dead-end here with two boards behaving exactly the same and appreciate any insights you have.

    Thanks,

    Scott

  • 0 in reply to Scott Grodevant
    Intellectual 925 points
    One additional data point. I tried loading the default projector firmware dlp2010evm-lc_7.0.1.img into flash and booting from that. PROJ_IRQ remains high at the end of the boot sequence. I captured SPI signal traces and analyzed them with my software. The boot sequence using this firmware is identical to the custom firmware meaning the locations and block sizes the 3470 reads on boot are the same. The collected data is of course different (since the code isn't the same).

    Scott
  • 0 in reply to Scott Grodevant
    TI__Mastermind 20045 points

    Hello Scott,

    The image ended up not coming through. Thank you for all of the other information though. Can you confirm that both the DMD and LEDs are connected. Could you also confirm the proper power-up signals are observed as shown on this attached startup sample diagram?

    Thanks,

    Kyle

    Startup_DLPC3470.pdf

  • 0 in reply to Kyle Rakos
    Intellectual 925 points
    Hi Kyle,
    I tried attaching the DMD on the outside change it matters for the 3470 to boot. I didn't see any difference.

    I also verified the timing diagram signals, all are OK (except of course PROJ_IRQ doesn't drop to a low level at the end of initialization).

    Thanks,
    Scott
  • 0 in reply to Scott Grodevant
    Intellectual 925 points

    Hi All,

    What's happening on this?  I'm more or less dead in the water here until I can communicate with the 3470.

    Thanks,

    Scott

  • 0 in reply to Scott Grodevant
    TI__Mastermind 20045 points
    Hi Scott,

    Sorry you are still having these issues. Could you confirm you are using the DMD pin mapping option 3 (as shown in the DLP2010 datasheet)?

    Thanks,
    Kyle
  • 0 in reply to Kyle Rakos
    Intellectual 925 points
    Hi Kyle,

    I am using DMD pin mapping option 4 (swap control 0x3) using data lanes A, B, G & H. But of course, the issue is more complicated than that!

    I have two designs. An "A" version that has pins G3 & G4 on the DMD swapped, otherwise it is wired as option 4. Our "B" design corrects that error and correctly conforms to option 4 wiring. We have not yet ordered any of these boards.

    Is it possible that this route flipping would cause the controller not to start? It seems unlikely, but nonetheless possible.

    Thanks,
    Scott
  • 0 in reply to Scott Grodevant
    TI__Mastermind 20045 points
    Hi Scott,

    It is possible this is an issue; however, it's unlikely. I know we are following up offline so I will mark this question resolved for now.

    Thanks,
    Kyle