• State Not Answered
  • Replies 2 replies
  • Subscribers 62 subscribers
  • Views 1407 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 105853
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF8001 Setup Question

carabia

Hello,

Working on my own code to integrate an arm chip with the nRF8001, after I read the device status, which says it's in Setup-mode, I'm sending the setup configuration to the device, as specified in services.h generated by nrf go studio. First I'm sending:

0x07,0x06,0x00,0x00,0x03,0x02,0x42,0x07 Which is 8 bytes (the first line in the setup msg array)

Then I'm sending: 0x1f,0x06,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x00,0x00,0x06,0x00,0x06,0xd0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

  • which is 32 bytes. (second line)

Note: Between each packet I cycle CS high/low.

After the first packet is sent, when I'm sending the 2nd one, I should be getting a confirmation during the transaction from the nRF, am I correct? However I get nothing. Instead, after sending the 2nd packet, I cycle CS high/low, but RDYN stays high for 39 ms, which seems to be unusually long. After that, I'm sending the 3rd packet and then I get a response, which says to continue the transaction.

I continue on to send all the packets (20 in total), after which RDYN stays up for 83 ms after which, it sends another TRANSACTION CONTINUE.

I can provide the logic trace is necessary, any help is appreciated, Thank you in advance.

  • 0

    I would suggest that you first verify your SPI driver by sending the Echo command and then verify that the Echo Event arrives. Do this for varying length echo commands so you verify your driver first.

    Send the Test Command. Wait for the Device Started Event with the nRF8001 in Test state. Send the Echo command and verify the Echo Response Event.

    Once you verify this you can attempt the Setup sequence.

  • 0

    Has there been an update/breakthrough on this issue? Did the above suggestion help clear it up? I'm seeing a similar issue and I'm wondering if this is timing related????

    I ported the Arduino driver over to TI's Tiva C microcontroller series and it is working just fine. I'm using freeRTOS and the BLE driver has its own task. Everything is working just fine, no issues at all. That is, until I add more tasks. That's when I run into the same issue as above. If I don't start all tasks, it works again. This tells me that this is not a driver issue (the BLE task is the only one that has access to the SPI interface), but rather a timing issue. However, this is odd and sort of unexpected as the actual SPI transactions happens in the ISR.

    It sounds like you're using your own driver implementation for the nRF8001 and NOT the provided library? When I stepped through the code I found that the device actually returns error status 0x83 (Device State Invalid) and I think a few other 0x8X errors. The driver keeps sending the rest of the messages but will return with an error code. The main loop will then pick up the "Continue Transaction" status that are triggered by the few messages that are accepted by the chip.

    Another thing I wanted to bring up is that there is a comment in the driver library that mentions the need of a delay when you fill the driver's buffer. I've increased this to no avail, but it's worth looking into it (if you're using the Nordic library).

    I'm really curious what the solution to the above state problem was and I am willing to collaborate on a solution.

Related