Arm Mbed OS support forum

Incorrect value returned by (member) function (of a class)

Hi,

I am having some really weird issue, can anyone offer a fresh look and see if there is anything obvious I am missing?

I have this function that grabs data from CircularBuffer byte by byte and check if incoming data matches certain pattern, until either the CircularBuffer is empty or a matching pattern is found.

bool CC13XX::packetAvailable()
{
    uint8_t newByte;
    bool pktAvail = false;
    while(uartRxBuf.pop(newByte)) {
        pktAvail  = processByte(newByte);
        printf("NB %02X, Result: %C\n", newByte, pktAvail ? 'Y' : 'N');
        if(pktAvail) {
            processPacket();
            break;
        }
    }
    if(pktAvail) {
        printf("Return should be true\n");
    }
    // Return as seen in main when called
    // Is almost always false
    return pktAvail;
}

This function is called in main every 100ms. If return is true, then some debug tag is print out to console.

if(cc13xx.packetAvailable()) {
   printf("CC13XX Packet Received\n");
}

The problem I am having is, return by cc13xx.packetAvailable() is almost always false, even when the expected return is true as indicated by printf() inside the function.

I feel the problem I am having is related to C++ itself or compiler, but I am not quite sure where it really is.

Thanks in advance.

If I change the return type to uint8_t and use ‘N’ and ‘Y’ as equivalent of false and true, the value returned to main matches expectation.

I will admit I have no clue why this happens.

Update: when I was switching return type from bool to uint8_t, I accidentally changed code for another thread and therefore appeared to fix the problem. The real cause has nothing to do with return type.

Hello Li,

That’s strange. Maybe it’s a printf problem. Try to togle an LED if packetAvailable() returns true in the main rather then to print a debug message.

1 Like

Thanks for the tip to use LED as indication. I was thinking along the line that printf() or related code was the cause, using LED ruled out that possibility. After that I was able to ping down the real cause to another thread.