• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 80 subscribers
  • Views 4879 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 half Duplex Slave with MSP430 as Master

Gert Havermann
Prodigy 100 points

I Have a Problem when using the MSP in SPI-Master Mode and trying to communicate with a half Duplex Slave.

The MSP only works in full Duplex, thus the Clock and CS only works for the Duration of the Send bits. In half Duplex the Slave starts responding some (undefined) time after receiving the bits. Since this undefined time also changes due to internal process times of the Slave, I see no way to find the first bit of the Response in order to read the bit sequence correctly.

I already tried to send a bunch of zeros to Keep the clock running, but when the reply starts with one or more Zeros, I see no way to synchonize it.

 

My next attempt will be bit banging, but if anyone here has an idea how to deal it in a more simple way I would appreciate other ideas.

 

BR

Gert

  • 0
    Guru 74080 points
    That sounds strange. What is your slave device? CS can be any pin you want which isn't controlled by the communication. You do not have to use STE. Does your slave give you some kind of status when pulling CS low?

    Dennis
  • 0 in reply to Dennis Eichmann
    Prodigy 100 points
    The Device is a EM4325 RFID Chip, and it gives no Status. I just read that it will start every reply with a 1, thus it seems as if I would need to rearrange all received bits to have the fist 1 being the MSB. But still the Problem is that the Clock will only be clocking as Long as the MSP is sending. since I don't know the exact delay between send and receive (datasheet sais ist in between 5-500µs) I would Need to add a lot of Zeros to keep the clock running Long enough, and with huge data packets the rearranging of received bits might lower my Battery time significantly.
  • 0 in reply to Gert Havermann
    Guru 74080 points
    Gert,

    could you please link in the datasheet and tell us the site where this mechanism is explained?

    Dennis
  • 0 in reply to Dennis Eichmann
    Guru 16361 points

    This looks like the datasheet for the specified RFID chip:

    http://www.emmicroelectronic.com/products/rf-identification-security/epc-and-uhf-ics/em4325

    The section on SPI slave operation says:

    EM4325 Datasheet said:
    This device will output a data value of ‘0’ on MISO before and after any reply back to the SPI Master. The maximum response time to an SPI command is 20 ms. The start of any reply always begins with a data value of ‘1’. The following example is provided to illustrate the use of this device as an SPI Slave to communicate with an external SPI Master device.

    The section after that explains that the slave will insert a 1 bit as the first bit of a byte, and all subsequent bits will follow. That suggests you might need to do some further processing on the incoming data to ignore the leading 1 bit.

    EDIT: I think I get it now. The first byte of every reply is "Reply Status". The MSB of that byte is 1, then the other seven bits give various status flags. The real response data is contained in subsequent bytes. That means you don't need to do any processing to get rid of an extra bit. Unfortunately you still need to transmit dummy data from the SPI master to get it to output a clock train though.

  • 0 in reply to Dennis Eichmann
    Guru 16361 points

    [double-post, ignore... delete seems to be broken]

  • 0 in reply to Robert Cowsill
    Prodigy 100 points

    Exactly, and I will need to delete the leading Zeros of the Reply in order to have the first bit to be the MSB. Is there any nice Feature to do so, or do I have to write a Loop looking for the first 1-Bit?

  • 0 in reply to Gert Havermann
    Guru 16361 points

    Gert Havermann said:
    Exactly, and I will need to delete the leading Zeros of the Reply in order to have the first bit to be the MSB. Is there any nice Feature to do so, or do I have to write a Loop looking for the first 1-Bit?

    I think you're misreading the document the same way that I was until I edited my post above. The EM4325 doesn't just prefix the reply with a single "1 bit", it prefixes it with a status byte. The first bit of the status byte is 1, but the remainder of that byte is status data.

    That means you need to ignore "zero" bytes, until a byte arrives that is non-zero. Bytes after the first non-zero byte contain the rest of the response. If you ignore the zero bytes and the status byte, then the first bit of the next byte is the first bit of your response.

  • 0 in reply to Robert Cowsill
    Prodigy 100 points
    Since the Status Byte will begin somwhat along the clock stream I can not guarantee that the fist bit of the Statusbyte will be recogniced as the first bit of a complete received Byte. E.g. when the statusbyte would be sent starting on the 6th clock, then the received Byte would be binary 000001xxxxx (xxx being statusbyte and Information).
    I Need to remove the leading Zeros of the reply to be able to remove the Status Byte from the reply.
  • 0 in reply to Gert Havermann
    Guru 16361 points

    Gert Havermann said:
    Since the Status Byte will begin somwhat along the clock stream I can not guarantee that the fist bit of the Statusbyte will be recogniced as the first bit of a complete received Byte

    Have you tested and seen that happen in practice? I know the document doesn't make it entirely clear whether the status byte aligns with the byte boundaries implied by the master clock, but it would be an awful protocol if it didn't!

    Perhaps you could try asking the manufacturer for confirmation on this. If they don't respond or say there are no such guarantees then it's time to consider looking for an alternative product...

  • 0 in reply to Gert Havermann
    Guru 327040 points

    I could not find a minimum SCLK frequency in that datasheet. So you might try the following: switch the SPI pins to GPIO, regularly send a single clock pulse to check whether you get the first bit of the answer (this does not need to be fast), and only then switch back to SPI to receive the rest of the answer.

  • 0 in reply to Clemens Ladisch
    Guru 227245 points
    Good workaround, Clemens.
    SPI by design is a bit stream. Usually, the bits are grouped into bytes, but I've had slaves with data packets that are 21 bit long.
    However, in those cases, the slave usually shifts the bits as they come and latches the last n bits when CS goes high again.

    For slaves where an arbitrary number of bits (and time) may pass until response, you have usually a dummy status byte returned until one byte comes that tells you that data begins now. SD cards are a typical member of this kind (block read function, also device init)

    But if you really have a bit stream where the first '1' bit after an unknown number of '0' bits indicates start of the transmission, then manually polling a single bit every now and then before using the USCI for the actual data transfer is probably the best way to handle such an unusual slave.
  • 0 in reply to Jens-Michael Gross
    Prodigy 100 points
    Thanks for all the suggestions and help. I tested Clemens Workaround, and it works. The only drawback is that I still need quite some CPU time for the processing, and thats hits me hard on my Power Budget. But for the time beeing I think there are no better Solutions so we can call this "Answered".
  • 0 in reply to Robert Cowsill
    Guru 227245 points
    "Unfortunately you still need to transmit dummy data from the SPI master to get it to output a clock train though."
    I can imagine a clever setup of DMA in combination with an ADC12 (or something similarly suitable):
    A timer trigger one DMA channel to send a dummy byte every now and then. The received response is moved by DMA to the ADC12 interrupt register. Where the MSB will trigger an ADC interrupt, if set. In the ADC ISR, the DMA can be reconfigured to poll the complete answer (or it can be done by using the USCI interrupts).
    This allows the CPU to remain in LPM0 or better, until the start byte has been received. (note that DMA and USCI still need a clock, DMA using MCLK)

**Attention** This is a public forum