• State Verified Answer
  • Replies 18 replies
  • Subscribers 63 subscribers
  • Views 4885 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125520
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

  • 0 in reply to David Edwin

    I tried 0x07,0x06,0x00,0x00,0x03,0x02,0x42,0x07. I received the same event: 0x00, 0x01, 0x03, 0x84, 0x01, 0x85.

  • 0 in reply to David Edwin

    odd, this means 0x00 (ignore the first byte), 0x01 -> length of 1 byte , 0x03 is an event opcode but 0x03 is not an valid event opcode, so this does not make sense. Since the length byte is 0x01 only one byte is part of the ACI packet.

    Is the RDYN line still low after this message , indicating more messages are available ?

  • 0 in reply to David Edwin

    As per the log above, I do get strange 0x00s preceding the debug byte, when receiving. This being said, I set my software to pick up the length from the 3rd byte, in that case. When I do that, the events I receive make perfect sense. Could that be a symptom of the problem?

    The RDYN goes high after 0x85 is received. However, I did try reading, after that. So: transmit, receive, receive. Strangely enough, it sends me 0x01, 0x01, 0x03, 0x84, 0x01, 0x85. The event is the same, except for the mysterious first byte.

    I am thinking that it is possible that it thinks the first 0x00 sent during the read cycle is part of the previously transmitted message from the master. However, how could that be when the read cycle only happens if RDYN is low before REQN. My write cycle only begins when RDYN is set high.

  • 0 in reply to David Edwin

    In fact, I tested putting read cycles in an endless loop after the write cycle. It keeps sending me the same message, over and over. RDYN goes high, after the final 0x85, every time. Yet, after the message is done, it goes low again. Shouldn't it remain high, waiting for the master to transmit new data?

  • 0 in reply to David Edwin

    The extra byte in the front is definitely not normal, so yes, I would suspect it to be part of the symptoms. Can you verify the SPI settings: SPI Mode 0, LSBit first, drop clock speed to 1MHz, verify that the SPI transaction occurs only when the RDYN and REQN are low.

    SPI transactions when the RDYN, REQN is high is undefined and should not be done as the SPI buffer would not be ready.

    If the RDYN goes low after you have transmitted, it means that the nRF8001 has a message for the MCU to clock out.

Related