Hi, so I designed a simple circuit board that fits on top of the Launchpad. This circuit board has the MCP2515 Can Controller, SN65HVD TI Can Transceiver, and some other basic circuit components.
All I am focusing on right now is the SPI. The issue that I am having is that the MISO (master in slave out) line is always logic high. The other lines, SCK, MOSI, STE, all work fine.
I wrote a simple program for the Launchpad that, upon pushing the P1.3 button, sends a "Read Register" instruction to the MCP2515. This instruction is then sent a second time, and that is the end of the program.
All communication lines are fine, except for MISO, which is stuck at logic high. After lots of playing around, I ran into a situation where the MISO line went low for a very short instant (~40 ns), and then back to high.
Attached to this post are a picture of the schematic of my circuit board (R4 not connected), two pictures showing the waveform that I got from the Logic Analyzer, and printed below is the code that I used.
I appreciate any help that I can get and I am happy to provide any additional information or clarifications that may be needed.
Thank You.
p450 of the user guide states that you should set the UCSWRST bit before fiddling with the UCS registers. But it is set on power up so you can be let off on this one. ;)
Disconnect your circuit from launch pad and connect MISO to MOSI. Then re run the test with the logic analyzer connected.
Seth BerggrenThe issue that I am having is that the MISO (master in slave out) line is always logic high. The other lines, SCK, MOSI, STE, all work fine.
Seth BerggrenP1OUT |= BIT5; //STE high
But I wonder how your code shall work.
SPI is give-and-take. After releasing SWRST, UCA0TXIFG is set and UCA0RXIFG is clear. So your RX ISR won't be called unleyy sou actually write something into TXBUF, which in turn creates a transfer. Well, your manual setting of RXIFG in the port ISR is - surprising. But it does the job.However, then things get strange.Your RX ISR goes into case 1, where you lower teh slave chip select. Some slaves require a minimum delay after that. Then you write to TXBUF which sends the first byte. But at this point, you should break out of the case, clear the RXIFG bit and exit the ISR. Instead you proceed right to the next case (while the SPI hasn't sent a bit yet), stuff another byte into TXBUF, do some busy-waiting cycles (a no-go inside an ISR) and never read RXBUF at all.This code doesn't need a switch/case structure and doesn't belong into an ISR at all.
However, a close look on the screenshots shows that the occasional low pulse of your slave comes at the last falling edge of teh clock signal. Which isn't a valid position at all.
So besides the coding oddity I'd say you picked the wrong polarity/phase for the clock. Usually, the clock is low-active (idle-high), which requires the CKPL bit set. And in most cases, CKPH doesn't need to be set or the slave will listen to and push data out on the wrong clock edge.
p.s.: the Saleae analyzer is a very good device. Especially the software is excellent.
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
Thanks for the reply Jens,
I took most of your advice. I got rid of the delay cycles in the ISR and set the SPI mode of the MSP430 to 1,1 (the MCP2515 accepts 0,0 or 1,1 mode SPI). The only issue I ran into with changing the SPI was that, when I loaded the bytes 0x03 and 0x0F into the TX buffers, the analyzer kept reading them as 0x07 and 0x1F. I figured it is just a timing thing with the bits, so instead I sent the bytes 0x01 and 0x07, and the analyzer reads the correct bytes now.
Still, after making those changes, the MISO line is unresponsive.
I think my next step is to switch the MISO and MOSI lines, as suggested earlier, although I doubt that is the problem... Do you have any other suggestions that might help me out here?
Here is my new code, and below that is the new waveforms that I produced:
Seth Berggren (the MCP2515 accepts 0,0 or 1,1 mode SPI)
About your signals: well, I don't know the high-level protocol of your slave.
It's possible that while you send the first byte, teh slave simply han't anythign to say (remember, it hasn't received your first byte yet adn therefore cannto send any answer, so it probably just sends an 0xff dummy).
If the two bytes you send form a command, you'll be required to send a third dummy byte (probably 0xff) to allow the slave sending an answer. When CS goes high, this cancels the high-level protocol and the slave won't send an answer to the previous request on your next attempt.
This would also explain the sputious blip you encountered on MISO: the slave took the last clock edge (due to wrong polarity(phase) as the beginning of a third byte and started to send its answer - which then was canceled because no more clock cycles were coming and then CS was going high again.