SPI Problems, Pyboard

Hello @Fahad,

These are fine. But buffers are controlled separately. There is a “Board” tab in the LimeSuite which controls direction of the on board buffers. This is why I am asking to check the on board buffer direction control pins using a multimeter or scope. Just to be sure that on board buffers are set to the correct direction.

Hello @Zack

We configured the LMS by USB (using LimeSuite) and SPI, both configurations were using the same Test Sginal configuration ini that was attached before.
After that we measured some values on the board, and they were the same after both configurations.
We hope these values tell something about the buffers status, :

After configuration by LimeSuite:
IQSELEN1TX_DIR(R151) = 3.3v
IQSELEN2RX_DIR(R152) = 0v
DIQ2RX_DIR (R153) = 0v
DIQ1TX_DIR (R154) = 3.3v

After programming by SPI:
IQSELEN1TX_DIR(R151) = 3.3v
IQSELEN2RX_DIR(R152) = 0v
DIQ2RX_DIR (R153) = 0
DIQ1TX_DIR (R154) = 3.3v

Thanks in advanced,

I wonder whether it is normal to get the voltage dropped from 5v to ~4v (and sometimes to ~3.3v and the current reaches ~1.00 Amp) after the SPI configuration? we feel there is something wrong here.

The interface is like the following:
TxEn = 3.3v
RxEn = 3.3v
VDIO_BB = 3.3v
4-wire SPI Interface.
GND is common.
Board v1.R3.
Resistor (R184) is removed.
LMS is powered by 5v external power supply.

Thanks in advance ,

Hi @Fahad,

It looks like your power source is not capable to deliver the current for the board. It is possible that the board consumes more than 1A after configuration.

Could you make a photo of your setup, please.

Hi @Fahad,

I am confused. If I understand correctly, you are using UNITE7 board without Stream board, right? If this is true, then IO buffers on UNITE7 board are not powered up. You have to solder R184 or supply the buffers via FMC connector. As I wrote in my previous message - need more detailed description on how everything is connected and supplied.

Yes it is UNITE7002 that is connected to Raspberry Pi 2. Here is the steup as shown in the following photo.

To clarify that, in J7:
Pin 8 (VDIO_BB), pin 18 (TXEN), pin 38 (RXEN) are connected to 3.3v that it gets from Power Supply.
Pin 17 (MCLK1TX) to yellow probe, pin 37 (MCLK2RX) to green probe.
Pin 40 (SAEN) is connected to a gpio of the Raspberry Pi 2 to master the 32 clock cycle.
4-wire SPI Interface.

In the SW1, RST is set to ON and HWB is set to OFF.

Thanks in advance ,

Hello @Fahad,

From the picture I see, that UNITE7 onboard MCU is not reset. SW1 RST switch (next to USB connector) must be set to the opposite position (to the right) to reset the MCU.

Hello @zack,

We’ve tried that too, we are out of the office now right, but we will switch it to the right again and update you by tomorrow.

Thanks for your fast response ,

Hello @zack,

We found out that the drop in the voltage because of the conflict between “Ports Mode Selection” and the “Board Buffers” settings, that it is fixed and no observed drops in the voltage now.

We tried the Test Signal configuration again with the UNITE board via USB, and it works just fine. The same content of the ini file was transmitted via SPI and all what we get is just the right MCLK signal, but no data on any of the ports!

  • Is it the best way to send the content of the 1120 registers of the ini file register by register via SPI?

Regards ,

Hello @Zack

This is gentle reminder.

Thanks ,

Hello @Fahad,

Sorry for the late response!
It is very difficult to say what may be wrong, when I have no access to the source code.
Is there any chance to get your code to be able to test it in my lab?

Hello @Zack

Here is the C code and the ini file we use to perform the configuration.
Just to explain the mechanism of the application, I use the “spi_conf.ini” which is the configuration of the test signal. First the application skips the header of “spi_conf.ini” untill it reaches the ( registers = values).
find_reg() is to catch the registers in the ini file, and find_value() is to catch the value of the registers.
After that, it converts registers and values from char to hex to be written to RAM.
Regarding to Chip Select, I use Raspberry Pi 2 and I mapped the CS to GPIO to control 32 clock cycle each time the application transfer instead of the standard CS pin.

Here is the link:
https://drive.google.com/open?id=0B6S3uUgUXRWRMVptdjFnSndzU2s

Best regards,

Hello @Fahad,

I will be able to test it next week.
How do you compile it on RPi?
Could you please write what exactly pins you are using to connect SPI bus. For instance:
UNITE7 J7.41 to RPi pin 23

Hello dear @Zack,

Native C compiling on RPi:
$ gcc foo.c -o foo
$ ./foo

The interface:
UNITE7 ---------------- RPi
J7.40 (SAEN) ---------------- Pin32 (GPIO12)
J7.41 (SCLK) ---------------- Pin21 (SPI0_SCLK)
J7.42 (SDIO) ---------------- Pin19 (SPI0_MOSI)
J7.43 (SDO) ---------------- Pin21 (SPI0_MISO)
GND ---------------------------- GND

I hope that is clear.

Regards ,

Hello @Zack

We tested the LMS on our PCB (iteration #1 of our SDR, not the UNITE7002) and the test was as following:

  • We configured the LMS on the PCB via SPI.
  • The configuration aimed to perform an internal-LMS-loopback ( FPGA —> LMS —> FPGA).
  • We were able to transmit the samples from the FPGA to the LMS, and the LMS returned back the values to the FPGA successfully.
  • BUT when we configured the LMS to generate the test signal, the 2MHz Clock MCLK was generated successfully but the data from LimeLight didn’t.

So we still stuck ,
Thanks ,

Hello @Zack

Is there any update with testing the SPI code?

Best regards,

Hello @Fahad,

Just got a time slot for experiment, sorry for delay.

Looks like typo - should be J7.41 (SCLK) ---------------- Pin23 (SPI0_SCLK), could you edit your post, please.

My setup is as follows:

  1. R184 resistor soldered (to supply on-board buffers for data lines);
  2. Board is powered from external 5V power supply;
  3. USB MCU is powered from USB (UNITE7 is connected to the RPi via using USB cable);
  4. USB MCU is reset (SW RST switch is set to “ON” position);
  5. Wiring between RPi and UNITE7 is as above except SAEN is connected to the ground instead of RPi’ GPIO12

The reason of item 5 is that SAEN line is not controlled from RPi side - it looks like it is an input, not output. Hence configuration van not be uploaded.

When I run your software, I can see an activity on DIQ2RX_* lines. So, it looks like everything was OK, except SAEN line and you have to connect USB cable just to power-up the USB MCU (it will supply the SPI level buffer between LMS7002M and USB MCU or J7 pinheader).

Let me know if this helps.

Hello Dear @Zack

You are right it is Pin23 (SPI0_SCLK).
By following ur setup, this is the only activity we noticed:
Green = similar results from DIQ1 & DIQ2 (J7.1 & J7.21)
Blue = MCLK1TX (J7.17)
Yellow = MCLK2RX (J7.37)

On the other hand when the SAEN is conneted to RPi Pin32 (GPIO12):

Still not sure why we have no output from DIQs ports.

Thanks ,

Hello,all,
Has the isssue been solved? Currently, I met the similar issue. we sent the anologue signal to LMS7002M,
we can read out the vaule of digital RSSI which varied with input anologue amplitude, in the Limelight port, except the MCLK and IQSEL , all data lines are zeros. we have checked the registers settings, but could not find out the root cause.
Could you pls share your experience to solve the issue with me ?
Thanks very much!
@Zack
@Fahad
@RoryM

Note: our system is only 1.8v supply with inner LDO used. we constructed the register settings based on the ini file of Limesdr-mini, sent by Zack.

Best Regards!

Hi @huangdeyong123,

There are interface settings in the ini file as well. You can check it according to your setup.