Erroneous interrupt & pull resistor behavior

Official Hardware Nano Family Nano RP2040 Connect
1

Hello All,

I have noticed some weird behavior regarding interrupts and pull resistors on the Arduino Nano RP2040 Connect. I am not sure if it is just my board.

Running the code below, I am able to read ~3v3 from the pin specified by PIN. All is working well.

#define PIN 6
void setup() {
  Serial.begin(115200);

  pinMode(PIN, INPUT_PULLUP);
}
void loop() {
  
  Serial.println(digitalRead(PIN));
}

Attaching an interrupt to the same pin like below, causes the pin to be measure ~0v. According to the doumention this should be possible. Anyone know what causes this?

The pins have nothing connected to them.

void setup() {
  Serial.begin(115200);

  pinMode(6, INPUT_PULLUP);
  delay(100);
  attachInterrupt(digitalPinToInterrupt(6), func, FALLING);
}

void func()
{
  Serial.println("interrupt triggered");
}

void loop() {
  
  Serial.println(digitalRead(6));
}
2

You're not supposed to be doing serial comms inside an ISR. It may not be the problem, but you should try a different test, like toggling a port or LED, that is guaranteed to work with interrupts disabled. At least rule it out, so it's a bulletproof test.

3

I changed the code to the following

#define PIN 4
#define LED 5
void setup() {
  Serial.begin(115200);

  pinMode(PIN, INPUT_PULLUP);
  pinMode(LED, OUTPUT);
  delay(100);
  attachInterrupt(digitalPinToInterrupt(PIN), func, FALLING);
}

void func()
{
  int ledState = digitalRead(LED);
  digitalWrite(LED, !ledState);
}

void loop() {
  Serial.println(digitalRead(PIN));
}

The pin is still reading 0v. Commenting out attachinterrupt allows 3v3 to be read. This happen on all pins, not just a single one.

4

Why is it important to you, to read the state in software? Is the pullup state of the port in question? If so you should measure it with a DMM to confirm.

You can't read voltage by reading an MCU internal logic state, but that's the kind of language that you're using.

MCU I/O ports often have complex internal logic and differ between MCU's. So the expectations of behaviour of core functions that interface them should be strictly limited to the API definitions.

Did you try changing the order from

  pinMode(6, INPUT_PULLUP);
  delay(100);
  attachInterrupt(digitalPinToInterrupt(6), func, FALLING);

to

  attachInterrupt(digitalPinToInterrupt(6), func, FALLING);
  pinMode(6, INPUT_PULLUP);

?

And, what is the purpose of the delay(100)?

5

I am concerned with the pull-up state.

I have been measuring the pins with a DMM inorder to confirm the pull state.

So far even though a pull-up resistor is configured, attaching an interrupt to the pin cause the pull-up configuration to be side stepped (i assume). I am not sure what is causing this.

I added a delay because I thought some time was need for the pull-up to be set. It was a futile attempt at a fix.

I tried switching the order and it worked!? Is there a specific reason?

1 Like
6

The code appears to try to set the pinMode for you,
I don't think I understand the comparison for "== NULL" instead of "!= NULL" (line 75), but i'm not sure how that would cause the behavior you see. Perhaps it is buried inside of MBed.

1 Like
7

digitalPinToGpio returns a pointer an mbed::DigitalInOut object which is created in pinMode. If it is NULL then pinMode has not been called. I don't think this is the cause for the observed behavior.

1 Like
8

Oh, right. mbed creates "pin objects" at the time they are first used (via pinMode, or in digitalWrite/digitalRead if you've never done a pinMode), so the code I questioned creates the pin if it hasn't already been created.

1 Like
9

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.