Arduino esp32 segger-jlink

Sysprogs forums Forums VisualGDB Arduino esp32 segger-jlink

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #26183
    adamtwatson
    Participant

    Arduino esp32 segger-jlink problems with 128Mb / 16MB parts

    Part https://www.digikey.co.uk/product-detail/en/espressif-systems/ESP32-WROOM-32U-(16MB)/1904-1028-1-ND/9381737

    I can program and debug with Segger-jlink and the 128Mb module on Partition Scheme “Huge App 3MB” and “Minimal SPIFFS” fine – with settings for 128Mb module – all good.

    If I try to use “16M Flash (2MB APP/12.5MB FAT)” partition scheme in VGDB and:

    • program with the Segger J-Link the device will not boot properly – crashing repeatedly with boot message
    • program with the “arduino tools” and debug with Segger J-Link it works fine

    Similar things happen when I use custom partitions.csv system

    Also works fine if I compile inside the Arduino IDE (1.8.9) – all partitions and custom options work as expected

    Seems to be  a problem J-link programming cycle as with VGD’s arduino-builder.exe is producing an image that can be downloaded via Arduino tools option

    I am an avid user and have two licenses for my machines – great system

    Adam Watson

    #26233
    support
    Keymaster

    Hi,

    No problem. Indeed, when using Segger J-Link, VisualGDB would try to parse the esptool command line, reconstruct the FLASH memory layout from it and then load it using the OpenOCD’s commands. This mechanism is relatively fragile, so it might indeed not work in some cases.

    In order to track this down, please try the following build: VisualGDB-5.5.1.3314.msi

    Then open View->Other Windows->VisualGDB Diagnostics Console and try programming the memory using J-Link.

    Once the memory is programmed, please locate the following lines in the diagnostic log:

    1. Parsing esptool command should show the command line of the esptool used by the Arduino build system.
    2. com.sysprogs.esp32.esptool.binaries.count and subsequent lines should show the FLASH structure reconstructed from the command line. Please check it for any obvious inconsistencies compared to the command line.
    3. ExecuteRawCommand(mon program_esp32, <…>, CLI) lines will show the actual FLASH programming commands issued by VisualGDB to OpenOCD. They should match the FLASH memory layout in the esptool command line.

    If you can point out a specific part of the esptool command line that gets parsed incorrectly, it should be very easy for us to fix it. However, if it’s not that obvious, we would need you to collect more information:

    1. Erase the FLASH memory using esptool.py.
    2. Program the memory using the “Arduino tools”.
    3. Read back the FLASH memory using esptool.py.
    4. Erase the entire memory again
    5. Program it using J-Link.
    6. Read it back via esptool.py
    7. Compare the results (e.g. using fc.exe /b).
    8. Finally, post the entire diagnostic log from VisualGDB and the results of the comparison to this thread, or send it via our support form so that we could double-check everything on our side.

    P.S. It would also be great if you could either update your forum profile to match the email used in the license key, or send it via our support form so that we could internally link it to your forum profile.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.