Why would calling attachInterrupt in an constructor fail to work for some builds

[Alan01252]

Hi all,

My colleague and I have had our brains melted in the last couple of days. I have some code that looks some thing link this

Driver::Driver(Logging &log, TwoWire &i2c, const BQ25622Pins &pins)
    : _log(log), _i2c(&i2c), _pins(pins)
{
    // Initialize pins
    pinMode(_pins.interruptPin, INPUT_PULLUP);
    // // Attach interrupt
    attachInterrupt(digitalPinToInterrupt(_pins.interruptPin), [this]()
                    { setInterrupted(); }, RISING);
}

void Driver::setInterrupted()
{
    _log.noticeln("[Driver] Interrupt fired");
    _hasBeenInterrupted = true;
}

void Driver::begin()
{
   // does stuff
}

When I compile this on my machine using cmake it works entirely as you'd expect and setInterrupted gets called when the interrupt pin fires.

However on their machine ( using the same version of stm32aduino, but using sloeber to compile the interrupt code doesn't run.

If however he moves the attachInterrupt function into the drivers begin function everything works as expected.

So, a few questions:

Is this unexpected behavior expected?
Is it best practice to do this sort of stuff in the begin anyway?
Should we move the pin initializing code here too, even though that appears to work even if the attachInterrupt doesn't?
Is there an underlying reason why attachInterrupt acts differently to the pinMode functions?

Any answers will be greatly appreciated, else this might haunt my dreams forever more :)

Thanks

Alan

[fpistm]

Hi @Alan01252
First, if you used the CMake support provided within the core it is very closed to the Arduino build using cli or IDE while with Sloeber, several build option, gcc flags,... are not the same.
Theissue I can see in your description is that when the Driver instance is instantiate not all the HAL is init and so the interrupt is not properly configure (it is just a guess), you can confirm looking registed to see if interrupt is enabled or not same for the GPIO clock config of the interrupt pin.

Is there an underlying reason why attachInterrupt acts differently to the pinMode functions?

if you don't need to set pullup the pinMode is not required when you use the attachinterrupt it will configure the GPIO but keep the PU configuration.

[Alan01252]

Is there anyway to determine if the HAL is entirely initialized do you know?

I'm also a bit naive to the flow, the Driver constructor above is called in main.cpp beneath these lines

#include <Arduino.h>
#include <ArduinoLog.h>

Is there a better place to construct objects that this?

if you don't need to set pullup the pinMode is not required when you use the attachinterrupt it will configure the GPIO but keep the PU configuration.

My concern here is whether I should be doing any atmduino calls in the constructor at all I guess. For example the code currently does

digitalWrite(CHARGE_PIN, LOW);

And that seems to work in the constructor for both me and my colleague, whereas attachinterrupt does not.

[fpistm]

Tha'ts why I think interrupt is disable.
Note that here we do not support Sloeber.

[Alan01252]

Understood @fpistm , googling around etc I think you're right.

Reading main.cpp of stmduino

// Force init to be called first, i.e. before static object allocation.
// Otherwise, statically allocated objects that need HAL may fail.
attribute((constructor(101))) void premain()
{
// trim
init();
}

It sounds like for most scenarios this would work, but I can see how interrupts might act differently.

I hadn't for example considered the case of the interrupt firing before the constructor had completed and I can see how that might cause various problems too.

But in general I'm now leaning towards the fact that almost everything related to GPIO pins etc should be done in a begin function.