• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 3879 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SPI data shifted by 1 bit

Pascal4275
Expert 2045 points
Other Parts Discussed in Thread: MSP430F5659

Hello!

I'm facing a weird problem when reading data from a device.
Here is the environment:

CPU: MSP430F5659
Device : BiSS master (iC-MB4)
Dev environment: IAR (although I'm quite sure it doesn't matter).

1. What happens:
- I have configured the SPI device (UCB0) with polarity 0 (idle low) and phase = 1.
Although the maker says that the phase should be 0, I guess it very much depends
on what one calls phase = 0. I found out that the only case where the device responds
is when phase = 1 (i.e. MSP430's CKPH is 1).
- I verified that the timing is absolutely right on the oscilloscope. My scope
as a bus analyzer, and when set properly it can perfectly decode the data. I can
write data in user registers and read them back, the timing is right,
- Problem: MSP430 reads a result shifted by 1 bit to the right.

2. What I have tried:
- I have first tried all the other combinations of CKPH and CKPL, but there is only
one working (at least on the scope). All the other combinations return 0.
- Read the next byte. I thought that the next byte would possibly contain the last
bit of what I'm reading. Exxample: the value I am supposed to read is 0x03, but
when I read, it's shifted, and I get 0x01. So I thought that maybe the next byte
would be 0x80, in which case I could have a workaround, read one byte more than
needed, and then fix all the bytes I have read by shitfing left and adding but 7
of the next one. But it doesn't work.

3. What I finally did:
I made a GPIO implementation of the SPI bus (bit banging). And this works perfectly,
but I cannot use DMA for transfers, so I would really appreciate any hint to get out
of this problem cleanly.

Thanks for any hint!

Pascal

  • 0
    Guru 23000 points
    Phase is a fixed definition and ranges from 0 to 360 degrees. Setting the Phase-bit to level ‘1’ inverts the CLK signal by shifting the Phase of it to 180 degrees.
    Both Transmitter and Receiver using the same clock and so they must use the same phase, otherwise you will miss one data bit.
  • 0 in reply to Leo Bosch
    Expert 2045 points
    Hello!

    Thanks for your reply.
    If I may repeat what I said, maybe in a more summarized manner, I tried all the solutions for CKPH and CKPL.
    The chip expects clearly a clock polarity of 0 (0 when idle). Just in case, I tried with CKPL = 1 and both CKPH of
    0 and 1. None works (MOSI stays low on the scope). So I use only CKPL = 0 now.

    - The only case where the chip replies is when I set CKPH = 1 in the MSP430 register.
    - The oscilloscope decodes the signal right, example if I want to read 03, then the scope decodes the response as 03.
    - Although the scope reads it right (clearly displayed as 03), MSP430 reads 01.

    Is there any other parameter to modify (other than CKPH, CKPL)?

    Best regards,

    Pascal
  • 0 in reply to Pascal4275
    Guru 23000 points

    All modifiable parameters are in the User’s Manual, and as I know there are no hidden ones.

    The signal levels must match with the Slave device, if still errors you need to look in other directions and not just gambling.

    The scope might read 9-bits. Does the signals (clock, data, CS; levels and edge direction) on the scope match with those in both devices User’s Manual’s? 

  • 0 in reply to Leo Bosch
    Expert 2045 points
    Hello!

    There is no gambling in what I did.
    I read the device manual, it said clock polarity = low when idle, which translates
    to 0 in MSP430's conventions.
    I read also in the device manual that the clock phase should be 0. Looking at the maker
    timing, data changes on falling edge, and is accessed on rising edge. According
    to MSP's manual, it corresponds to "Data is captured on the first UCLK edge and changed
    on the following edge.". As the polarity is idle low, I suppose the first edge is rising
    and the second is falling.
    From that, it's quite coherent that this is the only combination that gives a
    result on the scope.
    Why I tried other combinations? Just in case... I've seen plenty of cases where things
    didn't work the way they were supposed to, including sometimes because of my
    misunderstanding. But this time, I guess my understanding of CKPH and CKPL is the
    right one.

    Now, as for the other MSP's registers that could have an influence, let's see them
    in sequence:
    UCMSB: no. The order is fine, the maker spec says MSB first, everything is just shifted.
    UC7BIT : no, data is 8 bit
    UCMST : it's already in the proper config otherwise it wouldn't spit bytes. Master mode.
    UCMODEX : Wouldn't work if wrong
    UCSYNC: Yes, synchdonous.
    That's it for CTL0

    Now CTL1:
    Not a problem of clock selection or baud rate, modulation irrelevant.

    Next: status register: that's what it is. The problem is not there.

    The subsequent buffers are Tx, Rx, interrupt enable, interrupt flags, and that's it.

    So to summarize the situation: I can't think of a relevant register to change.

    My oscilloscope does not read 9 bits, 8 only. And when deciphering "by hand" using
    the cursors and looking at the states of the clock, I can't see any reason preventing it to work.
    Well, idle low clock is a quite rare configuration, that's the first time I meet this config
    in years.

    Pascal

**Attention** This is a public forum