Why do I get ACI_STATUS_ERROR_INVALID_PARAMETER for every command I send?

[MikeO]

I am communicating with the nrf8001 via SPI, from an HCS08 MCU. First thing I receive:

0x01 0x04 0x81 0x02 0x00 0x02

This makes sense, it tells me it is in setup state. I want to put it into test state, specifically for testing the ACI. So, I transmit:

0x02 0x01 0x02

I get acknowledgements of 0x00, 0x01, 0x00. Then, I receive:

0x01 0x03 0x84 0x01 0x85

According to the datasheet, this is an error, due to an invalid parameter. Okay, next I transmit an echo command:

0x04 0x02 0x47 0x48 0x49

I expect it to either tell me that it is in the wrong state, or, by some miracle, return the last three bytes. I receive:

0x01 0x03 0x84 0x01 0x85

Invalid Parameter. I have tried sending it various commands, even those with no parameters, such as the GetDeviceAddress (0x0A) or GetTemperature (0x0C). Yet, every time, I receive the same error: Invalid Parameter.

What could I be doing wrong?

[David Edwin]

You seem to have successfully received the Device Started Event stating that the device is in setup mode. However when you sent the Test command (0x01) , the command has failed. The failure is clear from the Command Response Event that is received for the Test command.

We need to understand why the test command failed. Can you send me the chip markings on top of the nRF8001 and the nRF8001 board that you are using.

Unexpected things noticed:

1. The nRF8001 is reponding with (0x01 0x03 0x84 0x01 0x85) to the echo command, and by looking at the SPI message received (command Response Event) the nRF8001 seems to think that the test command was sent. This would appear that no further commands are possible and only a pin RESET can be used to proceed and re-attempt the Test command again.

Actions requested (summary):

As @run_ar has suggested an SPI trace of the nRF8001 would be nice.

In addition mention the lines that you are using between the HS08 and the nRF8001 and Mention the SPI clock speed that you have used

Chip markings on the nRF8001 and the nRF8001 board used.

[MikeO]

The markings on top of the chip are: NRF D 8001 1429SH

I am using the MikroElektronika BLE P click board.

My master generates a clock of 2MHz (verified by oscilloscope).

nrf8001 MC9S08QE8

• RESET ==> Port A, Pin 2
• RDYN ==> Port A, Pin 3
• REQN ==> Port B, Pin 5 (SS)
• MISO ==> Port B, Pin 4 (MISO)
• MOSI ==> Port B, Pin 3 (MOSI)
• SCK ==> Port B, Pin 2 (SPSCK)

If you would like a full circuit diagram, I would be happy to provide it.

I am sending and recieving these messages through scratch-built C code

I have not tried resetting the nrf8001 after I receive the error and before sending the new command.

[MikeO]

Here is a log of sent and recieved bytes:

sent recieved

1. 0x00 0x00

2. 0x00 0x01

3. 0x00 0x04

4. 0x00 0x81

5. 0x00 0x02

6. 0x00 0x00

7. 0x00 0x02

8. 0x02 0x00

9. 0x01 0x01

10. 0x02 0x00

11. 0x00 0x00

12. 0x00 0x01

13. 0x00 0x03

14. 0x00 0x84

15. 0x00 0x01

16. 0x00 0x85

17. 0x04 0x01

18. 0x02 0x01

19. 0x47 0x00

20. 0x48 0x00

21. 0x49 0x00

22. 0x00 0x00

23. 0x00 0x01

24. 0x00 0x03

25. 0x00 0x84

26. 0x00 0x01

27. 0x00 0x85

[David Edwin]

I would like you to verify that you are indeed starting the SPI clock only after the RDYN goes low. You will get odd SPI issues if you do not follow that constraint properly. The first byte from the nRF8001 is a debug byte and can be safely ignored so long as the SPI clocking is happening at the right time i.e. REQN and RDYN are both low.

[MikeO]

I checked on my oscilloscope, the clock starts and stops while both REQN and RDYN are low. I have never seen it being generated while either signal was high. What data should I be getting back from the nrf8001, while the master is transmitting? I get seemingly random bytes that are either 0x00 or 0x01. Are 0x01s ACKs and 0x00 NACKs?

[David Edwin]

The first byte from the nRF8001 is a debug byte to see if the SPI buffer in the nRF8001 was correctly handled. It is actually reflecting an internal hardware state and should be ignored. Lets try a different path and send a Setup command (0x06) after the device stated event and see the behavior (i.e. is it different from the Test command). I have linked to a services.h file for the Setup Command. Line 106 in the services.h shows the Setup command. 0x07,0x06,0x00,0x00,0x03,0x02,0x42,0x07 .