Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JTAG ESP32 Failed to get flash mappings (Flashing Failed) (OCD-544) #223

Closed
littleboot opened this issue Apr 9, 2022 · 8 comments
Closed

Comments

@littleboot
Copy link

Problem description

After specific a specific firmware is flashed, loaded and working without any issues trying to flash the same or other firmware fails. The firmware in question does not touch any of the JTAG or bootstrap GPIO's. I'm certain its not a hardware issue, other firmware can be flashed and reflashed without issues. Only when the wifi provisioning code is added to the project JTAG breaks. To be able to flash over JTAG again the flash needs to be erased using the "flash erase" which using the serial bootloader which requires the serial interface to be connected (It would be a great feature to be able to erase the flash using the JTAG interface).

System properties

  • Windows 10 64-bit;
  • Eclipse + idf-eclipse-plugin
  • (Also tried Vscode extension, does not matter same openocd flash command is called)
  • IDF framework 4.4 (latest stable release as of writing)
  • (also tried IDF framework master 8-4-2022 )

Firmware description

The firmware in question is a modified "wifi_prov_mgr" example.
The only modifications are the addition of very simple RMT Led driver code.
All modifications (addition of some code) can be viewed easilly looking at the GIT commits.
The addition does not touch any of the JTAG or Bootstrapping GPIO's.

Hardware

  • Custom board with "ESP32-WROOM-32E(M113EH3200PH3Q0)" 4MB module.
  • ESP-prog (used for JTAG)

Part of OpenOcd log -d2 were it begins to fail

It looks like OpenOcd is not able to get the flash size and fail when it tries using 0KB.
Full logs and the firmware sources are provided at the end of this issue report.

Info : Auto-detected flash bank 'esp32.cpu0.flash' size 0 KB
Info : Using flash bank 'esp32.cpu0.flash' size 0 KB
Info : esp32.cpu0: Target halted, PC=0x400003C0, debug_reason=00000001
Error: Failed to get flash maps (2)!
Warn : Failed to get flash mappings (-4)!
Info : esp32.cpu0: Target halted, PC=0x400003C0, debug_reason=00000001
Info : esp32.cpu0: Target halted, PC=0x400003C0, debug_reason=00000001
Info : Auto-detected flash bank 'esp32.cpu1.flash' size 0 KB
Info : Using flash bank 'esp32.cpu1.flash' size 0 KB

Steps to reproduce

Open the provided firmware repo (see end of issue report) or perform the modifications manually. Flash this firmware over JTAG, observe that it succeeds. Observe that the apllication is working without any apparent issues. Try flashing over JTAG again. Observe that it fails to do so.

Firmware modifications

I describe here how I modified the "wifi_prov_mgr" example to get it to break JTAG flashing.
In addition I will highlight an additional issue with the example project in eclipse. Note that no modification are made to the code at this point (this is not the focus of this issue report but I would love to have a solution for this if possible).
The steps I took can be traced using the GIT commits included in the repo.

Open eclipse ide with IDF plugin and create a project based on the example "wifi_prov_mgr"

File->new->Espressif IDF project

Build project to verify toolchain is working (observe unrealed )

The project compiles without issues. However there is a problem listed in the problems tab:

Type 'size_t' could not be resolved
image

Somehow the eclipse indexer is not able to find the definition for "size_t".

Currently I supressing this error by the addition of:

Add // @suppress("Type cannot be resolved") to line 113 of app_main.c will supresses the warning but is not really a fix.

Modifications to app_main.c

Note the modified code is avaible at the end of the issue report, this is for reference.

add the following code to the top of app_main.c:

/* Led: Added code */
#include "driver/rmt.h"
#include "driver/gpio.h"

#define WS2815B_RMT_CHANNEL (RMT_CHANNEL_0)
#define BITS_PER_LED 24
#define WS2815B_DATA_PIN (GPIO_NUM_25)

rmt_item32_t rmt_data_buffer[BITS_PER_LED]; // This is the buffer which the hw peripheral will access while pulsing the output pin

static void setup_rmt_data_buffer(uint32_t led_data);
void WS2815B_init();
void WS2815B_set(uint32_t red, uint32_t green, uint32_t blue);

add the following code to the bottom of app_main.c:

void WS2815B_init(void)
{
    rmt_config_t config = RMT_DEFAULT_CONFIG_TX(WS2815B_DATA_PIN, WS2815B_RMT_CHANNEL);;

    config.rmt_mode = RMT_MODE_TX;
    config.channel = WS2815B_RMT_CHANNEL;
    config.gpio_num = WS2815B_DATA_PIN;
    config.mem_block_num = 1;
    config.tx_config.loop_en = false;
    config.tx_config.carrier_en = false;
    config.tx_config.idle_output_en = true;
    config.tx_config.idle_level = 0;
    config.clk_div = 2;

    ESP_ERROR_CHECK(rmt_config(&config));
    ESP_ERROR_CHECK(rmt_driver_install(config.channel, 0, 0));
}


static void setup_rmt_data_buffer(uint32_t led_data)
{
    uint32_t bits_to_send = led_data;
    uint32_t mask = 1 << (BITS_PER_LED - 1);

    for (uint32_t bit = 0; bit < BITS_PER_LED; bit++)
    {
        uint32_t bit_is_set = bits_to_send & mask;
        rmt_data_buffer[bit] = bit_is_set ? (rmt_item32_t){{{42, 1, 12, 0}}} : (rmt_item32_t){{{12, 1, 42, 0}}};
        mask >>= 1;
    }
}

void WS2815B_set(uint32_t red, uint32_t green, uint32_t blue)
{
    uint32_t ledData = (green << 16) | (red << 8) | (blue << 0);

    setup_rmt_data_buffer(ledData);

    ESP_ERROR_CHECK(rmt_write_items(WS2815B_RMT_CHANNEL, rmt_data_buffer, BITS_PER_LED, false));
    ESP_ERROR_CHECK(rmt_wait_tx_done(WS2815B_RMT_CHANNEL, portMAX_DELAY));
}

Add the following code inside void app_main(void) to the line before /* Wait for Wi-Fi connection */

/* LED Code */
WS2815B_init();
WS2815B_set(0, 255,255);

OpenOcd Log files

db2 - fail tried flashing again.txt
db2 - succes wifi_prof_mgr without modifications.txt
db3 - fail wifi_prof_mgr plus RMT LED driver GPIO2.txt
db3 - fail wifi_prof_mgr plus RMT LED driver GPIO25.txt

Firmware repo

wifi_prov_mgr - Breaks JTAG flash.zip

@erhankur
Copy link
Collaborator

erhankur commented Apr 9, 2022

@littleboot Thanks for the great explanation. I saw the issue.

In order to speed up the download process from jtag, target cpu clock frequency is set to the highest possible value in the stub flasher code. Looks like this operation breaks something when rmt driver is enabled. We will look at it later on. But until we find the root cause you can use the attached OpenOCD master built for your test.

openocd-esp32-win32-0.11.0-esp32-20211220-1339-g187c87957.zip

@littleboot
Copy link
Author

openocd-esp32-win32-0.11.0-esp32-20211220-1339-g187c87957.zip

Thank you very much, this build fixes the problem!

I tested the OpenOcd build first using the command line according to the instructions .

Launching OpenOcd

Cd C:\Users\Admin\Desktop\openocd-esp32\bin
openocd -f board/esp32-wrover-kit-3.3v.cfg

Success: no problems

Flashing
(copy the binary to the openocd.exe location (or provide full path in program_esp command)

Cd C:\Users\Admin\Desktop\openocd-esp32\bin
openocd -f board/esp32-wrover-kit-3.3v.cfg -c "program_esp wifi_prov_mgr.bin 0x10000 verify exit"

Success: no problems

Update OpenOcd in Eclipse:
Downloaded, extracted and renamed latest openOcd build (openocd-esp32-win32-0.11.0-esp32-20211220-1339-g187c87957.zip)
To the tools folder used by eclipse IDF:
C:\Users\Admin\.espressif\tools\openocd-esp32\v0.11.0-esp32-20211220-1339-g187c87957

Changed open OCD path in eclipse
Window->preferences->Espressif->Global OpenOcd Path:
C:\Users\Admin\.espressif\tools\openocd-esp32\v0.11.0-esp32-20211220-1339-g187c87957\openocd-esp32\bin

Success: No problems, I can flash the firmware using JTAG over and over without issues.

@github-actions github-actions bot changed the title JTAG ESP32 Failed to get flash mappings (Flashing Failed) JTAG ESP32 Failed to get flash mappings (Flashing Failed) (OCD-544) Apr 26, 2022
@josesimoes
Copy link

I'm similar issues, but when starting a debug session.

I've downloaded the Openocd version from above and this is what I'm getting when starting openocd on the command prompt:

openocd-esp32-win32-0.11.0-esp32-20211220-1339-g187c87957/openocd-esp32/bin/openocd.exe -s ".espressif/tools/openocd-esp32/v0.11.0-esp32-20211220/openocd-esp32/share/openocd/scripts/" -f board/esp32-wrover-kit-1.8v.cfg
Open On-Chip Debugger  v0.11.0-esp32-20211220-1339-g187c8795 (2022-04-09-16:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'ftdi vid_pid' not 'ftdi_vid_pid'
DEPRECATED! use 'ftdi channel' not 'ftdi_channel'
DEPRECATED! use 'ftdi layout_init' not 'ftdi_layout_init'
DEPRECATED! use 'ftdi layout_signal' not 'ftdi_layout_signal'
DEPRECATED! use 'ftdi layout_signal' not 'ftdi_layout_signal'
DEPRECATED! use 'ftdi layout_signal' not 'ftdi_layout_signal'
DEPRECATED! use 'ftdi layout_signal' not 'ftdi_layout_signal'
semihosting not supported for current target

@erhankur
Copy link
Collaborator

erhankur commented May 5, 2022

@josesimoes please use the scripts from the new built directory.

@josesimoes
Copy link

josesimoes commented May 5, 2022

@josesimoes please use the scripts from the new built directory.

@erhankur can you please point me to that "new built directory"? Where can I find it? Are you referring to the "build" directory that's created when building?

@erhankur
Copy link
Collaborator

erhankur commented May 5, 2022

I meant use scripts from the directory openocd-esp32-win32-0.11.0-esp32-20211220-1339-g187c87957/openocd-esp32/

We also updated all deprecated scripts. So you need to point them in your openocd command.

@josesimoes
Copy link

@erhankur OK that works. Thanks!

@erhankur
Copy link
Collaborator

Fix added to the latest release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants