I’m trying to interface with my custom SPI slave board. In synchro mode I achieved normal SPI transfer, but in asynchronous mode I couldn’t get SPI read working. The problem looks like this: when I write to SPI in asynchronous mode and wait for a flag from high level IRQ - the transfer passes and I see that my SPI slave got data. When I read from SPI in asynchronous mode I get valid data but than my slave boards does not respond.
It seems that in asynchronous mode something differs: timings or delays or addressing…
Hiya,
I’m not sure what you mean by Synchronous and asynchronous SPI. Could you please elaborate a little further.
However, in my experience the following is true for a Q2686 running firmware R7.2 & R7.3:
- The Q2686 has to be the SPI MASTER (i.e. controls the bus at all times)
- The Q2686 does not handle simultaneous bi-directional SPI data (i.e. for every byte clocked out on the MOSI pin, another is read on the MISO pin). All microcontroller implementations of SPI that I have worked with WILL support simultaneous bi-directional data transfer
I haven’t pushed the R7.4 firmware yet - but when my next PCB’s come back I’ll be looking int the SPIU again.
ciao, Dave
Sorry. Seems to be bad ground. Now it is OK.
In SPI sample there is a switch from synchronous to async SPI and vice versa. Synchronous SPI waits for every transfer to complete before it proceeds the next program step so it may be easily reseted by watchdog if it is expected to read too much data. Asynchronous transfer is IRQ based and therefore it is OK to send or read large buffers of data.
I know. I’ve got a SPI slave board connected to my Q2686. BTW I’ve got R74.
Yes it is a bit weird for me. My SPI slave can read and write simultaneously, but it waits for Q2686 transfers.
Also I’d like to know is it OK to expect all zeroes or all ones on MOSI during Q2686 read? And also do you have some kind of emergency reset for unexpected desynchronization? It seems to me that every unexpected or lost byte can hang up the slave since there is no any byte synchronizations.
At the hardware level the SPI itself is, of course, always synchronous.
The “Synchronous” or “Asynchronous” here refers to the operation of the API calls- not the hardware!
As already noted:
- “Synchronous” API calls don’t return until the operation has completed;
- “Asynchronous” API calls return immediately, with an IRQ later to indicate when the operation has completed.
it mostly indicates a problem, but why not?
it’s normal to read zero-filled bytes from my accellerometer sometimes.
you’ve got chip-select for that don’t you?
if chip-select switches to -not-selected- (logic state depends on the spi-mode) communication should reset.
if chip-select switches back to -selected- the communication should start again from the beginning.
Hiya,
That’s what I thought - I thought blackyblack was referring to the SPI protocol itself - and I had missed something really major… 
Thinking back, I probably should have said ‘full duplex’, rather than ‘bi-directional’. The Q2686 SPI API only seems to support half-duplex communications. This is a major hick-up in the Wavecom SPI API.
Writing all zeros out the MOSI pin to clock data in seems to be a sane thing to do. It’s been so long since I’ve worked on that section of my code that I can’t remember what I saw on the oscilloscope.
ciao, Dave
Agreed!
Note that it doesn’t seem to be just the Q2686 - it seems to be Open-AT in general?
I meant another thing. When data is being read by q2686 it has a meaningful data on input, but what does it have on output?
Is it a default behaviour for all SPI slaves? I tried to tie chip select to ground and have not seen any differences. What is chip select behaviour from q2686 side?
I managed to transfer and print a pretty large amount of data in blocks of 0x1000 bytes for every transfer. It seems that block size is limited only by the receive buffer which is limited by task stack size. But still there is some lack of synchronization in opcode-address-data protocol - on 9th transfer I’ve got a buffer filled with a single symbol and needed to reset SPI slave state.
Since Q26 supports Master only, the CS is always generated by the Q26 (or not used at all)
chip select is active low.
it is generated on the pin that you designated in the adl_busSPISettings_t
I know that it is master and it is active low by default. I want to know is it active during all read sequence or is it active during each byte and inactive between them.
i can’'t remember exactly, but i think that it’s active during the entire transaction. (haven’t got my test equipment around at the moment)
Yes - it is.
as it should be 
(but with wavecom 
)
Hiya,
I’ve never seen a SPI slave device where you can tie the chip select low and leave is that way.
I seem to recall that the Q2686 pulls the chip select low at the start of the transaction, and raises it again when the transaction is complete.
In my code, I do the following each time I access the bus:
- subscribe to the bus [adl_busSubscribe()]
- set the bus IO state [adl_busIOCtl()]
- read/write to the bus [adl_busRead()]
- unsubscribe from the bus[adl_busUnsubscribe()]
ciao, Dave
if you’e only got one device on your spi-bus, and the device is not likely to be removed from the bus you can leave the subscription active for as long as your wcpu remains active.
(that’s the way i’m using the two spi-busses on my q2686)
Looks like proper Full-Duplex is still not supported: Can Open-AT do *Full* Duplex SPI yet? 