8000 Interrupt block update? · Issue #22 · scottchiefbaker/ESP-WebOTA · GitHub
[go: up one dir, main page]
Skip to content

Interrupt block update? #22

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
Open
netmindz opened this issue Oct 21, 2023 · 10 comments
Open

Interrupt block update? #22

netmindz opened this issue Oct 21, 2023 · 10 comments

Comments

@netmindz
Copy link

Do interrupts block the update? It looks like they do

Could you add noInterrupts and interrupts to your code or provide some form of callback like the ArduinoOTA.onStart ?
@netmindz
Copy link
Author

Firmware update initiated: firmware.bin

assert failed: xQueueSemaphoreTake queue.c:1554 (!( ( xTaskGetSchedulerState() == ( ( BaseType_t ) 0 ) ) && ( xTicksToWait != 0 ) ))

Backtrace: 0x40083785:0x3ffbf2fc |<-CORRUPTED

ELF file SHA256: f4d9d1357296968f

@netmindz
Copy link
Author

Callback would be preferable as I've found detaching and attaching my own interrupts again looks to be better than disabling all.

As a workaround I'm detaching and then attaching either side of the webota.handle(); but that's not ideal it's removing even when we aren't actually doing an updating

@netmindz netmindz mentioned this issue Oct 21, 2023
Open
@netmindz
Copy link
Author

See code suggestion #23

@scottchiefbaker
Copy link
Owner

I have never used interrupts in my Arduino code so I didn't know this was a issue. Is the issue then that an interrupt fires while we're in the middle of uploading an interrupt and that breaks the update?

Seems like a simple noInterrupts() while were actively updating would be a simple solution? Looking at your callback solution it seems full featured and perhaps a little overkill. This project has been public for several years now and this hasn't come up before. I'm leaning towards the more simple noInterrupts() solution at the moment unless you can convince me otherwise.

@netmindz
Copy link
Author

Yeah the update gets only to 10% in my case before the interrupt kills it.

Disabling all interrupts didn't actually work for me on the ESP32.

As for the the complexity, registering the callbacks is entirely optional so doesn't make it any harder to use for users who don't want that. By using callbacks users can also do things like change a status LED to indicate update in process.

The structure is lifted from AuduinoOTA so well be familiar to users

@scottchiefbaker
Copy link
Owner

Is there any reason not to call noInterrupts() inside of the HTTP upload section of the code? I cannot think of a scenario where you would WANT to break off your upload mid-stream to handle an interrupt.

I'm thinking it's a no-brainer to add noInterrupts() to the code, and then also look at adding the callbacks? What do you think?

@netmindz
Copy link
Author

Initially I tried using noInterrupts() in my callback but that didn't work so I swapped to detaching my rapidly firing interrupt. I'm didn't investigate why it didn't work, but it's possible that interrupts are needed for WiFi or something else that's part of the overall stack on an ESP32

@netmindz
Copy link
Author

https://forum.arduino.cc/t/enabling-wifi-conflicts-with-button-interrupts-resolved/644348/7

@scottchiefbaker
Copy link
Owner

Does noInterrupts() just not doing anything on ESP32?

Either way I'm leaning towards using it inside of the actual update code as it can't really hurt?

@netmindz
Copy link
Author

I need to tripple check, but I believe that disabling all interrupts will stop the WiFi stack working

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
2 participants
@netmindz @scottchiefbaker
0