digitalRead() returning value of 32?

Troubleshooting
1

I had some intermittent issues with switches on the digital input pins, for some reason the logic in my code behaved strangely.

I decided to publish the read pin states as a variable and have it logged using a google spreadsheet.
I’m using D1, D2 and D3 as digital inputs and set their respective modes to INPUT.
The inputs are pulled high to 3.3v by 4k7 ohm resistors and the obvious ground when the switches close.

In the logging it now appears that D1 within certain periods of time (few minutes) will all of a sudden start returning the value of 32 instead of HIGH/LOW (1/0), this while the pin is still pulled low.

Is it possible for a digital input pin to return values other than 1/0 ? (thusfar I have only seen D1 do it)

2

@BaSS, can you post your code so we can get a better idea of what your program is doing?

3

Here’s where I read the digital pins (D1,D2,D3).
i’m exposing the m_bufferLevelXXX variables in a json string like so:

sprintf(jsonResult, "{\"m\":\"%s\",\"s\":\"%s\",\"tin\":%.2f,\"tout\":%.2f,\"thtr\":%.2f,\"tamb\":%.2f,\"bl\":%d,\"b1\":%d,\"b2\":%d,\"b3\":%d}", 
        str, statusStr, state.tempIn, state.tempOut, state.tempHeater, state.tempAmbient, state.bufferLevel, 
        m_bufferLevelLow, m_bufferLevelMed, m_bufferLevelHigh);

Spark.variable("getstats", &jsonResult, STRING);

and here’s where the pins are read.

void processBufferLevels()
{

    m_bufferLevelLow = digitalRead(PIN_BUFFER_LOW);    
    m_bufferLevelMed = digitalRead(PIN_BUFFER_MED);   
    m_bufferLevelHigh = digitalRead(PIN_BUFFER_HIGH);    


    unsigned long delta;    

    // debounce
    if (m_bufferLevelLow != m_pin_buffer_low_debounce_state)
    {
        if (m_pin_buffer_low_debounce == 0)
            m_pin_buffer_low_debounce = millis();
            
        delta = millis() - m_pin_buffer_low_debounce;
        if (delta > 50)
        {
            m_pin_buffer_low_debounce_state = m_bufferLevelLow;
            m_pin_buffer_low_debounce = 0;
        }
    }
    
    if (m_bufferLevelMed != m_pin_buffer_med_debounce_state)
    {
        if (m_pin_buffer_med_debounce == 0)
            m_pin_buffer_med_debounce = millis();
            
        delta = millis() - m_pin_buffer_med_debounce;
        if (delta > 50)
        {
            m_pin_buffer_med_debounce_state = m_bufferLevelMed;
            m_pin_buffer_med_debounce = 0;
        }
    }

    if (m_bufferLevelHigh != m_pin_buffer_high_debounce_state)
    {
        if (m_pin_buffer_high_debounce == 0)
            m_pin_buffer_high_debounce = millis();
            
        delta = millis() - m_pin_buffer_high_debounce;
        if (delta > 50)
        {
            m_pin_buffer_high_debounce_state = m_bufferLevelHigh;
            m_pin_buffer_high_debounce = 0;
        }
    }

    if (m_pin_buffer_high_debounce_state != HIGH) state.bufferLevel = BUFFER_LEVEL_HIGH; 
    else if (m_pin_buffer_med_debounce_state != HIGH) state.bufferLevel = BUFFER_LEVEL_MEDIUM; 
    else if (m_pin_buffer_low_debounce_state != HIGH) state.bufferLevel = BUFFER_LEVEL_LOW; 
    else state.bufferLevel = BUFFER_LEVEL_EMPTY;
}

Initially I was reading the pins and keeping their states (m_pin_buffer_low_debounce_state etc…) in a byte variable, but I have now changed them to be ints and I have not seen the problem since (20 minutes and counting)… Could it simply be an sprintf() fluke displaying bytes using %d ?

Something else to note btw, without the debounce code I had quite a bit of flakey bouncing going on… but i’m wondering if that might have been because of the read 32 at the time…

4

@BaSS, the issue may well have been the use of %d for printing a byte var with sprintf. The bounce should not have caused this issue since the value returned is 0 or 1. Nonetheless, your debounce code could have been the culprit with a byte var. Hopefully you have fixed the problem by using int vars. :smile:

5

Strange still though, right? I mean, sprintf should normally handle %d with bytes shouldn’t it? (not saying its a confirmed bug or anything, just asking).

It has however been running without problems for the past 40 mins without any issues (using ints) …

Fingers crossed :wink:

1 Like