Problems with version 4.0.2

[elral]

After updating from version 4.0.1 I got problems with the library TFT_eSPI from Bodmer (https://github.com/Bodmer/TFT_eSPI).
It might be that this a problem with the library, but at least it has changed compared to version 4.0.1 (I am quite sure it was this version, but it could be also 4.0.0 which is very unlikely).

I am using a Pico2 and a PGA2350 to display graphics on a display using the above metioned lib.

1. To get it displayed, the can use pushImageDMA() to transfer data to the display. This worked fine before version 4.0.2. With the last update this is not working anymore, instead the data has to be transferred w/o DMA. This is tested with a simple example project.
2. Within my real project (which runs fine on a ESP32-S3, so should not be the code) which is quite bigger, the Pico2 shows the same behaviour. DMA transfer does work, but at least some sprites can be displayed w/o DMA. As a lot of graphics are used (stored in the flash), not all can be dsiplayed due to the less RAM. If a compile the same code for the PGA2350, the board seems to crash even without using any function from the lib (functions are in the code but they got not be called). No USB connection can be established anymore and I have to put the board into bootloader mode for the next upload. At least here is a difference between these both boards.

For the Pico (RP2040) nothing has changed. Another project using this lib is still working fine, even with DMA transfer.

I am a little bit lost what to test now.

[elral]

I am coming a little bit closer. The crash of the PGA2350 seems to be related to our function like:
buttons = new (allocateMemory(sizeof(MFButton) * count)) MFButton;
with

std::size_t    *allocateMemory(uint16_t size)
{
    uint16_t actualPointer = nextPointer;
    nextPointer            = actualPointer + size;
    if (nextPointer >= MF_MAX_DEVICEMEM) {
        Serial.println("DeviceBuffer Overflow!");
        return nullptr;
    }
    return &deviceBuffer[actualPointer];
}

It's enough to have the code in the firmware, buttons = new (allocateMemory(sizeof(MFButton) * count)) MFButton; must not be called to get the PGA2350 to crash!?
But with a minimum working code everything is fine.

/edit:
We use this several times for different devices. Now I found out, that some are working, some not. And it depends on combinations of these devices.
I know this erratic behaviour from memory overlaps like exceeding boundaries from arrays...

[earlephilhower]

Without a small code sample that doesn't need special HW there's not much we can do here, but in general a) the 2.0 SDK changed the way certain resources were assigned (PIO2 first instead of PIO0, for example) and b) the 2350 has a different register map and HW resources than the 2040. Maybe open something at the GFX library repo?

[elral]

@earlephilhower thanks for the reply.

a) the 2.0 SDK changed the way certain resources were assigned (PIO2 first instead of PIO0, for example) and b) the 2350 has a different register map and HW resources than the 2040.

Good to know, so that's definetly something where the library is affected.

I wasn't successfull to set up a small code example for the Pimoroni PGA2350 as all attempts are working fine. But I am quite sure that it is not related to the graphic lib as it's working (w/o DMA) if I deactivate other parts of our code.
Unless I can set up a small demo maybe just keep this in mind that there might be an issue (or not).

[elral]

I did an update this morning and the Pimoroni PGA2350 doesn't crash anymore and the DMA transfer from the TFT_sSPI lib is also working again.
So everything is fine again. Just have to figure out how to use the PSRAM wihtin the library.
Thanks again!

/edit: I still had code deactivated, activating different combinations lead to a crash or not. Still trying to remove code why it's crashing. For now it looks lile it has to do with the EEPROM emulation, but still not quite sure.

[elral]

@earlephilhower It turns out that all my problems for the PGA_2350 from Pimoroni come from the library ArduinoUniqueID where flash_get_unique_id() is used. It is repeatable that this causes crashes or strange behaviours of the app.
As a minimal test the followong code:

#include <Arduino.h>
#include "hardware/flash.h"

void printPSRAMinfo(void)
{
    Serial.print("PSRAM size is: ");
    Serial.println(rp2040.getPSRAMSize());
    Serial.print("Total PSRAM Heap: ");
    Serial.println(rp2040.getTotalPSRAMHeap());
    Serial.print("Used PSRAM Heap: ");
    Serial.println(rp2040.getUsedPSRAMHeap());
    Serial.print("Free PSRAM Heap: ");
    Serial.println(rp2040.getFreePSRAMHeap());
}

uint8_t id[8];

void setup()
{
    Serial.begin(115200);
    while (!Serial)
        delay(10);
    delay(100);
    Serial.println("-------------- Before getting UniqueID  ------------------");
    printPSRAMinfo();
    flash_get_unique_id((uint8_t*)id);
    Serial.println("--------------- After getting UniqueID  ------------------");
    printPSRAMinfo();
}

void loop()
{
}

with platformio.ini

[env:pga2350]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pimoroni_pga2350
framework = arduino
board_build.core = earlephilhower
;board_build.filesystem_size = 0M
lib_ldf_mode = deep+
upload_protocol = mbed
monitor_speed = 115200

The output is:

-------------- Before getting UniqueID  ------------------
PSRAM size is: 8388608
Total PSRAM Heap: 8386052
Used PSRAM Heap: 12
Free PSRAM Heap: 8386040
--------------- After getting UniqueID  ------------------
PSRAM size is: 8388608
Total PSRAM Heap: 0
Used PSRAM Heap: 0
Free PSRAM Heap: 0

PSRAM Heap values should be the same after reading the UniqueID.
Using pico_get_unique_board_id_string() or pico_get_unique_board_id() works like expected and reports the same as flash_get_unique_id(), so that's what I will use for now.
But it would be still interersting what the problem could be.

Thanks again

Ralf

[earlephilhower]

Flash and PSRAM share the QSPI interface pins and logic, so running a naked command like you're doing is probably not legal. The SDK code https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_unique_id/unique_id.c caches the data immediately after boot (and before PSRAM has been set up) and uses the ROM routines on the RP2350 instead of poking the flash bus directly to grab the data...

[earlephilhower]

You might want to open something on the pico-sdk repo about this. If it's really not legal to call that flash function on the 2350, maybe it shouldn't exist when building on the 2350?