Slow set up with nRF8001 on custom board

[Kieran]

We have recently moved to a new PCB which puts the nRF8001 on the layout instead of plugging into a nRF2741 development module. The nRF8001 connects to a TI Cortex-M4 Tiva MCU (previously a TI Cortex-M3).

Two issues have now arose. In the setup stage the RDYN line is held high for 1s after the nRF8001 sends a Command Response Event to the Setup system command (0x06). Setup completes successfully, but takes a lot longer than it did with the nRF2741 module.

The second issue is that the 16mhz clock often momentarily gets pulled low every few ms. Similar phenomenon was seen on the development kit, but the effect is now far more pronounced.

The code used on both boards is functionally the same and is adapted from the HID mouse example. I've attached an screenshot of the ACI lines for the transmission of one setup packet and response (i.e. what happens every 1s).

[Kieran]

Thanks! I've just made a change to my code to get responses to work off an interrupt instead of looping round hal_aci_tl_poll_rdy_line, this hasn't helped noticeably so I'll try a full integration of the driver you've provided.

[run_ar]

Hi,

There is a design limitation in the firmware of the nRF8001. The limitation will cause the nRF8001 to delay servicing the REQN line when it goes low. This will cause the RDYN line to be delayed by up to 1 second. It is also possible for the delay to be lowered by the connection or advertising interval when the radio is running. Example: If the service of the REQN line is delayed when in a connection with a connection interval of 25 ms. The RDYN can be delayed by 25ms.

Issue:

1. After clocking out, the data REQN is set high to indicate end of data.
2. The RDYN line will follow and will be high
3. Setting the REQN line low 110-125 us after the REQN line goes high will cause the nRF8001 to delay servicing the REQN line.

Workaround: The workaround is to set the REQN line low outside this 110-125 us window.

As Tie Fighter suggests, you can change the driver to avoid this problem as an interrupt based system can be more deterministic on the width of the REQN line.

Best regards, Runar

[Kieran]

Added a small delay to the REQN line being pulled low and that's reduced the setup time from 20s to 300ms! Excellent, I'll just work on neatening up the fix. Thanks for the help.

[TIE Fighter]

There is a queue for the ACI commands so you can place the ACI Setup commands in the queue until the queue is full, as the queue gets processed keep filling it up. You will get a command response event for every Setup command that has been processed, so add a Setup message for every command response that is arriving. Keep doing this until the nRF8001 sends a Command response event with Transaction complete.

In the code in hal_aci_tl.c

//If there are more ACI commands in the queue, //lower the REQN line immediately if (false == m_aci_q_is_empty(&aci_tx_q)) { // Set request pin low to indicate to //nRF8001 we want to send data //will prevent the delayed Setup commands that you are seeing SET_REQN_LOW(); //Wait for the interrupt handler to execute when the RDYN //goes low again }

This should make the Setup run without any delays.

[CCommander]

How can I get started with this driver? I have no clue, what I have to do to create a BLE service and start advertising.