ILI9341_T4Driver: Hanging in _waitUpdateAsyncComplete()...

[MaltWhiskey]

When I send data over the serial connection (from a external esp8266) the driver will hang. ILI9341_T4Driver: Hanging in _waitUpdateAsyncComplete()...

This is the setup for serial between teensy and esp // ESP8266 UART baudrate on Hardware Serial1 Serial1.begin(460800); // Prevents RX buffer overflow if not reading fast enough static char read_buffer[4096]; Serial1.addMemoryForRead(read_buffer, sizeof(read_buffer));

I have made a yield to keep handeling serial data so the error message will keep showing up in the serial monitor (so the program is still active, just stuck forever in the _wait loop. // Check custom serial events (yield gets called in ILI9341_T4Driver) void yield() { ESP8266::loop(); }

The ESP8266::loop doesn't do anything special but read from Serial1 and write this to Serial. If I go for the default yield() nothing is printed in the serial monitor, but the result is still the same.

I put a break after this if (em > 1000)

but this will crash the teensy.

Any clue at what is making the driver block on _dma_state != ILI9341_T4_DMA_IDLE ??

I haven't investigated any further, thought I'd ask first ;)

Thx Malt Whiskey

[MaltWhiskey]

There must be something that messes up your interrupts in the HardwareSerial thereby missing the IDLE flag... https://github.com/PaulStoffregen/cores/blob/master/teensy4/HardwareSerial.cpp

[vindar]

Hi,

Weird bug. Clearly looks interrupt related. I have not stumbled upon it before... I will try to reproduce and look at it asap but it may take a few days since I just relocated and have yet to unpack my computer/electronic stuffs...

[MaltWhiskey]

Thanks, if i can help in anyway lmk

(i’m on a vacation next week, no coding/computer allowed)

[vindar]

Hi,

I finally unpacked my stuff...

I would like to reproduce the bug. Could you provide me with a minimalist example that shows the problem ? I have a T4.1, ESP32 (or ESP8266 at hand).. Thanks !

[MaltWhiskey]

Hi Arvind,

I can’t do anything code wise right now, but i pushed everything to github before i went on vacation. https://github.com/MaltWhiskey/Mega-Cube

The code is in the software folder. “LED display” is the teensy 4.0 code. The “wifi module” is the esp8266 and the “wio terminal” is a module from seeed (not needed). The teensy is connected on serial1 with rx <-> tx and tx <-> rx. I use platform IO if you add the software folder you should get 3 projects.

Not really a minimalist example right now (im back on monday i can make one then). I have used your game of life example (but pin 10 is not used for spi) and i think if you connect an esp and send data from the esp to the teensy of 400+ characters the bug will happen. I trigger the esp with wifi (telnet into it and paste 400 chars) it’s the serial data that is probably delaying an interrupt thereby crashing the lcd driver. (thats my assumption) Maybe something vsynch related? The read buffer has 4k so the serial shouldn’t overflow (or block)

// ESP8266 UART baudrate on Hardware Serial1 Serial1.begin(460800); // Prevents RX buffer overflow if not reading fast enough static char read_buffer[4096]; Serial1.addMemoryForRead(read_buffer, sizeof(read_buffer));

The game of life is here: https://github.com/MaltWhiskey/Mega-Cube/blob/master/Software/LED%20Display/src/core/LCD.cpp

Instead of using the ESP8266 class, just do a while loop to read serial1 if it’s available in the main loop() or in the yield() and all the animation stuff don’t need to run either.

The minimalist example would be game of life (pin 10 not spi) and a hardware serial with teensy using serial1, in the loop reading serial1 and something that sends 400+ chars to the teensy on serial1.

Op 20 jul. 2022 om 22:07 heeft Arvind Singh @.***> het volgende geschreven:



Hi,

I finally unpacked my stuff...

I would like to reproduce the bug. Could you provide me with a minimalist example that shows the problem ? I have a T4.1, ESP32 (or ESP8266 at hand).. Thanks !

— Reply to this email directly, view it on GitHubhttps://github.com/vindar/ILI9341_T4/issues/10#issuecomment-1190705866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKYMZ5X34XLTIO6HPJNLUKDVVBMBTANCNFSM53YDJEEQ. You are receiving this because you authored the thread.Message ID: @.***>

[vindar]

Hi,

Indeed, I can reproduce the bug ! I just added polling of Serial1 to the 99luftballons example (and used another Teensy to send random bytes via Serial1).

In my test, the bug does not occur when DC is wired to an hardware CS pin of the Teensy: this hints at a conflict with the SPI interrupt (because those interrupts are used much more intensively when DC is software emulated).

A (not completely satisfying) workaround is to increase the priority of the interrupt for the ILI941_T4 driver. To do so, just edit line 79 of ILI9341Driver.h and set it to:

#define ILI9341_T4_IRQ_PRIORITY 64

I have not tested this fix exhaustively but at least my test program does not hang anymore after the priority is increased... Yet, I would still like to understand exactly what is happening here :-)

Thank you for reporting the bug !

[vindar]

Hi again,

I think I have found the problem: when an interrupt occurs around lines 1487/1488 in ILI9341Driver.h and lasts too long, the SPI bus has time to complete the transaction but the interrupt flag is cleared so that the next interrupt is never called...

I just pushed a tentative fix (which does not require to increase the interrupt priorities anymore). Please let me know it it works for you when you have the time to test it.

Enjoy your holidays in the meanwhile ;-)

[MaltWhiskey]

Hi Arvind,

That was quick :-) I’ll let you know asap when i get home if the bug is fixed.

Op 21 jul. 2022 om 08:12 heeft Arvind Singh @.***> het volgende geschreven:



Hi again,

I think I have found the problem: when an interrupt occurs around lines 1487/1488 in ILI9341Driver.h and lasts too long, the SPI bus has time to complete the transaction but the interrupt flag is cleared so that the next interrupt is never called...

I just pushed a tentative fix (which does not require to increase the interrupt priorities anymore). Please let me know it it works for you when you have the time to test it.

Enjoy your holidays in the meanwhile ;-)

— Reply to this email directly, view it on GitHubhttps://github.com/vindar/ILI9341_T4/issues/10#issuecomment-1191081135, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKYMZ5RMMVPPJV6IG7MO2N3VVDS35ANCNFSM53YDJEEQ. You are receiving this because you authored the thread.Message ID: @.***>

[MaltWhiskey]

Tested and it works! Issue solved :)

[vindar]

Great :-)

Thanks again your help !