DLPC3478: Pattern write block size issues for values smaller than 256 bytes per block.

Hi I'll have a DLPC3478 expert look into this and let you know.

Thanks

Hello Armin,

Thanks for reaching out through E2E about this!

It is curious that 128 bytes is giving an issue. According to Write Flash Data Length (DFh) and what you mentioned, the maximum data length allowed for each write transaction is 1024 bytes while the max read transaction is 256 bytes. Additionally, as mentioned is 3.7.3.1 the "flash data must be a multiple of four bytes." I'd think that means four bytes was the minimum.

Let me reach out to my team about this.

Are you following the instructions on the DLPC3470 and DLP3478 Software Programmer's Guide section 3.7 and changing the Flash Data Length and Flash Start commands?

Best,

Aaron

Hello Aaron,

yes, I follow the respective guides.

One remark about it though: Bit 4 of the response of the "Read short Status" command (D0h) is inverted compared to the documentation.

The same observation comes from looking at the code of the DLPC-API-1.10 reference project.

The general procedure for just the writing part is:

WriteFlashDataLength(128)

WriteFlashStart(first_128_bytes)



for every full chunk of 128 bytes:

   WriteFlashDataLength(128)

   WriteFlashContinue(next_128_byte)



WriteFlashDataLength(remainderChunkLength)

WriteFlashContinue(remainderBytes)

Regards

Armin

Hello Armin,

I'll have to look at the inversion of the 'Flash Erase Complete' bit 4 of D0h.

The steps within the User's Guide are as below:

1. Generate your pattern data using the DLP® Display and Light Control EVM GUI. The .bin file generated by the “Save Pattern Data” button in GUI contains the pattern data to be sent through I2C.
2. Ensure internal patterns are not currently running. If the controller is in internal pattern mode, use the Write Internal Pattern Control command (Section 3.4.13) to stop running internal patterns.
3. Set flash data type to pattern data block using Write Flash Data Type Select (DEh) command.
4. Check whether the generated .bin file can fit within the currently existing pattern data flash block using the Read Flash Update PreCheck (DDh) command.
5. Erase existing pattern data using Write Erase Flash Data (E0h) command.
6. Set flash data length to 1024 bytes using the Write Flash Data Length (DFh) command.
7. Write the first 1024 bytes of pattern data using Write Flash Start (E1h) command.
8. Write the remaining data in blocks of 1024 bytes using the Write Flash Continue (E2h) command.

The steps you've shown pick up with DFh (FlashDataLength) and E1h (WriteFlashStart) - steps #6 and #7. Were steps 3-5 also followed?

Could you share with me all the commands you're sending while you update from 256 to 128 bytes? This should include DEh (WriteFlashDataTypeSelect) and others in the steps 3-5 mentioned.

Best,

Aaron

// For reference: I count from 0, e.g. for bit numbers

WriteOperatingModeSelect([0x05, 0x04])
WriteInternalPatternControl([0x9E, 0x01, 0x00]) // Stop pattern sequence

WriteFlashDataTypeSelect([0xDE, 0xD0]) // Undocumented type D0, to be found in the DLPC API
ReadFlashUpdatePrecheck([0xDD, 0x44, 0x05]) // 1348 
Check response for bit 0 and bit 1 equal 0

WriteFlashDataTypeSelect([0xDE, 0xD0]) // Undocumented type D0, to be found in the DLPC API
WriteEraseFlashData([0xE0, 0xAA, 0xBB, 0xCC, 0xDD])

repeat ReadShortStatus([0xD0])
while response bit 3 is 1

WriteFlashDataLength([0xDF, 0x80, 00]) // 128
WriteFlashStart([0xE1, .. 128 bytes])
ReadShortStatus([0xD0])
check response for bit 4 equal 0 // Flash error?

for i=1 to 10
    WriteFlashDataLength([0xDF, 0x80, 00]) // 128
    WriteFlashContinue([0xE2, next .. 128 bytes])
    ReadShortStatus([0xD0])
    check response for bit 4 equal 0 // Flash error?

WriteFlashDataLength([0xDF, 0x44, 00]) // 68
WriteFlashContinue([0xE2, last 68 bytes])

That is the exact order of commands I send. All working fine for block sizes >=256 (and still dividable by 4 of course).

About read short status documentation error:

vs the DLPC API Code in dlpc34xx.h:256 ff

typedef enum
{
    DLPC34XX_FE_COMPLETE = 0x0,                                       /**< Complete */
    DLPC34XX_FE_NOT_COMPLETE = 0x1,                                   /**< Not Complete */
} DLPC34XX_FlashErase_e;

By the way. Not fixing the assumption of the flipped bit for `Flash erase not complete` makes code assume erase is already complete and following write commands can and will brick the firmware.

Regards,

Armin

Hello Armin,

When you perform this same task with 256, 512, 1024, and it is working does the last 'ReadShortStatus (D0h)' return a 0 or a 1 for bit 4?

Sorry, it took a while to understand the issue, thank you for pointing to the API code.

Best,

Aaron

Hello Aaron,

'ReadShortStatus (D0h)'  does not return "flash error" for any of such values and also not for e.g. a block size of 128.

Regards

Armin

Hey Armin,

Thanks for the additional info, I'm aligning with my team about this.

Best,

Aaron

Hello Aaron,

one additional remark. Even just modifying the DLPC-API example code to just use a write buffer of 128 bytes (thus using that as block size for all writes)

results in the same issues. The first block can be read back valid, the rest will be 0xFF. The read back code is also not wrong.

Additionally, also using the modified sample code results in a malfunctioning pattern firmware block.

Regards

Armin

Hello Armin,

Yes, I definitely need a member of my team to take a look at this, thank you for the additional information!

I'm still in discussion with them about this. Please give them a day or two to get back to this thread, thank you!

Best,

Aaron

Hello Armin,

Can you explain what is the reason for using block size less than 256 bytes?

Regards,
Kirthi Vignan

Hello Armin,

Thank you for letting us know.

Regards,
Kirthi Vignan.