services setup nrf8001

RE: services setup nrf8001

user123x — Mon, 17 Oct 2016 19:30:43 GMT

Kind Reminder !

I have been able to get a standby message after feeding the nRF all the Setup data. However after that I can not detect the BT signal. I have tried all kinds of telephones. Have I missed out something. Please find the setup attached. 3.xml

RE: services setup nrf8001

user123x — Sat, 15 Oct 2016 06:57:09 GMT

I was able to get a standby response from the chip after the setup packets were all successfully accepted by the nrF80001. However I am still not able to detect the nrf8001 on my andriod mobile using the nrf connect app ?

RE: services setup nrf8001

user123x — Fri, 14 Oct 2016 19:28:47 GMT

You are right. The two files have different data. It worked. Eureka ! Regards

RE: services setup nrf8001

user123x — Fri, 14 Oct 2016 17:22:12 GMT

.........................

RE: services setup nrf8001

David Edwin — Fri, 14 Oct 2016 16:08:35 GMT

Did you get the Setup messages from services.h or services_lock.h ? If you used services_lock.h they are written to OTP on the nRF8001. Since this is OTP (one time programmable) you have used up the OTP portion to store Setup. However you can still store Setup in the RAM even when you have Setup in OTP. Just make sure that you use the messages from services.h

RE: services setup nrf8001

user123x — Fri, 14 Oct 2016 14:18:14 GMT

I was able to get all the setup packets to feed with 0x01 status one after the other. However in response to the last (11th) packet I get the following:

01, 03, 84, 06, 8B, 83, 39, 2E,

0X8B means : Setup data is locked and cannot be modified.

Does any one know why this comes up. Have I locked up some thing by error ?

As I understand from:

devzone.nordicsemi.com/.../

Some how a second stand-by signal should get generated at some point (starting or end of the setup), when the flash gets written to. However I am not able to see the second standby signal ?

Thanks and Regards

RE: services setup nrf8001

David Edwin — Wed, 12 Oct 2016 08:14:18 GMT

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.

RE: services setup nrf8001

user123x — Tue, 11 Oct 2016 20:21:28 GMT

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

RE: services setup nrf8001

David Edwin — Tue, 11 Oct 2016 11:27:16 GMT

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.

RE: services setup nrf8001

user123x — Tue, 11 Oct 2016 10:36:48 GMT

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:

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 :

Pull SS Low and send a packet
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.

RE: services setup nrf8001

David Edwin — Mon, 10 Oct 2016 09:48:06 GMT

[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.