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

The nRF52832 received an error packet with crcok and length wrong.

Hi all,

   When I do some tests on chip of nrf52832,the chip sometimes receive an error packet: the crc status is ok,but the length field is random.The reference  documents shows:If the payload plus add-on length is specified larger than MAXLEN, the RADIO will still transmit or receive in the same way as before except the payload is now truncated to MAXLEN. The packet's LENGTH field will not be altered when the payload is truncated. The RADIO will calculate CRC as if the packet length is equal to MAXLEN.That means if a large  random data is received,it wii be trunctaed and calculate CRC as if the packet length is equal to MAXLEN.Obviously,in that case  the CRC is rarely ok.

 Does the radio calculate crc accoding to the LENGTH field when it receives a normal packet?Does  the LENGTH field  decide the number of bytes payload received ?

Parents
  • Hi

    Assuming the value in the LENGTH field is less than or equal to MAXLEN the length of the incoming payload and the CRC calculation should be based on the value of the LENGTH field, yes. 

    What is the size of your CRC field and your address?

    Unless these are short it should be extremely rare to have a packet with errors that pass the CRC test. 

    Best regards
    Torbjørn

  • Hi,

       Thanks a lot!From the datasheet:after the whole packet including the CRC has been received, the RADIO will generate a CRCOK event or CRCERROR event.1.Does the radio calculate the CRC while receiving one byte by another or untill all the bytes are recieved ?

    2.Does the radio receive bytes of payload according to the  LENGTH field?

    3.The s0, length,s1 and payload is moved to the somewhere in data ram according to the PACKETPTR,however the preamble, address,and crc is kept to where? How does the radio distinguish these fields?For example, how does teh radio distinguish adress from the rest of the fields?Because only  s0,length,s1,payload and crc can be accessed.

    4.CRC, Address match, Packet disassembler and other process are dealed after the whole packet is fully received?What does the address event indicate?Just the bytes of address bytes are received?And where are these bytes kept?I once thought the address event indicated the address match or not but the fact was obviously not that.

    5.Does easy dma move every  byte to somewhere in data ram while receiving?If so, is the time of tx_end  the same as the rx_end except  the subsequent CRC, Address match and so? 

  • Hi 

    Regarding 1. CRCOK/CRCERROR will actually happen one 16MHz clock cycle before the END event, not after as I predicted. 

    Best regards
    Torbjørn

  • Thank ou very much!I'm using nrf52832 in our future products and a private protocol instead of bluetooth.So I need more details about the chip to get a better firmware.Thank you again for your kind and exhaustive descriptions.

  • Hi,

      Thanks a lot!

    1.CRCOK/CRCERROR will actually happen one 16MHz clock cycle before the END event, not after as I predicted.

    Yes.

    2.Do you mean what happens if there is a bit error in the LENGTH field that makes the length larger than intended?

    If this happens the radio would receive a number of bytes equal to MAXLEN, check the CRC, and see that the CRC check fails because of the bit error in the LENGTH field.
    Yes in the case that a bit error in the LENGTH field that makes the length larger than MAXLENGTH(as the datasheet shows).
    Sorry for my description.I also need to confrm that: when a bit error in the LENGTH field that makes the length shorter than MAXLENGTH,does the radio decide to receive the bytes of the payload acooording to the "wrong"LENGTH ?Of course teh crc wiil be error in both above two cases.

    3. "On tx side,the addresses are stored in the BASE0, BASE1, PREFIX0 and PREFIX1 registers.But where those are stored when receiving?"

    The receiver has the same registers as the transmitter. If the packet sent from the transmitter has an address that matches one of the addresses configured in the receiver it will trigger an address match event, and the rest of the packet will be received. If you haven't configured the address registers correctly in the receiver then the packet will not be received.
    Yes.

    "or stops receive when address does't macth?"

    It doesn't stop reception when the address doesn't match, it keeps listening for a valid address.
    Agree with it!Sorry for my poor description.Need to confirm that:when the radio receive an invalid address, it will enter rxidle state.Once we trigger a start task or make it in continuous rx mode, it will enter rx state and listen for a valid address again.Right?

    4. "Address match occurs immediately after the reception of a valid address.-->Only when address match,the radio will trigger an address event ?Or will trigger all the times just after receiving an address no matter it matces or not? "

    It is important to understand that the radio doesn't know when it is receiving an address, or when it is just receiving random noise from the air. Any bit coming into the radio could be the start of a valid address, and the radio simply has to check every single bit and match it to the preceding 16-40 bits to see if they match the address that you have configured.

    With a bitrate of 1Mbps this happens one million times every second, which means every second the address matcher have to "discard" one million potential addresses until a valid address is found.

    You can imagine the address matcher as a shift register that all the incoming data is passed through, and as soon as the entirety of a valid address is shifted into the register it will trigger a match.

    "When the received address is beyond the logical address(perhaps a wrong address),how does the radio deal with it?Just discard it ?What is the value in the RXMATCH register?"

    It ignores it, and doesn't change any registers. As I described above this will happen a million times a second when the bitrate is 1Mbps, so it is a very common occurrence.
    Absolutely!
    PS: there is no address macth event in the radio event registers.EVENTS_DEVMATCH is perhaps not the address macth event you mentioned and ENENTS_ADDRESS just indicate that teh radio has received an address(no mattter it is valid or not).So teh address macth event is just referring to ?

    5. "When the tx side send all the bytes and an end even occurs,does the rx side happens to receive all the bytes or an end event occur?"

    I am not sure I understand the question. If the packet is successfully received by the RX then the ADDRESS, PAYLOAD and END events on the receiver will happen shortly after the ADDRESS, PAYLOAD and END events on the transmitter. There will be a small delay caused by the travel time of the radio packet and the delay in the receiver chain, but this is just a couple of microseconds.
    Yes, only take the rx chain delay in mind(only 5 us in 2Mbps) .

    "Does the tx always begin to send packets when tx start task s triggered?In what occasons the radio will not begin to send?For example,the air environment is not good."
    The radio is half duplex, and can not receive and transmit at the same time.
    Unless the transmitter is in the wrong state (like if it is already in the middle of transmitting a packet) then it will start every time. The transmitter doesn't care about the RF environment, since it has no way to know what is happening on the air when it is in transmit mode.
    That means: the radio will always send the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?
    Is it the same as the rx side?The radio wil always begin to receivte the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?

  • Hi

    "Sorry for my description.I also need to confrm that: when a bit error in the LENGTH field that makes the length shorter than MAXLENGTH,does the radio decide to receive the bytes of the payload acooording to the "wrong"LENGTH ?Of course teh crc wiil be error in both above two cases."

    Yes. The receiver has no way to know if the LENGTH is right or wrong, so it just has to assume that it is correct. 

    If the length is incorrectly too short it will receive the number of bytes according to the incorrect length, and then receive what it thinks is the CRC. Once it does the CRC check it should get a mismatch, and discard the packet. 

    "Agree with it!Sorry for my poor description.Need to confirm that:when the radio receive an invalid address, it will enter rxidle state.Once we trigger a start task or make it in continuous rx mode, it will enter rx state and listen for a valid address again.Right?"

    No, that is not correct. The radio will receive a million valid addresses every second. If the RX was disabled every time you received an invalid address it would never be able to stay on long enough to receive a valid address ;)

    As I said before, there is no way for the receiver to know if it is receiving an address from a transmitter, or just random noise from the air. For every single bit it receives it has to check whether or not you have an address match. 

    This also means that you could get a false address match if the noise in the receiver happens to match one of the configured addresses in the BASE and PREFIX registers. 

    To avoid false address matches you should use an address that is at least 4 bytes long. 

    "When the received address is beyond the logical address(perhaps a wrong address),how does the radio deal with it?Just discard it ?What is the value in the RXMATCH register?"

    It ignores it. As mentioned this will happen up to 1 million times pr second, so you don't want the receiver to take any action. 

    "PS: there is no address macth event in the radio event registers.EVENTS_DEVMATCH is perhaps not the address macth event you mentioned and ENENTS_ADDRESS just indicate that teh radio has received an address(no mattter it is valid or not).So teh address macth event is just referring to ?"

    The address match event is just called "EVENTS_ADDRESS"

    "That means: the radio will always send the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    Correct.

    "Is it the same as the rx side?The radio wil always begin to receivte the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    It will start receiving the first packet on the first address match after you trigger the start task, regardless of the RF environment. That is correct. 

    But if the RF environment is really bad there is obviously a chance that any incoming packet will be corrupted, which will either lead to an incorrect address (if you have bit errors in the address), or CRC failure (if you have bit errors on the packet). 

    Best regards
    Torbjørn

  • Hi,

      Thanks a lot!

    "Sorry for my description.I also need to confrm that: when a bit error in the LENGTH field that makes the length shorter than
    "Agree with it!Sorry for my poor description.Need to confirm that:when the radio receive an invalid address, it will enter rxidle state.Once we trigger a start task or make it in continuous rx mode, it will enter rx state and listen for a valid address again.Right?"

    No, that is not correct. The radio will receive a million valid addresses every second. If the RX was disabled every time you received an invalid address it would never be able to stay on long enough to receive a valid address ;)

    As I said before, there is no way for the receiver to know if it is receiving an address from a transmitter, or just random noise from the air. For every single bit it receives it has to check whether or not you have an address match.

    This also means that you could get a false address match if the noise in the receiver happens to match one of the configured addresses in the BASE and PREFIX registers.
    Yes!

    To avoid false address matches you should use an address that is at least 4 bytes long.
    Absolutely!I once set the address to short length(2 or 3 three bytes), the radio will always receive error data(address match but crc error).

    "When the received address is beyond the logical address(perhaps a wrong address),how does the radio deal with it?Just discard it ?What is the value in the RXMATCH register?"

    It ignores it. As mentioned this will happen up to 1 million times pr second, so you don't want the receiver to take any action.
    Yes.RXMATCH register is the Logical address of which previous packet was received.When rx address does't match, it will has no influence on this register.

    "PS: there is no address macth event in the radio event registers.EVENTS_DEVMATCH is perhaps not the address macth event you mentioned and ENENTS_ADDRESS just indicate that teh radio has received an address(no mattter it is valid or not).So teh address macth event is just referring to ?"

    The address match event is just called "EVENTS_ADDRESS"
    Yes.

    "That means: the radio will always send the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    Correct.

    "Is it the same as the rx side?The radio wil always begin to receivte the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    It will start receiving the first packet on the first address match after you trigger the start task, regardless of the RF environment. That is correct.

    But if the RF environment is really bad there is obviously a chance that any incoming packet will be corrupted, which will either lead to an incorrect address (if you have bit errors in the address), or CRC failure (if you have bit errors on the packet).
    Yes.

Reply
  • Hi,

      Thanks a lot!

    "Sorry for my description.I also need to confrm that: when a bit error in the LENGTH field that makes the length shorter than
    "Agree with it!Sorry for my poor description.Need to confirm that:when the radio receive an invalid address, it will enter rxidle state.Once we trigger a start task or make it in continuous rx mode, it will enter rx state and listen for a valid address again.Right?"

    No, that is not correct. The radio will receive a million valid addresses every second. If the RX was disabled every time you received an invalid address it would never be able to stay on long enough to receive a valid address ;)

    As I said before, there is no way for the receiver to know if it is receiving an address from a transmitter, or just random noise from the air. For every single bit it receives it has to check whether or not you have an address match.

    This also means that you could get a false address match if the noise in the receiver happens to match one of the configured addresses in the BASE and PREFIX registers.
    Yes!

    To avoid false address matches you should use an address that is at least 4 bytes long.
    Absolutely!I once set the address to short length(2 or 3 three bytes), the radio will always receive error data(address match but crc error).

    "When the received address is beyond the logical address(perhaps a wrong address),how does the radio deal with it?Just discard it ?What is the value in the RXMATCH register?"

    It ignores it. As mentioned this will happen up to 1 million times pr second, so you don't want the receiver to take any action.
    Yes.RXMATCH register is the Logical address of which previous packet was received.When rx address does't match, it will has no influence on this register.

    "PS: there is no address macth event in the radio event registers.EVENTS_DEVMATCH is perhaps not the address macth event you mentioned and ENENTS_ADDRESS just indicate that teh radio has received an address(no mattter it is valid or not).So teh address macth event is just referring to ?"

    The address match event is just called "EVENTS_ADDRESS"
    Yes.

    "That means: the radio will always send the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    Correct.

    "Is it the same as the rx side?The radio wil always begin to receivte the packet once it has dealed with last packet and the start task is triggered no mater how bad the RF environment is?"

    It will start receiving the first packet on the first address match after you trigger the start task, regardless of the RF environment. That is correct.

    But if the RF environment is really bad there is obviously a chance that any incoming packet will be corrupted, which will either lead to an incorrect address (if you have bit errors in the address), or CRC failure (if you have bit errors on the packet).
    Yes.

Children
Related