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.

LMK04208EVM: LMK04208EVM

Part Number: LMK04208EVM

We ran into the shifted bit problem as well with this chip. Any write to R9 shifts the timing of the readback pin. Yes we checked all the READBACK_LE, etc. Everything works great until we write to R9.

We avoid this problem by manually removing the write to R9 from the exported hex values file (from TICS Pro). It would be nice if TICS Pro wouldn't output this register in its export file or attempt to write to it so we wouldn't have to manually remove it each time.

Also, if anyone knows how to get it back into a working state, that would be great as well.

  • Hello Richard,

    Just to double check, is the value for R9 0x5555 5549 (in hex)? This should be the programmed value of that register for the device to operate properly (the automatic configuration in TICS Pro should result in this value). Not sure if this is what you meant with "checking the READBACK_LE, etc," but did you go over the data sheet section "8.5.3 Readback." In that section, it goes over properly setting readback, as well as an example. You can find it in p. 51 of the data sheet.

    Regarding specifics about the register, I will get back to you on that by tomorrow.

    Good Luck,

    Andrea

  • On startup, the readback value of R9 is 0x5555 5540 (since you only read the first 27 bits). If I write 0x5555 5549 to it, and then read it back it changes to 0x2AAAAAA0. READBACK_LE is '0'.

    Here is the waveform before writing (when reading R9):

    Here is the waveform after writing (when reading R9):

    The bits seem to shift over. I am driving this from a SPI interface with CPOL=0 and CPHA=0. My understanding is that thos settings should match for uWire (send data on falling edge, sample on rising edge). In 8.5.3.1 bullet 3, it says "Data is valid on falling edge of CLKuWire". Isn't this incorrect with the uWire spec? This wouldn't explain the shifting of bits after writing to R9, but it would mean that after the shift the data is correct (would be 0x5555 5540 if sampled on falling edge).

  • I think I found a solution. I believe this chip is expecting it's readback data to be sampled on the falling edge, but I have to run the SPI at CPOL=0 CPHA=0 for the writing to work (it samples on the rising edge). The workaround is to shift the output bits up one (dropping the MSB). If I do this the R9 register comes up as 0xAAAA_AA80 (readback), but the other registers read ok. I then just write 0x5555_5549 to R9 and it shifts its bits so it will then read 0x5555_5540 after that. Subsequent writes to R9 keep the same shift. This may create timing problems since I am sampling on the rising edge after the falling edge, but it seems to work.

  • Hello Richard,

    Glad you found a solution! To further your comments, you are correct, as shown in the timing diagram below (on p. 14 of the data sheet), the data is sampled on the falling edge. Also, for the device to function properly, it needs to have register R9 set to 0x5555 5549, so make sure that is the case. 

    Good Luck,

    Andrea