8000 S3 Pin IRQ · Issue #8488 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

S3 Pin IRQ #8488

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
stephanelsmith opened this issue Apr 4, 2022 · 2 comments
Closed

S3 Pin IRQ #8488

stephanelsmith opened this issue Apr 4, 2022 · 2 comments

Comments

@stephanelsmith
Copy link
Contributor

Another odd S3 related issue. In S2 (and previous versions), I have no problem with pin irqs. In S3, the IRQ handler seems to not be called.

  • I've tried a variety of the RTC pins (GPIO0 - GPIO21)
  • Tried different pull options
  • I am able to read the correct logic level using pin.value()
  • I have a variety of different boards I've tested (and pins) and seeming consistency in S3 specific issue.
from machine import Pin
p = Pin(5, Pin.IN, pull=Pin.PULL_DOWN)
p.irq(lambda pin:print(pin))

I have no problem on ESP32-S2 as tested on:

  • UM FeatherS2
  • UM TinyS2

On S3, seeing the issues on:

  • ESP official S3 dev kit
  • UM ProS3
  • My custom S3 board

My gut feel would be this would be related to pin definition for RTC pins in machine_pin.c. I don't see anything popping out at me, though eyes aren't properly calibrated here.
@stephanelsmith
Copy link
Contributor Author
stephanelsmith commented Apr 6, 2022 •
edited
Loading

Using GENERIC_S3 firmware, I was able to track down the commit where the issue begins, 279 commits ago!

The issue is when "Pin MicroPython to core 1 again". This makes sense as to the differing behavior between S2 (single core) and S3 (dual core). Though, to my primitive understanding, I don't understand how this would affect IRQ handler.

278 XXXXXXXXXXXXXX 648656d esp32/esp32_rmt: Call rmt_driver_install directly if running on core 1.
279 XXXXXXXXXXXXXX 3570785 esp32: Pin MicroPython to core 1 again.
280 GOOD 63438a3 esp32/machine_adcblock: Add new machine.ADCBlock class and update ADC.

My gut guess here is the irq is firing into the wrong core. Is that a thing?

@stephanelsmith
Copy link
Contributor Author
stephanelsmith commented Apr 6, 2022 •
edited
Loading

Back on master branch, with the following setting, pin.irq handler is firing again. The test code in the first comment above now works.

CONFIG_FREERTOS_UNICORE=y

I'm not sure what the side-effects are here or the story behind the current pinning setup, but hopefully another clue towards resolution of this issue.

@ma261065 ma261065 mentioned this issue Apr 11, 2023
Closed
tannewt added a commit to tannewt/circuitpython that referenced this issue Oct 24, 2023
@tannewt
Re-add passing native methods the subclass instance
63079c7 
Fixes micropython#8488
tannewt added a commit to tannewt/circuitpython that referenced this issue Oct 25, 2023
@tannewt
Pass subobject into native subscr
be30c12 
This allows PixelBuf to call transmit after setting a value.

Fixes micropython#8488
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@stephanelsmith
0