From Q2687 to Q2698 SPI problems

i was upgrading my Open AT application from Q2687 Module to the newer Q2698
using a 7.52 A1 beta firmware release.
This software make use of the spi_1to communicate with a connected SD card.
While on the previous module the same code it’s doing good and the SD card is responsive,
on the Q2698 i can’t receive nothing on the SPI In pin (the cards does not initialize).

Reading the Q2698 manuals, i’ve done the following changes to accomplish the job:

  • changed the CS (spi_1) Pin from GPIO 31 to GPIO19.
  • changed the adl_busSettings_u->clk_speed from 0 (13Mhz on Q2687) to 15 (12.xx Mhz on Q2698)

but never seen any spi in data coming out the SD card.

Observing the waveform using an oscilloscope w 3 probes i can see those differences between the old and the new module:

  • When using adl_busWrite command on the Q2687 electrical level is mantained in High level state until just before the clock begins to pulse then writes data. On the Q2698 is in Low level state until just the clock begins.
  • on the Q2687 the clock pulses are very regular and syncronized perfectly with data line, on the Q2698 there are clock pauses between every byte written even i’m using a adl_busWrite command with 6 or 8 byte stream.
  • at lower clock rates (250khz, 500khz) data loss have been observed (3 byte written on 6 byte write command).

note: if you need Oscilloscope images i can send them.

could you investigate on this strange issues?
Thank you in advance.

i’ve taken 4 pictures of the “problem” from my oscilloscope.
There are 3 probes connected:

Yellow line - Spi1_Out (to the SD card)
Blue Line - Spi1_ClK
Violet Line - Spi1_CS

The first two are taken from the Q2687 sending the first initialization command to the SD Card. The command,
as you can read, is 0x40 0x00 0x00 0x00 0x00 0x95 , 6 byte long. This command is accepted from SD card correctly (we have response on the spi1_in after the command).
The latter are taken from the Q2698, and are in evidence the pauses between byte transfers (command is passed as a 6 byte buffer to the adl_buswrite function) and the strange electrical level of the clock.
In this case the SD remains in is hiberantion state and does not answer data to subsequent clock pulses.

cannot upload more photo, see next post…

hope this could be of help.


Just a thought - have you got your logic level translation right? The Q2898 has 2V8 SPI I/O, and off the top of my head a SD card is 3V3.

Also, are you using SPI1 or SPI2 - SPI2 is shared with UART2 and only one can be active at any one point in time.

ciao, Dave

hi Dave,
thank you for your answer.
As you can see from images (1V scale), ever the q2687 module uses the 2V8 spi levels to communicate with SD card, and do it good.
I’ve tested various SD-Cards and are all 2V7 to 3V6 tolerant as seen from specification sheets.
On the Q2698 module have tested spi1 at first (images above), then the spi2 disabling the Uart2 (at+wmfm command=0,0,2 and not subscribing with fcm with adl command any uart2).
The diagrams of the spi2 protocol are level and time comparable to those of spi1.

Please note that Q2698 only supports a lower current on 2.8V GPIO pins than Q2686/Q2687
IOH (I out high ) is specified at 150uA for 2.8V GPIO. (Q2698 PTS, section 4.2)
If there is too much load on these lines, this could at least explain the signal waveform.

I don’t tink it’s a current issue, the next picture shows pins status captured directly with Oscilloscope probes without SD attached to them.
The levels are comparable to the previous.

Hi radmaster,

Have you found any solution?

I’m having the same issue
but think I’ve found my problem
seems it is the low level idle state of the SPI data output line during the read operation
on Q2687 it is held high, while on Q2698 it is held low

and my current solution for Q2698 is in sending few spare 0xFF bytes before any command – after doing it I’m getting the correct response from the SD card

hope that will be helpful for you

I did not found how to change the idle state of the data output line
it is also a shame that is not possible to read during the write operation