# Is it a problem with SPI bit-banging or the mode

After hours of debugging the SPI send bit-banging function and probing, I have come to a point where I could no longer understand whats causing the Si4455-RFIC to always return response of 0x00, including for CTS command. However I have hypotheses for this problem cause, which are:

1. I believe it would be mainly due to the Si4455 not being able to process the commands and hence returning 0x00
2. It's not processing the commands because it's having trouble interpreting it, because there is something wrong with my SPI bit-banging function or the data I am sending.

According to the Si4455 datasheet here, it states the following on page 23 regarding the SPI mode of Si4455:

And shows this SPI timing diagram on page 22:

From the above information, it is understood that the host MCU must put the data on the SDI of Si4455 during the falling edge of clock, so that the Si4455 can read the data on the rising edge of the clock. And the same applies with the Si4455. Based on this, I wrote a function that sends the data (Commands bytes) to the slave device i.e. Si4455 using the simple bit banging method as shown below:

void Spi_Send (unsigned char Spi_Data)
{

m = Spi_Data;
while(index)
{
SPI_CLK_LOW;
k = (maskval & m);
while (k == 0X80)
{
SPI_SDO_HIGH;
k = 1;
}
while (!k)
{
SPI_SDO_LOW;
k = 1;
}
m = m<<1;
index--;
SPI_CLK_HIGH;

}
SPI_CLK_LOW;
}


The below scope image shows the command and CTS response transaction that does the following (Yellow Signal -> Data and Blue Signal -> Clock:

  1. Make NSEL Low
2. Send 0x44 Command -- That takes 8 Clock Cycles
3. Generate additional 8 Clock Cycle to read CTS Response
4. Make NSEL High


Below is the scope image of how I am handling the chip select between each transactions to read the CTS response (Yellow -> CS and Blue -> Clock):

We have already built the first prototype and have got this chip to work with the TI CC3200, but for some reason I am having trouble getting it to talk with the ESP8266EX. I'd appreciate if folks can please review the signals in the scope I have attached and assist/advise me as to if there is anything I am missing or, is the way I am handling the signals wrong? If we cannot resolve this issue in this week, then we may be forced to evaluate some other module, which would be sad, since we have got this chip working on our first prototype with TI CC3200.

Update 1: Please see the hardware schematics of the ESP8266EX Launcher Board Here - Jump to Page 42 to 46 for Schematics. Note that there is a 1uF capacitor connected to GPIO 13 i.e MISO line after the reset key. I have removed this capacitor, since it will not allow for SPI communication.

Update 2: I have captured the timing variations comparison between TIcc3200 and esp8266ex signals as shown below, w.r.t Si4455 SPI timing diagram above.

• I have various SPI'able components, some use different 'clock high, data high' modes, and some are programmable. Your scope traces look clean(ish) (undershoots?). Triple check the mode, and then check again. If you have anything with a programmable mode, check you are initialising correctly, rather than allowing the reset default to persist, as this may change between implementations of part, compiler, removing an 'unimportant' bit of code. All of my software 'intermittencies' have had rational causes, and most of those have been careless defaults, and unintended changes. – Neil_UK Sep 1 '16 at 8:21
• "the host MCU must put the data on the SDO of Si4455" - NO! The host must put its data on the SDI pin of the Si4455. SDO is Serial Data Out, SDI is Serial Data In. – brhans Sep 1 '16 at 11:23
• The pics shown seem to be ok. Do you have for the data from the Si4455 to the MCU? – hcabral Sep 1 '16 at 11:30
• @PsychedGuy - Some strange parts of your scope photos include: Different voltages for the clock & data signals shown on the top image; even more different voltages between chip select and clock signals in the bottom image; you chose different reference levels (the arrows on the left side of each trace), which partly hides that the clock signal has significant spikes (~0.8V) below its logic 0 level. If I had your hardware, I would be closely investigating the schematic and SPI signals to better understand why there are those (imho unexpected) differences. Can you supply your schematic here? – SamGibson Sep 1 '16 at 12:47
• @SamGibson - I had cross checked the schematics but could not find anything else connected to these lines apart from a 1 uF capacitor to the MISO line which I had removed. However, I have updated my question with the link and page number to the hardware schematics. May be you could see something that I couldn't. Just so you know, that I am using HSPI - GPIO 15 (CS), GPIO 13(MISO), GPIO 14(CLK), GPIO 12 (MOSI) – PsychedGuy Sep 1 '16 at 14:08