I am using an SI4464 with an SI4463. I can get the SI4463 to work with other SI4463 chips however the SI4464 is only capable of receiving a single packet before throwing CRC errors. My packet structure is 1 byte length and up to 63 byte payload, both covered by CRC. If the CRC is incorrectly configured then I get a CRC failure every packet(as expected) however if the CRC seems correctly configured the first packet is received by the SI4464 but any subsequent packets all return CRC error. If I pull data from the FIFO after this CRC error the beginning of the buffer contains the correct packet without any errors.
Interestingly, if I check the FIFO length after the failed CRC I get a length that is much longer than my actual packet. Attached are screenshots of the two packet's data output and sync detect on GPIOs.
Update: Seems that the SI4464 can receive multiple packets in a row so long as it does not transmit. If the SI4464 transmits then subsequent receives all fail. For some reason the SI446X_CMD_GET_INT_STATUS_REP_PH_PEND_PACKET_SENT_PEND_BIT never goes high and any future receives trigger SI446X_CMD_GET_CHIP_STATUS_REP_CHIP_PEND_CMD_ERROR_PEND_BIT. Checking the packet handler config it seems that PKT_FIELD_1_LENGTH changes from 1 to 2 after receiving a packet.
I have concerns about your solution you've found in your previous post, therefore I recommend to clarify first the CRC configuration.
- The attached screenshots are not so informative. You might share instead of those the project .xml files exported by WDS both for Si4464 and Si4463.
"If I check the FIFO length after the failed CRC I get a length that is much longer than my actual packet."
- It might be because improper variable length packet configuration. With the .xml files we can check it too.
Also, in the device's errata we have an item which describes a similar issue what you observed (2.14).
- Could you confirm, that there are no spurious CMD_ERR interrupts occur on the Si4464?
- Regarding the errata documentation, please confirm, that the device is not operating in the 479-639 MHz band.
Best Regards,
Bence
0
I've attached the xml files, please let me know if you need anything else.
I do not get any pending errors after replying to the first packet however I also do not get the packet sent pending. Once I receive the second packet I do get a pending error (SI446X_CMD_GET_CHIP_STATUS_REP_CHIP_PEND_CMD_ERROR_PEND_BIT).
I've managed to get this working on every second packet by setting PKT_FIELD_1_LENGTH to 1 after every error and changing my spi timings(No clue why this would matter as it worked fine with the SI4463). Now I can receive a packet, send a packet and then fail to receive the next packet. No SI446X_CMD_GET_INT_STATUS_REP_PH_PEND_PACKET_SENT_PEND_BIT signals are produced and the next received packet results in a SI446X_CMD_GET_CHIP_STATUS_REP_CHIP_PEND_CMD_ERROR_PEND_BIT where I reset PKT_FIELD_1_LENGTH which then allows me to receive packets again.
This certainly isn't a fix. Any ideas why the SI4464 loses PKT_FIELD_1_LENGTH after every TX?
0
Hi Gabriel,
I think if the length argument of START_TX or START_RX is not zero, it overwrites PKT_FIELD_1_LENGTH.
Tamás
0
Hi Gabriel,
The first thing I observed in your Si4464 radio configuration is that the CRC on the first field is transmitted, but not checked at the receiver side:
It causes CRC errors on every packets.
I tested the Si4464 configuration. I imported the configuration into Custom packet TX/RX projects, monitored TX_DATA_CLK and TX_DATA signals on the transmitter, and the RX_STATE, RX_DATA, RX_DATA_CLK and SYNC_WORD_DETECT signals on the receiver.
If I left the Check CRC at the end of this field checkbox (see the PKT_FIELD_1_CRC_CONFIG.CHECK_CRC bitfield's documentation) unchecked at the first field's configuration, the receiver produced CRC error, due it missed the last two bytes (the CRC2 part, since it did not expect the 2 bytes length CRC1). With this config the radio remains in RX state, but for the subsequent packet, the radio shuts off at the middle of the packet, and it lefts RX state for a short period. This sequence repeats on every two packets. Find my result in the CRC_no_check.logicdata file.
Once I enabled CRC1 on the receiver side, everything seemed to work correctly: the buzzer on the development board beeped, and there was no missing packet. I also captured it with my logic analyzer (CRC_check.logicdata).
The issue was that the field length in TX would override the field length in RX. I resolved the problem by enabling split field in SI446X_PROP_GRP_INDEX_PKT_CONFIG1 and then copying from PKT_FIELD to PKT_RX_FIELD. I no longer have to reset the field length after every second packet. This really should be added to the WDS config GUI as without it the SI4464 doesn't behave correctly with variable packets, unlike the SI4463.
Check CRC must not be on for F1, enabling this makes the CRC fail as the CRC bytes are only appended at the end of the whole packet. The GUI config tool is misleading as F1 is shared between RX and TX but F2 is unique to RX. I have no clue why it might have worked for you with this field on.
What works for the CRC is transmit CRC on F1(since TX only looks at F1) but check CRC on F2(since packet handler needs to know where the CRC is) while enabling CRC over both fields.
SI4464 and SI4463 compatibility and CRC issues
I am using an SI4464 with an SI4463. I can get the SI4463 to work with other SI4463 chips however the SI4464 is only capable of receiving a single packet before throwing CRC errors. My packet structure is 1 byte length and up to 63 byte payload, both covered by CRC. If the CRC is incorrectly configured then I get a CRC failure every packet(as expected) however if the CRC seems correctly configured the first packet is received by the SI4464 but any subsequent packets all return CRC error. If I pull data from the FIFO after this CRC error the beginning of the buffer contains the correct packet without any errors.
Interestingly, if I check the FIFO length after the failed CRC I get a length that is much longer than my actual packet. Attached are screenshots of the two packet's data output and sync detect on GPIOs.
Update: Seems that the SI4464 can receive multiple packets in a row so long as it does not transmit. If the SI4464 transmits then subsequent receives all fail. For some reason the SI446X_CMD_GET_INT_STATUS_REP_PH_PEND_PACKET_SENT_PEND_BIT never goes high and any future receives trigger SI446X_CMD_GET_CHIP_STATUS_REP_CHIP_PEND_CMD_ERROR_PEND_BIT. Checking the packet handler config it seems that PKT_FIELD_1_LENGTH changes from 1 to 2 after receiving a packet.
Any ideas what might be going on?
Hi Gabriel,
I have concerns about your solution you've found in your previous post, therefore I recommend to clarify first the CRC configuration.
- The attached screenshots are not so informative. You might share instead of those the project .xml files exported by WDS both for Si4464 and Si4463.
"If I check the FIFO length after the failed CRC I get a length that is much longer than my actual packet."
- It might be because improper variable length packet configuration. With the .xml files we can check it too.
Also, in the device's errata we have an item which describes a similar issue what you observed (2.14).
- Could you confirm, that there are no spurious CMD_ERR interrupts occur on the Si4464?
- Regarding the errata documentation, please confirm, that the device is not operating in the 479-639 MHz band.
Best Regards,
Bence
I've attached the xml files, please let me know if you need anything else.
I do not get any pending errors after replying to the first packet however I also do not get the packet sent pending. Once I receive the second packet I do get a pending error (SI446X_CMD_GET_CHIP_STATUS_REP_CHIP_PEND_CMD_ERROR_PEND_BIT).
I am operating at 420MHz.
This certainly isn't a fix. Any ideas why the SI4464 loses PKT_FIELD_1_LENGTH after every TX?
Hi Gabriel,
I think if the length argument of START_TX or START_RX is not zero, it overwrites PKT_FIELD_1_LENGTH.
Tamás
Hi Gabriel,
The first thing I observed in your Si4464 radio configuration is that the CRC on the first field is transmitted, but not checked at the receiver side:
It causes CRC errors on every packets.
I tested the Si4464 configuration. I imported the configuration into Custom packet TX/RX projects, monitored TX_DATA_CLK and TX_DATA signals on the transmitter, and the RX_STATE, RX_DATA, RX_DATA_CLK and SYNC_WORD_DETECT signals on the receiver.
If I left the Check CRC at the end of this field checkbox (see the PKT_FIELD_1_CRC_CONFIG.CHECK_CRC bitfield's documentation) unchecked at the first field's configuration, the receiver produced CRC error, due it missed the last two bytes (the CRC2 part, since it did not expect the 2 bytes length CRC1). With this config the radio remains in RX state, but for the subsequent packet, the radio shuts off at the middle of the packet, and it lefts RX state for a short period. This sequence repeats on every two packets. Find my result in the CRC_no_check.logicdata file.
Once I enabled CRC1 on the receiver side, everything seemed to work correctly: the buzzer on the development board beeped, and there was no missing packet. I also captured it with my logic analyzer (CRC_check.logicdata).
Let us know if it solves the issue at your end!
Best Regards,
Bence
The issue was that the field length in TX would override the field length in RX. I resolved the problem by enabling split field in SI446X_PROP_GRP_INDEX_PKT_CONFIG1 and then copying from PKT_FIELD to PKT_RX_FIELD. I no longer have to reset the field length after every second packet. This really should be added to the WDS config GUI as without it the SI4464 doesn't behave correctly with variable packets, unlike the SI4463.
Check CRC must not be on for F1, enabling this makes the CRC fail as the CRC bytes are only appended at the end of the whole packet. The GUI config tool is misleading as F1 is shared between RX and TX but F2 is unique to RX. I have no clue why it might have worked for you with this field on.
What works for the CRC is transmit CRC on F1(since TX only looks at F1) but check CRC on F2(since packet handler needs to know where the CRC is) while enabling CRC over both fields.
The actual packet format is [Len][Data][CRC]