SPI bus signals - Problems during read


This regards the spi bus access on the Q2686 module. I’m trying out with simple routines, reading and writing a single byte to and from the spi bus. At the same time I’m observing the signals; spi_in, spi_out and spi_clk with an oscilloscope.
My busSettings are as follows:

adl_busSPISettings_t SpiSettings =
        5,				// Clk_Speed    (5 = 2 MHz)
        ADL_BUS_SPI_CLK_MODE_0,	// Clk_Mode;
        ADL_BUS_SPI_ADDR_CS_NONE,	// ChipSelect;
        ADL_BUS_SPI_CS_POL_LOW,	// ChipSelectPolarity;
        ADL_BUS_SPI_MSB_FIRST,		// LsbFirst;
        0,		                                // GpioChipSelect;
        ADL_BUS_SPI_FRAME_HANDLING,	// WriteHandling;
        ADL_BUS_SPI_DATA_UNIDIR	// DataLinesConf;

and my busAccess structure is:

adl_busAccess_t SpiBus_Access = 
      0,                                           //Address
      0,                                           //Opcode
      0,                                           //Opcode length
      0,                                           //Address length
      ADL_BUS_SIZE_BYTE              //bit size on the bus

I’ve disabled the cs signal in the above, but I’ve also tried with GPIO cs signal active.
During the adl_busWrite(…) everything seems to be normal, as I recognize my data byte on spi_out and 8 clock pulses on spi_clk. But during the read function; adl_busRead(…) it seems to me that on the spi_clk, the 8 clock pulses for reading 1 byte, seems to be repeated with a small delay of appr. 3 usec for spi_clk = 2MHz. This is always the case, even when I try to read 2 bytes, the 16 clock pulses respectively are repeated again.

Are there any comments on this one?
Is it just the way I configure my busSettings?

With regards


I notice the same strange behavior during adl_busRead. The communication with the CPU which worked in a few previous projects based on Q2406B doesn’t work now!!!



I have exactly the same problem. Interval between the 2 repetitions is 35 µs @ bus speed 812 kHz… Any word from Wavecom when this will be fixed?


Appearantly, this is TT anomaly CUS37898 and added to the next 6.62a MSD. Hopefully it’ll be out soon…

Best Regards,