• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 1077 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.

Missing clock edges when Using SPI comms

george clarkson
Intellectual 830 points

Hi there,

I'm currently having an issue with using SPI to communicate with an external flash. I'm currently using DMA to send out SPI comms using the UCSI_B module.

Most of the time this is working fine however sometimes I am occasionally getting errors when I communicate with the Flash chip and it doesn't hear me correctly. After a long time chasing this around I've discovered that it appears to occasionally miss a clock pulse. I've included an image below to help explain.

what should have occurred here is the the bytes [0x81][0x21][0x9F][0x00] should have been sent followed by an [0xFF] which would be sent during the point when the enable line is pulled back high. However as you can see this isn't what happened, looking closely you should be able to see that part way through the second byte the clock remains high for too long.


I'm currently running the USCI_B clock at 8Mhz, which is derived from a 24MHz source. I also ensured that when I recorded the data my sampling speed was high enough to avoid aliasing (sampled at 25MHz).

I've checked the errata (quick link here if you want to recheck) and I couldn't find anything that would obviously explain this so I'm hoping that someone on here might be able to offer some suggestions.

EDIT 1: The error occurs in different places, I send lots of different messages over the SPI lines, and I've seen the error occur in them all and in a different spot each time. I haven't noticed any pattern in the errors occurring.

Electrically the lines are short and scoping them reveals no obvious problems the rise times are well within what would be required and there is no visible rippling or noise from external sources.

There are several options for what the CPU may be doing during the DMA transfer, as there are several interrupts that could trigger duing this period, alternatively it may be sleeping. However this is unlikly to be the problem as the data does appear to have been inserted into the SPI buffer correctly, as adding a clock pulse to where it is missing would have provided the correct data. As such I believe the problem to be occurring after the DMA has completed its job.

  • 0
    Guru 16361 points

    At first I wondered if this might be a case of the usual SPI communication problem: clock phase and polarity settings. Looking closer it's clear that the wrong number of clock pulses are being produced (39 rather than 40).

    Does it work correctly if you use the CPU to load the transmitted data instead of DMA?

  • 0 in reply to Robert Cowsill
    Intellectual 830 points

    No the code originally used the CPU and I actually implemented DMA as part of my playing with the code. Unfortunately it doesn't make much difference.

  • 0 in reply to george clarkson
    Intellectual 830 points

    Small update, so I've also posted this on StackOverflow to see if anyone over there might be able to provide any suggestions. However I've edited the main post with some additional information that was asked for over there.

  • 0 in reply to george clarkson
    Intellectual 830 points

    Ok, I've just written a small test program in which the micro continually writes the the flash chip, and I've set up a test pin to toggle when it goes wrong. I've now run it for around 20 minutes and not seen an error, I'll keep running it for a bit longer but I think this means that the problem must be caused by an interaction from another part of my code.

    What other modules could cause a problem with the SPI?

  • 0
    Guru 227245 points

    The ‘missing’ clock pulse indeed seems to be a missing clock pulse.
    But the USCI doesn’t ‘forget’ clock pulses. The data output wouldn’t propagate as it apparently does if there were no clock pulse.
    So there are not many possible reasons.
    First is an electrical defect of the MSP’s output driver.
    Second is a 3rd party signal on the SCL line that pulls it high.
    Third would be a mismatch of the two part’s threshold value for the digital levels.
    If the MSP is running form a lower voltage than the slave, the MSP’s output voltage might be too low to be safely accepted. It would be interesting to look a the real signal (with a scope) when this happens.

    However, your test code indeed seems to indicate a software problem. So it would be necessary to know the code that causes the problem, for further analysis.

**Attention** This is a public forum