• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 23 subscribers
  • Views 315 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.

LMK04828: Support for 32-bit SPI transaction length

David Kwong
Prodigy 10 points
Part Number: LMK04828
Other Parts Discussed in Thread: LMK04832, LMK04821, LMK04826, LMK04228

According to the TI spec sheet, the LMK04828 uses a 24-bit SPI transaction length.  Can I drive the LMK04828 SPI interface with a 32-bit SPI word and shift the 24-bit "word of interest" such that the first 8-bits shifted in are zeroes?  Since the LMK04828 basically clocks the SPI bits into a shift register, assuming it's a 24-bit shift register, will it keep shifting the full 32-bits in and keep the last 24-bits prior to the CS being deasserted?

Any clarifications would be very helpful.

Best regards,

David

  • 0
    TI__Mastermind 30920 points

    David,

    LMK04828 likely has a means to support this by zero-padding the final 8 bits rather than the first 8 bits; the shift register logic likely updates on the 24th bit of every transaction, so the subsequent eight bits would be ignored.

    I'm still waiting on confirmation of this from our design team. I'll report back once I'm sure.

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 10 points

    Hi Derek,

    Thank you for your answer.  I look forward to your confirmation.  I am assuming then that every time CS is de-asserted, the FSM responsible for selecting the first 24-bits is reset so there is no state carrying over from one SPI transaction to the next?  As such, every SPI transaction greater than or equal to 24-bits would always result in the first 24-bits being used and the following bits discarded.

    Thanks,

    David

  • 0 in reply to David Kwong
    TI__Mastermind 30920 points

    You're correct that the FSM would reset the transaction after CS deassert. The difficulty now is I'm not sure if the LMK04828 implements the same kind of (mostly undocumented) block read/write capability as LMK04832 (see e.g. https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1036075/lmk04832-change-the-external-clk-frequency-setting). If this capability is implemented, then the last 8 bits would have some meaning; rather than zero-padding transactions, we'd instead need to either prepare the data for the next register offset, or find a way to hold the address and duplicate the data byte.

    For various reasons it's looking like it might take a while for design team to get back to us, so I will try to experimentally verify the SPI function tomorrow when I can get into our lab for testing. Apologies for the extended delay.

  • 0 in reply to Derek Payne
    Prodigy 10 points

    Hi Derek,

    Thank you for your prompt support in this manner.  It's not clear to me how I would configure the RO bits.  Considering that this is undocumented behavior, my concern then is that this behavior could change from one revision to the next.  Will TI consider inserting an addendum to document this feature?

    Thank you,

    David

  • +1 in reply to David Kwong
    TI__Mastermind 30920 points

    I've determined the following:

    • 4-byte WRITE behavior decodes the address once using the first 16 bits, and all subsequent bytes are written to this address. In most cases, you should duplicate each data byte at the end of the transaction. Example: if you want to write 0x01 to 0x0002 address, you'd write 0x00020101.
    • 4-byte READ behavior decodes the address once using the first 16 bits, reads the byte at that address to the next byte, and pads the trailing byte with zeros. Example: if you want to read 0x0005, you would write 0x8005XXXX to the device, and the readback would be 0xXXXX5B00 (X = don't care).
    • When writing, I can envision a couple of registers that may require unusual handling:
      • Writing 0x0 with RESET=1 twice would reset the device twice in a row in rapid succession. This should be fine; the reset is significantly shorter than 8 periods of the maximum SPI clock frequency. In the unlikely event that this causes trouble, you could write the second data byte with RESET=0.
      • Writing 0x13E to trigger the SYSREF pulse count may retrigger the SYSREF pulser, if the SYSREF pulser is used in SPI mode. A potential workaround is to use the pin trigger mode. I don't think a SPI workaround exists, since all codes are valid and all will trigger the pulser.
      • Writing 0x142 to trigger dynamic digital delay adjustment may retrigger the adjustment. You could set the first data byte to 0, and the second data byte to the desired value, to avoid doubling the adjust period.
      • Writing address 0x168 (the LSB of the N-divider) triggers VCO calibration; I'm not sure what happens if the VCO calibration is retriggered so quickly. There may be a lockout period or it may just reset the calibration state machine. I don't expect this to prevent locking PLL2, but locking PLL2 may take 8 SPI periods longer than normal. In case there are issues, as a workaround you could set the SPI clock frequency extremely slow when writing this register, e.g. 10kHz, such that the calibration state machine is given 800µs to complete its operation. This should be more than enough time for the calibration state machine to finalize.
      • Writing the SPI_LOCK registers may be impacted, but I'm not sure how. These registers do not need to be written under normal circumstances, so it likely does not impact your use case.

    For read-only bits or unrecognized addresses, you can write whatever is most convenient for you and the device will ignore it. I suspect this question was directed more toward what to do if the register address decode changes between each data byte in the 4-byte transaction, but I have not observed the address to change between data bytes so I think this is a moot point.

    I'll look into getting this behavior documented in the datasheet somewhere. For now I can assure you that this behavior will be consistent across all production silicon for LMK04828(-EP), LMK04826, LMK04821, and LMK04228 devices, and this behavior is exceptionally unlikely to change since it would require a significant revision to the devices. For the sake of ensuring any such changes are captured in a PCN, I'll look into getting this behavior documented in the datasheet somewhere.