Tx Retry Infinite Loop After 4 Read/Tx cycles

[JeffRocchio]

After a variety of updates to both the ATTiny and RPi code I noticed in a validation run that after 4 successful Cap read and transmit cycles the ATTiny-RPi pair is stuck in a Tx/Ack-Rx retry loop. The ATTiny side is looping through the logic that is the 'Error ID #2' logic - it transmits but doesn't see an Ack packet back from the RPi. So it keeps retrying. Heartbeat and errorFlash are working - I do see the 'Error-2' reports on the red led. On the RPi side it is receiving the Tx's from the ATTiny's radio chip. I see the ctErrors value keep counting up on the RPi SSH terminal session.

[JeffRocchio]

OK, so I now have a working version of the program with the bug removed. The trigger for the bug was the redefinition of the ackPayload struct in order to support the command/response protocol. When I made that change to both the ATTiny and RPi code I got the error. So I then re-redefined the struct, as noted below, and now it works. So my theory is that the 'data boundaries' in the struct have to be at 4-byte intervals in order for either the nRF24 chipset/board and/or the ATTiny to pack and unpack the structs properly.

This definition causes the issue to occur:

struct AckPayloadStruct {
    uint8_t command;      // Command ID back to sensor | 1-byte
    uint8_t uiCmdData;    // Command data field: unsigned int | 1-byte
    int iCmdData;         // Command data field: signed int | 2-bytes
    uint32_t uliCmdData;  // Command data field: unsigned long int | 4-bytes
    float fCmdData;       // Command data field: float | 4-bytes
};
AckPayloadStruct ackPayload;

This definition works fine:

struct AckPayloadStruct {
    uint32_t command;
    uint32_t uliCmdData;
};
AckPayloadStruct ackPayload;

Some additional testing may reveal what constraints are really at work on defining structs that work.

[JeffRocchio]

This is resolved in commit dd80da1. Although I do not, at this time, fully understand the 'rules' for defining data structs that will work, are bullet-proof, for data comms between the ATTiny and RPi using the nRF24 chip. That will have to be an exploration for another day - BUT see the posting about this at the below link, wherein it is stated:

What you're fighting is called memory misalignment. It can be solved by making sure data fits into 32-bit wide boundaries. For example, your test data sends an 11-byte string in the first segment of the payload, but it would be better if this was the last segment. If you look at the raw hex data, you may have noticed that everything after the first c-string is offset by 1 byte.

Add Info Regarding Byte Alignment or Packing Mismatches