BLE ACI verification

[SYonekura]

Hi, i'm kinda a newbie on this, and i'm trying to port the SDK available for arduino to a PIC, i followed the instructions on the SDK and also here

Now i want to verify that my code is alright by running the ble_aci_transport_layer_verification, but the if statement in the loop function never triggers due to "aci_queue_is_empty" always returns true (aci_q->head == aci_q->tail).

On the other hand, the setup funcion calls aci_queue_init (via hal_aci_tl_init), but this function sets aci_q->head and aci_q->tail to zero. I debugged the rest of the program one line at a time and no other function modifies those values.

So, I'm starting to think that maybe there is a bug on the code, i hope somebody could help me pointing out where the aci queue is initialized (or if i should write a call to aci_queue_enqueue somewhere), thanks in advance

[David Edwin]

Can you check with an logic analyzer on the SPI to verify that the hardware connections are ok. If no messages are coming over the SPI, this is the normal behaviour.

Do a simple test: Do a pin reset of the nRF8001 - Section 14.4 on the nRF8001 datasheet You should receive a Device Started Event from the nRF8001 about 62ms after the reset. Verify that your code on the PIC has got this event.

See section 7.1.5 of the nRF8001 datasheet for the Events on the SPI lines.

[SYonekura]

thx for the info. i did the test and i still don't get any event signal.

i also checked with a logic analyzer and there are communication between pic and nRF8001, but no one of the packets received have an event code (0x8X)

[David Edwin]

Can you post whatever you received ? The Events have a debug byte in the front, followed by the length and then the Event code. See Section 7 in the nRF8001 datasheet.

[SYonekura]

the most typical was: 0xAC 0x00 (just that)

i read the datasheet again and did some changes to the code, in particular i commented some lines (hal_aci_tl -> m_aci_event_check):

    // If the ready line is disabled and we have pending messages outgoing we enable the request line
  if (HIGH == !digitalRead(a_pins_local_ptr->rdyn_pin))
  {
    //if (!aci_queue_is_empty(&aci_tx_q))
    //{
      m_aci_reqn_enable();
    //}

    //return;
  }

Since "devide started" its an event, if rdyn is set low by nRF8001 then reqn should be set low too and then start the SPI communication (this was not happening because of the return statement)

Now i get this package: 0x01 0x04 0x81 0x02 0x00 0x02. Clearly more familiar with the nomenclature specified with the datasheet, but i'm not sure if that changes would cause some overflow or another bug afterwards.

[Nico]

I'm also struggling with a similar problem and have started by porting the MSP430 example to a PIC32, the one that only puts it in UART test mode. It does spit out the 0x01 0x04 0x81 0x02 0x00 0x02 start event but followed by 26 bytes of 0x00 then a 0x07 or 0xD7 randomly. I think it's not nabbing the length packet properly (I'm bit swapping LSB in software as there's no HW support). My problem is an aci buffer overflow.

I'd be very interested in your complete code if you made any headway to build from as I was going to migrate to PIC18.

On a side note it would be fantastic if nordic provided more than an arduino example to build from