setting gdb breakpoints at init causes PSRAM memory overwrite (IDFGH-8913) (OCD-670)

[zfields]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.0

Operating System used.

macOS

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-S3-WROOM-1 (N8R2)

Power Supply used.

USB

What is the expected behavior?

I expect to be able to allocate PSRAM in chunks bigger than 24540 bytes.

What is the actual behavior?

It starts to overwrite memory when 24541 and larger bytes are allocated.

Steps to reproduce.

main.c

#include <stdio.h>
#include <string.h>

void app_main(void)
{
    // CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL == 16384, so any block larger than this                                      
    // will be forced into PSRAM.  The following shows an overwrite.                                                    
    // 24540 works; 24541 begins to show overwrite; 1000000 is massive overwrite                                        
    uint8_t *obj = calloc(24541,sizeof(uint8_t));
    (void)obj;

    // Test breakpoints, to be set when you are stopped at app_main.                                                    
    // - if you only set "b 15" then "c", when it breaks do an "x/128xb obj" you'll see 0's as you should               
    // - but if you set "b 15" AND "b 16" AND "b 17" then "c", when it breaks you'll see bad values                     
    printf("breakpoint 1\n");
    printf("breakpoint 2\n");
    printf("breakpoint 3\n");
}

1. Use an ESP32-S3 (N8R2) and plug both USB's into your PC
2. In esp-idf, make sure you "./install.sh esp32s3" to install tooling for the S3
3. In this project do "idf.py set-target esp32s3"
4. in "idf.py menuconfig"
   1. Compiler Options / Optimization Level / Debug without optimization (-O0)
   2. Serial flasher config -> Flash size -> 8 MB
   3. Component Config -> ESP PSRAM -> ENABLE Support for external, SPI-connected RAM
5. idf.py build & idf.py flash to flash...
6. Start two terminal sessions, and in both make sure you do ". ./export.sh" to set env vars
7. In terminal 1, run:
   openocd -f board/esp32s3-builtin.cfg -c "esp32s3.cpu1 configure -rtos FreeRTOS"
8. In terminal 2, run:
   xtensa-esp32s3-elf-gdb -tui -ex 'set pagination off' -ex 'target extended-remote :3333' -ex 'mon reset halt' -ex 'maintenance flush register-cache' -ex 'thb app_main' -ex 'monitor [target current] configure -event gdb-detach { shutdown }' -ex 'c' ./build/main.elf

Debug Logs.

No response

More Information.

• Allocating 24540 works; 24541 begins to show overwrite
• if you only set "b 15" then "c", when it breaks do an "x/128xb obj" you'll see 0's as you should
• if you set "b 15" AND "b 16" AND "b 17" then "c", when it breaks you'll see bad values

[igrr]

@zfields Do you observe this issue when you aren't connecting OpenOCD? I think OpenOCD on ESP32-S3 doesn't support PSRAM yet, so PSRAM data may be corrupted when OpenOCD is setting/removing a breakpoint.

[zfields]

If that's true, that would certainly explain it. How would I connect without OpenOCD to check?

[igrr]

I think you can try to still run OpenOCD but disable the software breakpoints in flash, then force GDB to use only hardware breakpoints. As a result, OpenOCD will not write to flash and this should prevent PSRAM corruption.

In step 7:

openocd -c 'set ESP_FLASH_SIZE 0' -f board/esp32s3-builtin.cfg

When running GDB, add

-ex 'set remote hardware-breakpoint-limit 2'

and use thb (temporary hardware breakpoint) instead of b to use only hardware breakpoints and keep the number of breakpoints <=2.

[zfields]

Thanks @igrr for following up with me so quickly!

When dumping memory even with these fixes and even with 1 breakpoint, the first byte looks bad when you first dump it. However, it seems to "clear up" if you dump it twice. Any ideas?

Also, is there any time frame for when using OpenOCD on the ESP32-S3 will support PSRAM?

[igrr]

@zfields Have transferred this issue to OpenOCD project so that it is tracked properly.

Regarding the successful read on 2nd attempt, there has been a similar issue we had fixed recently; however it looks like you are already using the latest release which includes the fix. Could you please confirm the version of OpenOCD you are running?

Regarding PSRAM support for ESP32-S3, it will likely be done in Q1 2023.

[zfields]

Thanks @igrr!

Could you please confirm the version of OpenOCD you are running?

I'm using OpenOCD v0.11.0-esp32-20221026.

Regarding PSRAM support for ESP32-S3, it will likely be done in Q1 2023.

Thanks, that's great news!

Have transferred this issue to OpenOCD project so that it is tracked properly.

No, I have not. Is there a way to "transfer" it using the GitHub UI, or do you mean reopen it there?

[igrr]

Sorry for not phrasing this clearly. I meant that I have already transferred this issue to the OpenOCD project. You don't need to do anything.

[erhankur]

Hi @zfields Can I ask you to test with the attached version?

openocd-esp32-macos-0.11.0-esp32-20221026-86-g283b87d64.tar.gz