Digital Discovery to collect 16 bit SPI data - multiple slaves with same CS, CLK, MOSI and individual MISO

[JAlaj]

Hello 

I am looking to use Digital Discovery to capture 16 bit SPI data on multiple slaves, all slaves will have CS, MOSI and CLK shorted, and MISO line will be individual for each slave. I want to capture continuous data for 24 hrs and dump it in a  text file

I also want to power up the part using same HW, so that i can capture SPI right after power up

Pls suggest, 

Thanks,

Jalaj

[Shalin]

Hello @attila

I have a query in Digilent Digital Discovery. Is it possible to use Digilent Digital discovery as a pattern generator and logic analyzer for I3C protocol ?

Thanks 

Shalin

[attila]

Hi @Shalin

I3C is not supported natively but it can be implemented in Logic Analyzer with Custom decoder.

[Shalin]

Hello @attila

Could you please guide me towards the implementation of I3C through Digilent discovery. Our new project will be utilizing I3C. Therefore, we will have to send I3C patterns via Digital discovery and further analyze them. In addition, we will have to vary timing with proper control. 

Thanks,

Shalin

[attila]

Hi @Shalin

You can generate custom pattern with the Pattern Generator and add custom interpreter in Logic Analyzer, but the existing I2C interpreter may also be suitable.
I'll try to implement I3C support later, but unfortunately cannot give you a deadline for this.

[Shalin]

Hello @attila

Thank you for supporting I3C protocol implementation into Digilent Digital discovery in coming time. I am looking forward and waiting for the incorporation of I3C. 

Thanks and Regards,

Shalin

[Shalin]

Hello @attila

I want to bring to your concern regarding a bug in receiver function (rgRX) of labview. When I send 32 bit pattern from Digilent pattern generator and capture 32 bit rgRX receiver pattern response, it comes constantly as all zero's in labview. I captured the response through Saleae LA and I am able to see 32 bit rgRX pattern there. However, the digilent rgRX is unable to capture the 32 bit pattern. Please check the rgRX functionality for 32bit response. 

I am attaching the screenshot below of 32-bit rgRX response captured through Saleae LA and the Labview VI below for your reference.  

Thanks,

Shalin

SPI_read - Annapurna.vi

[attila]

Hi @Shalin

Are you looking at 'rgRX out' ?
I could not run your VI but a similar script is working:

[Shalin]

Yes, I am seeing rgRX out with cRX = 32. 
I tried but it only shows rgRX for 4 bit and not for 16 bit and 32 bit. 
I would request you to please run my VI once. It will help in identifying the issue.

[Shalin]

Hello @attila,

How do you set the digital voltage level of the pattern in digital discovery ?

Do you have any specific function in labview to set the digital level ?

Thanks

Shalin

[attila]

Hi @Shalin

As you can see in the screenshot I can not run your VI since the sub-VIs are missing.

The voltage can be adjusted by FDwfParamSet (before FDwfDeviceOpen) or after with FDwfDeviceParamSet or FDwfAnalogIOChannelNodeSet.

[Shalin]

Hello @attila,

I have set the voltage as 1.2V in the VI, whereas I am still seeing 3V in the scope output. I have attached screenshot below.

Thanks,

Shalin

 

[Shalin]

Hello @attila

Please check the attached zip file below which contains the VI alongwith supporting libraries. I am not able to achieve the value of rgRX from digilent while I can see the MISO output data (rgRX) on other LA. Please try to run this VI and see if you get any output. 

Thanks,

Shalin

SPI read.zip

[attila]

Hi @Shalin

See the following: LV SPI.zip

[Shalin]

Hello @attila

Thanks for taking out time and making the effort. The rgRX is still appearing as zero. I probed this response on Scope and it shows that a very weak output MISO response of level 840 mV is appearing (attached screenshot below). Due to a weak output response, the digilent digital discovery DIO pin is interpreting this 840 mV as zero. 

Is there a way out , that this weak output signal response of 840 mV is interpreted as 1 by the digilent and shows 1 in the rgRX ? 

Is it possible to capture this weak signal by using the MISO high-speed LA pins (0-23) and adding a trigger ?    

Edited February 21 by Shalin

[attila]

Hi @Shalin

Try lower IO voltage. Eventual pullup which can help if the driver has some impedance.
The absolute minimum is around 0.96V but even if you try lower value it will limit to what it can. (The minimum recommended for the FPGA IO supply is 1.1V)

Here with 0.95V the threshold is 0.55V/0.65V
AD3 Wavegen is connected to one DIO of Digital Discovery and another DIO outputs the logic level of the input (with ROM Logic) which is connected to AD3 Scope 1.

[Shalin]

Hello @attila

According to our specification, we need to set CLK, MOSI and SS as 3.3V. When I lower the IO, it shows no response. My LA which is capturing has been set to 1.2volts digital level. At this level only, I am getting the MISO response of 840mv. Mainly, I will have to set the LA level to 1.2V to capture the MISO waveform. 

Is it possible to capture this weak MISO signal by using the high-speed LA pins (0-23) and adding a trigger ? 

Once I fetch the MISO signal using Digilent LA pin, then is there a way to set the rgRX in the VI with the array of data received from the LA pin ?

Thanks,

Shalin

Edited February 22 by Shalin

[attila]

Hi @Shalin

The supply voltage applies to all DIO and DIN channels.
The IO and IN channels have different frontends, see:
https://digilent.com/reference/test-and-measurement/digital-discovery/reference-manual#io_level_translators
https://digilent.com/reference/test-and-measurement/digital-discovery/reference-manual#input_dividers
The SPI and other protocols swap the capture order of IO IN channels, so DIOs are first. To use a DIN channel as MISO configure data 1 to be 16+DINnumber, like FDwfDigitalSpiDataSet(hdwf, 1, 16) for DIN-0

[attila]

Hi @Shalin

I just corrected a bug that could cause the MISO to be driven from the device side.

 

[Shalin]

Hello @attila,

 Thanks, it is working absolutely fine now. Meanwhile, I need to know the status of development of I3C support in Digilent. I will be requiring to use Digilent for our upcoming I3C based project. I will be performing automation through LabView by using Digilent I3C libraries. 

Thanks and Regards,

Shalin Verma

[attila]

Hi @Shalin

I spent a few days with this and then realized the approach I had chosen would not work.
Please don't wait for this, I don't know when I will have time to try to make it happen again.

[JAlaj]

On 8/9/2023 at 12:42 AM, attila said:

Hi @JAlaj

In newer sw version the CS can be controlled by hardware.
With the SPI/Custom or Script or API if the .Start/Stop() is not called the .Read/Write() will automatically assert CS.

Hello Attila,

I am trying to capture SPI data every 1ms. Its a 16 bit SPI capture. My target is to capture data for 3 hours. Periodic capture is required as i need to perform FFT on this data. I am unable to achieve this. Please suggest the best way

[attila]

Hi @JAlaj

If you are listening on signal use Protocol/SPI/Spy 'Receive to File' or for SPI master write a Custom script or Sensor for precise hardware timer.

[JAlaj]

2 hours ago, attila said:

Hi @JAlaj

If you are listening on signal use Protocol/SPI/Spy 'Receive to File' or for SPI master write a Custom script or Sensor for precise hardware timer.

Thanks Attila

I was trying that but i couldn't understand how FIFO will work here. Since Digilent DD has limited memory, it has to dump data into file to empty buffer and collect next set of data. But how do i make it synchronous. Would be great, if you can share one example code. I was trying to follow example code in script, but didn't get much help

[bobql]

On 3/25/2024 at 8:08 AM, attila said:

Hi @JAlaj

If you are listening on signal use Protocol/SPI/Spy 'Receive to File' or for SPI master write a Custom script or Sensor for precise hardware timer.

Hi Attila,

Is there anyway to mimic in labview the "Sensor" feature implemented in the Waveforms GUI?  We have a 5 axis sensor that I would like to read at very consistent read rates.

Below is a test case I have done using the a script in Sensor tab.  I found that the longer the iterations, the outcome is worse....i.e. timing is not correct.

[attila]

Hi @bobql

1. The Sensor tab on execution first calls the initialize function, where sensor register, global variables, file initialization... can be performed.
2. Calls the software loop function, without executing it in the device, to build a pattern with the transfers, like for CS, CLK and MOSI.
3. Starts to generate this pattern with hardware timer at the specified rate and iterations, and at the same time it captures the transfers.
4. Decodes the received MISO bits by software call of loop function, without executing it in the device.
5. At the end calls the finish function, where sensor register shutdown and file finalize can be performed.
The software timing of the software function calls in not precise but the pattern generation is, which are basically loop function calls in hardware.

Similar can be done in SDK.
Pattern with digitalout functions, see DigitalOut_SPI.py example, repeat can be set to 'infinite'.
Steps 3-4 can be merged, to receive and decode simultaneously, see DigitalIn_Spi_Spy.py. In Sensors tab these are separate since the sw loop execution takes some time and it would be a bottleneck at high rates.