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.

UCD90160A: NACK when sending RESET_COUNT command

Part Number: UCD90160A

Tool/software:

Hello,

sometimes when requesting a read to the RESET_COUNT (0xDC) register on a UCD90160A device, we get a NACK (we do it during the software init stage).

The command reference manual SLVU352G has a footnote (1) for the command "STORE_DEFAULT_ALL" that states "There is a chance that a write to this command will receive a NACK..." 

- Does this also apply for the RESET_COUNT instruction? That instruction doesn't seem to have a footnote, but there is a suspicious "(1)" text in the Transaction type, Data format and Comments with no further explanation. 

- Can a read to MFR_REVISION (0x9B) trigger a flash update? We read it just before the RESET_COUNT. Maybe swapping the two instructions would get rid of the nack? 

Thanks

  • Hi

    RESET_COUNT is a write/read word command. Please follow below protocol

    reading MFR_REVISION shall have not impact on RESET_COUNT

    Regards

    Yihe

  • Hello,

    yes that is what we are doing,

    however the nack happens when writing the address for the write, the power sequencer also does a clock stretching that lasts 34 ms

    P.S. In this capture you can see the clock stretching that the power sequencer is doing during the read of the MFR_REVISION, those 5 bytes are the lasts of a 12 bytes read.

  • This is the logic trace, in case you can open it, so you can have a full picture of what is happeningLogicTrace.zip

  • Hi

    Thank you for the log. I can see what the problem is. 

    MFR_REVISION is a block read command. if host is trying to read more bytes than it is supposed to be, there will be a timeout event since UCD does not have more data to transfer. and after timeout. Host shall stop the transaction immediately instead of continuing on the existing transaction. 

    The following correction is required on your software side
    1. for the MFR_REVISIOIN, please only read the required bytes

    2. when a 35ms timeout is present, software shall abort the transaction immediately by issuing STOP.

    Regards

    Yihe

  • Hello Yike,

    yes that does make sense

    We were reading 12 bytes because there is no better description of that register and the command reference manual SLVU352G seems to imply that there are 12 bytes. We were ignoring the data length assuming it would be 12 anyway... we didn't spot that incongruence.

    :

    Thanks,

    Marco