drawWedgeLine call to base display (tft.) locks it up and stops tft.fillCircle

[MikeyMoMo]

Using ESP32 WROOM. No PSRAM for large sprites so I have to use the base display. About to upgrade to WRover to get PSRAM.

I have a project that needs to draw two wedge lines onto the display. I was using fillTriangle but it was not as pretty as WedgeLine so I switched over. Suddenly things started locking up in one of 3 ways. Either some dots did not get written, all dots got written or no dots got written. It would change with any change to the code.

I thought that maybe it was hardware failing. I was in the middle of a large conversion to add a new display with a different touch controller on it so I though it might be something I had done. So it took a lot of troubleshooting to pin it down. I thought that maybe the integers going in might be confusing the routine although the compiler should be taking care of the conversion so I added (float) and float(myHX). Neither helped. No error messages, just stops updating as soon as the drawWedgeLine is issued. The other board is a WT32-SC01 and has PSRAM so I don't call tft.drawWedgeLine and it runs just fine. Again, making me suspect hardware.

Fails and causes further screen update failures: tft.drawWedgeLine(myHX, myHY, (float)xCenter, (float)yCenter, 2., 8., TFT_RED);

This also stops working after the drawWedge: tft.fillCircle(mySX, mySY, 3, ILI9341_YELLOW);

Works: sprite61.drawWedgeLine(0, 0, 100, 50, 2., 8., TFT_WHITE);

If I draw the dots first, they work once then the wedge fails and the dots no longer render. The code is being called but nothing comes out onto the screen.

[Bodmer]

These symptoms suggest lack of available memory which leads to corruption of variables and arrays. Check the size of memory resources consumed by the sprites. Bear in mind that the memory can get fragmented if sprites are often created and deleted.

Try a simpler sketch to test the drawing function works as expected. If it does not then post a simple sketch that demonstrates the problem.

[MikeyMoMo]

Remember, when the same program writes the wedge shape to a sprite object, it works just fine. Only when writing to the tft. object does it fail. The only change is whether it says tft. or sprite. for the target name.

The two little sprites are always allocated. The only difference is whether I use it for a test or not. If I use the sprite as the target for the wedge shape, all is well. If I don't use it, it still still there taking up the same amount of memory. Should not be a factor since it does not change, as far as I know about this stuff.

I have chopped out about everything I can.

Sketch uses 575185 bytes (18%) of program storage space. Maximum is 3145728 bytes.
(Down from only 39% when all code was there) Global variables use 29592 bytes (9%) of dynamic memory, leaving 298088 bytes for local variables. Maximum is 327680 bytes.

Still broken.

Just before the call to do the wedge hands:

These two do not change during execution.

Free Heap Size: 184040 uxTaskGetStackHighWaterMark: 5420

What other numbers would you like to see to help with this? Glad to provide. ...or... I just uploaded this minimal code set to github as MikeyMoMo/BLC-Stripout. https://github.com/MikeyMoMo/BLC-Stripout

lLastHeapSize = esp_get_free_heap_size();

#if defined DO_WEDGE_HANDS
  Serial.printf("Free Heap Size: %i\r\n",  esp_get_free_heap_size());
  Serial.print("uxTaskGetStackHighWaterMark: ");
  Serial.println(uxTaskGetStackHighWaterMark(NULL));
  tft.drawWedgeLine(myHX, myHY, xCenter, yCenter, 2, 8, TFT_RED);
  tft.drawWedgeLine(myMX, myMY, xCenter, yCenter, 2, 8, TFT_WHITE);

[Bodmer]

Usually I find that if the fault signature changes when unrelated code is changed, then memory corruption is the cause. Another possibility is that the new touch library operates using interrupts and is locking up the SPI bus. Without a detailed knowledge of the code and operating environment I can only guess at the cause.

Please provide simple example code that demonstrates the problem.

[Bodmer]

Assumed solved.

[MikeyMoMo]

We were down for 3 weeks because i6f a hurricane. Nothing has changed. Code still broken. I will look to see if there is some code change but I library update seen.

On Sat, Jul 29, 2023, 6:59 AM Bodmer @.***> wrote:

Closed #2739 https://github.com/Bodmer/TFT_eSPI/issues/2739 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Bodmer/TFT_eSPI/issues/2739#event-9952892798, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYPSIMHCKRCVCKGDK6NYWLXSQ75TANCNFSM6AAAAAA2ECZR3I . You are receiving this because you authored the thread.Message ID: @.***>