This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Slow set up with nRF8001 on custom board

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

http://i.imgur.com/vbMa90N.png

Parents
  • I have attached a nRF8001 driver for the TIVA, this uses an interrupt on the RDYN line to process all commands to the nRF8001 and is quite fast. You should not see any delays in processing the setup command with this deiver. You can also modify the driver, so that the interrupt just sets a flag and the flag can be read out from the main context. The driver currently only implements Test, Echo commands and uses the 2 commands to verify that the SPI is running correctly. This diver also uses a queue for the ACI commands and ACI events. so the calling function can return immediately.

    nRF8001-TIVA.zip

Reply
  • I have attached a nRF8001 driver for the TIVA, this uses an interrupt on the RDYN line to process all commands to the nRF8001 and is quite fast. You should not see any delays in processing the setup command with this deiver. You can also modify the driver, so that the interrupt just sets a flag and the flag can be read out from the main context. The driver currently only implements Test, Echo commands and uses the 2 commands to verify that the SPI is running correctly. This diver also uses a queue for the ACI commands and ACI events. so the calling function can return immediately.

    nRF8001-TIVA.zip

Children
  • 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.

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

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

Related