services setup nrf8001

[user123x]

Services Setup

I am trying to feed the "Services Data" manually to the nRF8001.

As per the data sheet page 82 (see image below): Upon transmission of 1 packet of data an ACI_Transition_Continue should get generated: (i.e. some where a )"0x01" should get popped back to the Controller. If this is received then the controller should send out more packets, till the setup is complete.

Now the first packet that I send out (after the nRF has been confirmed to be running is the standard packet:

{0x07,0x06,0x00,0x00,0x03,0x02,0x42,0x07};

The response is as follows:

As you can see the sent in bytes just get echoed and there is no "01", instead I can see a "00" at the beginning (dont know if this means success ?).

In the next packet I sendout:

 {0x1f,0x06,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x00,0x00,0x06,0x00,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,};

Again, I assume this is a standard setup paket.

The result is 30 times "00". Same with all following messages.

Is there some thing I am doing wrong ? SPI is working without a problem and when I try to do ECHO every thing works fine.

I would be much obliged to you get your help.

[David Edwin]

[Edited]

What do you mean by feeding the setup data manually, You are taking the generated setup data from the nrfgo studio generated file "services.h" and then sending the setup messages one by one.

Remember the ACI Event for your command will not be immediately sent (see section 7.1.6), so the SPI transactions during setup, typically look like this.

Slow method for nRF8001 Setup

Transaction 1: Lower REQN :: Wait for RDYN to be low :: ACI Setup command 1 clocked out from SPI master ::: 0 length packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction 2: RDYN is low signalling an ACI event :::: Lower REQN :: 0 length packet clocked out from the SPI master :::: ACI Event clocked in from the nRF8001 (Transaction continue) :: Raise REQN, RDYN will go high

Transaction 3: Lower REQN :: Wait for RDYN to be low :: ACI Setup command 2 clocked out from SPI master :::: 0 length packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction 4: RDYN is low signalling an ACI event :::: Lower REQN :: 0 length packet clocked out from the SPI master :::: ACI Event clocked in from the nRF8001 (Transaction continue) :: Raise REQN, RDYN will go high

........

Transaction 2N-1: (Where N is the number of Setup commands) Lower REQN :: Wait for RDYN to be low :: ACI Setup command N clocked out from SPI master ::: 0 length packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction 2N: (Where N is the number of Setup commands) RDYN is low signalling an ACI event :::: Lower REQN :: 0 length packet clocked out from the SPI master :::: ACI Event clocked in from the nRF8001 (Transaction Complete) :: Raise REQN, RDYN will go high

Faster Method for nRF8001 Setup

The nRF8001 has buffers available for a few commands so it is possible to burst the Setup commands until the buffers are filled up. The buffer availability is signalled by the RDYN line and will act as the flow control for the Setup. You can use fixed SPI clocks of 32 bytes but the ACI packet itself should be unmodified.

Transaction 1: Lower REQN :: Wait for RDYN to be low :: ACI Setup command 1 clocked out from SPI master ::: 0 length packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction 2: Lower REQN :: Wait for RDYN to be low :: ACI Setup command 2 clocked out from SPI master ::: 0 length or ACI Event packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction 3: Lower REQN :: Wait for RDYN to be low :: ACI Setup command 3 clocked out from SPI master ::: 0 length or ACI Event packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

........

Transaction N-1: Lower REQN :: Wait for RDYN to be low :: ACI Setup command N-1 clocked out from SPI master ::: 0 length or ACI Event packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Transaction N: Lower REQN :: Wait for RDYN to be low :: ACI Setup command N clocked out from SPI master ::: 0 length or ACI Event packet clocked in from nRF8001 :: Raise REQN, RDYN will go high

Track the ACI Events so that you get the Transaction continue and Transaction complete. The faster method will reduce the number of transactions.

Action requested: Attach a logic analyzer trace to verify that you are following the handshake rules on the SPI.

[user123x]

Dear David, Thanks for your kind response. I got some of what you said and some of it has confused me a bit:

SPI Communication with the nRF8001:

1. The exchange of the BITs in SPI will occure synchronusly. Therefore as soon as the SS is low and the RDY is low (i.e. a hand shake is signalled), the Master can start sending in bytes.

As I observe: The RF8001 generates response and sending out the responses without waiting for the packet to come to an end. i.e. a sort of full duplex communication happens.

Now what you are suggesting is :

1. Pull SS Low and send a packet
2. Then wait for RDY to go low and send in 32 times 0x00 and read the response.

However as I observe, as soon as I pull the SS low the RDY also goes low. Is there some thing I am missing.

I am much obliged for your excellent support to me on this matter.

[David Edwin]

I edited it and expanded it to be more clear as I did not do the explain the states of the REQN and RDYN in every transaction. In the Setup State, when the REQN is pulled low the RDYN will almost immediately follow if it has the buffer available to receive the incoming SPI message. Yes , it is full duplex when the SPI is running , I am asking to to slow it down , that I is why I mentioned it as a the slow method, once we have got that working you can then speed it up.

I have clarified, so take a look at it again, you always need to have RDYN low before you can start the SPI clocking.

[user123x]

Dear David,

Your responses are precise and learned. My complements for you. The method that you describe above works. The LA traces also confirm it. Understandably, my next question is, how it is possible to read the data from a fully duplex communication:

In full duplex mode (Fast Method) the entire setup data (services settings) would get pumped into the nRF via the MOSI in one go, while almost parallely the "event data" (response) bits would get pumped back into the µC via the MISO line.

Therefore, my question is, how would it be possible to seperat the individual event bits from each other to descipher them. Ofcorse, I assume this is done in software, however I can not seem to be able to conceptualise a method to seperate one packet from the other, esp when we dont know exactly how long each individual event (response) packet could be ?

Your comment on this is most appriciated. Additionly if you could guide me to some literature which explains more on how to manage such fulll duplex communication, then I will be much obliged.

Regards

[David Edwin]

I have edited my answer to add a faster method of transacting with the nRF8001. The setup commands are packet based so they need to sent packet by packet i.e the REQN line has to be raised and lowered as packet delimiters.