Digital Discovery Cant Get trigger to work for capture SPI communications to SD Card

[mmessuri]

I am sorry if this is a simple question but I have been fighting with this for most of the day:  I am using an Arduino to read/write to an SD card (via a breakout board) and during this activity I am trying to use the Digital Discovery  (and WaveForms version 3.22.2) to capture (using both the logic analyzer and SPI protocol analyzer)  the initial command (0x40) being sent over MOSI; however, my trigger never hits (to add insult to injury, if I am using the SPI protocol analyzer to monitor the traffic I see values being passed back and forth but never the inital command block (which is 0x40 0x00 0x00 0x00 0x00 0x95).

To make sure that I have everything wired up correctly I also setup a Sale Logic 8 to the same pins (using a breadobard) and ran a capture with the Salea Logic 2 software).  Without having to mess with any of the configuration params in the Logic software I see (and trigger on) the desired 0x40 Command value so I know its going accross the wire and that my pins are correct.

My settings in WaveForms are:

    

SPI_CS: DIO24
SPI_CLK: DIO29
SPI_MOSI: DIO28
SPI_MISO: DIO25

SPI Protocol Analyzer Settngs:

Select: DIO24
Clock: DIO29
Active: Low
Polarity: 0
Frequency: Have tried from 100kHz to 50MHz
DQ0: DIO28
DQ1: DIO25
First bit: MSBit
Glitch Filter: Enabled

Logic Analyzer (From the Debug with option)

Select: DIO24
Clock: DIO29
DQ0: DIO28
DQ1: DIO25

Mode: Repeated (also tried just about every other mode)
Trigger: Normal (also tried Auto)
Source: Tried both Digital and Patterns
Protocol: Spi MOSI
    Trigger: Value
        Value: h40
           Place: Any
Source: Digital, Rising Edge, 100MHz (also tried 200Mhx), 8 bits, DIO 24...31
Samples: Default (also tried up to  32 Mi
Rate: 100Mhz (also tried down to 20Mhz)

Note:  3.3v VIO not connected as the Arduino Uno is supplying the volatage

Also, I have tried all of the above on both a Windows 10 system and a Linux system

I must admit at this point I have no clue as to what I am doing wrong so any advice would be much welcomed.

 

Thanks.

 

-- Michael --

Edited April 10 by mmessuri
typo

[mmessuri]

If I change the start delay to 1s and have the Trigger set to Auto, I can capture the data as-long-as I keep hitting the reset on the Arduino, causing the values to be sent again and again.  However, if I change the trigger to Normal nothing ever triggers.

Finally, with the trigger set to Auto the capture kicks off regardless of hitting the trigger (I dont' press anything to re-init the sending of data and the trigger starts recording)

 

Very frustrating!

Edited April 10 by mmessuri
More Information

[JColvin]

Hi @mmessuri,

I don't have a SD card set up on hand to readily test this out for myself, but lets see if I understand your description correctly (a screenshot and a picture of the physical setup would help).

When using either the Protocol Analyzer with the SPI Spy tab or just the Logic Analyzer with no trigger condition (or just on Auto which, as you saw, will start capturing data after a timeout period), you can still see the various lines being toggled in their expected locations. (I am presuming that you have double checked the physical connections considering that you are not using the default IO pins).

I have found with the Digital Discovery that if you are not the the Spy tab and instead on the Master or Custom tab, even with the Debug with Logic Analyzer selected, the digital input lines still seem to be driven so that data reception cannot occur.

If I have the Protocol tool open to Spy and then either Debug with the Logic Analyzer or use only use the Protocol tool, then I can receive and trigger on a value as expected:

Digital Discovery WaveForms screenshot:

Digital Discovery sniffing out the SPI data being sent between an Analog Discovery 3 communicating with a random Pmod. Probably should have not had a bunch of random other stuff underneath everything else for a cleaner picture but oh well.

Let me know if you have any questions or are still experiencing problems and I'll see how I can help.

Thanks,
JColvin

[mmessuri]

Here is the setup for just the Arduino, Digital Discovery, and the MicroSD card breakout board (connected to a bread board):

 

Here is the connections to the MicroSD Card (the ground wire came off when I flipped it over for this picture; however, you can see from all the other pictures that the ground is connected as shared between all devices)

 

I have mirrored your setup (as seen in your pictures), with the only difference being I am trying to capture/trigger on data from MOSI rather than the receiving of data on MISO.  I also setup my trigger for the CMD 0x40 coming out of MOSI:

 

When I press the reset button on the Arduino Uno, causing the SD_CardInfo sketch to run, the serial monitor of the Ardunio receives:

 

As you can see from this screen shot, the tigger never triggered:

 

Now I add another logic analyzer (in this case a cheaper verwsion of the Saleae Logic 8):

 

I change nothing within the analyzer portion of the Logic 2.x software, other than set a trigger for 0x40 on the MOSI line and then press run:

 

a few time frames later, the trigger hit

 

Yet nothing was picked up by the Digital Discovery (it still is sitting on armed)

 

So as you can see (and hopefully feel my frustation and bewilderment), a $20 knock of analyzer running logic analyzer software which required zero configuration changes is able to successfully capture/trigger yet the Digital Discovery (which cost over 10x as much [yes I know this Digital Discovery is more than just a logic analyzer]) is unable to perform the same task (even with all the tweaking I have tried [which includes just using the logic analyzer portion with the High speed probes and running at 800MHz]).  I am sure it is probably something I have done wrong but I just cant figure out what.

 

 

As a final note, if I turn off the "Debug with Logic Analyzer" option here is a portion of the capture from the SPI Protocol (I nseem to get a large number of "Leftover Bits" no matter what setting(s) I use:

 

...

Data: hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, hFF | h00, 
Leftover bits: 5 hF8 | h08, 
Leftover bits: 1 h0 | h0, 
Leftover bits: 3 h20 | h20, 
Leftover bits: 2 h00 | h00, 
Leftover bits: 6 h0FC | h004, 

 

Edited April 11 by mmessuri
Updated

[JColvin]

Hi @mmessuri,

Your wiring looks correct to me (thanks for clarifying that the ground between the 3 devices are normally all connected since only 1 out of 3 photos shows the DD ground connected), and I understand your frustration about not getting the SD card to work.

I located an Arduino Uno around my office and am now in the process of debugging the built-in CardInfo example with the Digital Discovery.

I can manage to get the Protocol SPI Spy to report recorded data (it reports a number of leftover bits) before each transaction, and can get the Logic Analyzer to capture data when I set the trigger to an individual pin. But attempting to trigger on a SPI MOSI value of h40 (which I can see repeatedly comes up early on in the transaction) never fires, even though if I open the Events view, I can see and have WaveForms jump to the h40 event on MOSI just fine.
Interestingly, if I set the Logic Analyzer to trigger on SPI MISO, then it catches whatever trigger just fine.

The clock signal also does not appear to be free running and I seem to occasionally catch a spurious(?) positive edges on the Chip Select line, which I suspect is causing the leftover bits. I half wonder if this is because the Uno runs at 5 V logic, but the Digital Discovery uses 3.3 V CMOS (albeit 5 V compatible) but that corresponding lower threshold is getting tripped. Regardless, that doesn't explain why the SPI MOSI trigger value isn't being caught as it is the second one in.

I will continue to do more debugging today to get a better answer for you as, indeed, one of the primary purposes of the Digital Discovery is to debug and view different protocol transactions.

Thanks,
JColvin

[mmessuri]

Concerning the  Uno's 5 V logic and the DD's 3.3v logic, I thought the same thing so today I added a Logic Level Converter between the Arduino and the Logic Analyzer / device

Drove the Low power supply (to the LLC), using a bench power supply:

This had to effect on the problem (same old garbage in the analyzer).

Since that did not work, I disconnected the above and recalibrated the Digital Discovery.  This also did nothing to resolve the problem.

Finally, I tried changing the delays and buffer sizes and this also did nothing to solve the problem.

So at this point, I have run out of ideas

[mmessuri]

After re-reading your response, I noticed that I failed to mention:

I also tried chaning the trigger to 0x40 on MISO and sure enough, a trigger is hit every time

[JColvin]

Hi @mmessuri,

None of my co-workers in my timezone had the hardware to replicate my setup, but I think got it working, including getting rid of the excessive leftover bits. I have attached the WaveForms workspace that I am using. 

To be honest, I'm not exactly certain what changed in terms of software, since all I had done was roll back to an older version of WaveForms to test out the SPI MOSI triggering, found it was working, and then could not get it to fail to trigger again despite having repeatedly seen it fail all morning and the fact that I had not made any hardware changes yet. I tested multiple two different Digital Discoverys and multiple versions of WaveForms (20.1 release, 22.2 release, and latest beta 22.16) and multiple known MOSI transaction values (h40, h51, h02).

The main hardware change that I did was to use a twisted wire pair for the Chip Select signal with a ground signal wrapped around it, as recommended by the WaveForms developer for this thread on the same CS spikes that I was seeing:

I happened to use the high speed twisted wire pair to accomplish this, which I believe I saw you also had from your photos.

Otherwise the wiring is all the same. 3.3 V supply, ground, and regular SPI pins from the Arduino Uno to the SD card; DD using DIO 24 for Select, DIO 25 for Clock, DIO 26 for MOSI, and DIO 27 for MISO.
I put the ground for the twisted CS pair wire on the ground line for the 3 boards and the other end into DIO 28 (since I didn't want to split that wire apart) and had DIO 28 and 24 pulled low in the Supplies instrument.

Let me know if it this works for you, and I'll be more than happy to continue debugging if you are still not able to get the expected results.

Thanks,
JColvin

DD-SPI-SD-analyzing.dwf3work

[mmessuri]

So I gave your workspace a try, along with your addition to the twisted pair on the CS line and still had no luck. Now if I also add a twisted pair to the CLK line then I can get the trigger to take place on MOSI; however, I still see a bunch of leftover bits which seems to be corrupting the data as the 0x40 CMD does not termiate with the 0x95 value (see picture, where it is ? h90).

 

At this point I am thinking it is interference caused by the use of a bread board so I have ordered a different SD card breakout board (also going to mod the one that I am using so that I can have pins on both sides)

if you dont mind me asking, what is your breakout setup there?.

After doing all of this I do have a follow-on question:  Any ideas on why the DD  is having such issues when the cheap analyzer does not?

[JColvin]

Hi @mmessuri,

The breakout setup I have uses the Pmod TPH2, https://wiki.digilent.com/reference/pmod/pmodtph2/start, which is just a dedicated test point header module, and the SD card adapter I am using is the Pmod SD, https://wiki.digilent.com/reference/pmod/pmodsd/start, but I anticipate there will be effectively zero difference between the Digilent branded SD adapter and the mikroElectronika one you have.
Maybe the breadboard setup is contributing to the crosstalk happening on the CS line, but having extra long pins on the SD card to extend on both sides should take care of that.

As for why the other Logic Analyzer is giving better/more consistent results, it looks like from the photo where I can see the Logic Analyzer, it appears to run at 24 MHz (or at least that is what it has labeled on the shell) and ends up missing (or maybe filtering via software? Not certain what options it has) the tiny cross talk pulses.

This is what I see with the ADP2230 (has 50 MHz bandwidth oscilloscope inputs) when I probe the CS line and also treat use the Scope to Digital functionality to interpret the Scope Channel 1 as part of the SPI bus.

example of spurs that I see:

zoomed in on a spur:

Or at least that's my theory of what the Digital Discovery also operating at a high sample rate is detecting.

I'm hoping @attila may have some more insight into this when it's a more reasonable timezone hour for him.

Thanks,
JColvin

[mmessuri]

JColvin, thanks for the update and I'm sorry to say that I will have to wait until at least Saturday to follow up as during the moding of my micro SD card reader I had a slip up and botched up a through hole (it's been one of those weeks) by pulling up the top part of it (just pcb left now).

I did place an order for some replacements but they won't be here until Saturday 

[mmessuri]

JColvin:

Finally, success...Over the weekend I lifted a SD Card connector from an old PCB and addedd long header pins to it, with this addition I was able to eliminate the use of the breadboard (I still receive a "Leftover bit" error every once in a while but everything else is working).

Thanks for all the help on this.

 

BTW: While I am not sure if it is still needed, I did use the twisted wire pair (high speed) for both the CS and the CLK pins.

 

-- Michael -- 

 

 

[JColvin]

Hi @mmessuri,

I'm glad to hear you are having much more success.

To be honest, even after I had added the twisted wire pair (I also used the high speed pair, I didn't check to see if I could accomplish the same thing with just random breadboard wires that don't have the embedded resistor), I would also receive an occasional lone "Leftover bit" error, but it was far less egregious than when I was getting the errant CS spikes.
I'm not sure off-hand if these remaining bits are a remaining errant spike or a quirk in the CardInfo example (since I seem to recall that the leftover bit was in a somewhat consistent location); I haven't done further debugging to determine the root cause.

Regardless, let me know if you have any questions.

Thanks,
JColvin