ESP32 update problems

[Frank]

I had a working project in VS, after the updated I had to fix a few errors before being able to build without errors. After fixing the errors, I am unable to flash the esp32 over jtag.

Visualgdb: flash read err, 1000
Serial: rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 Falling back to built-in command interpreter. OK

I started a new clean msbuild project that builds and flashes ok but gives an error while running:

I (1733) cpu_start: Pro cpu start user code
	Guru Meditation Error of type IllegalInstruction occurred on core  0 at pc=40118532. Setting bp and returning..

I tried to make a new clean GNUMake project but that just creates build errors caused by undefined references to ethernet functions.
I cannot remove ethernet framework since it is baked into the esp32 event default event handler.

Any ideas?

[support]

Hi,

If you are getting build errors, most likely the toolchain got corrupt, so removing and reinstalling it should help.

FLASH reading errors are tougher and could indicate a dead chip. During our tests with ESP8266 three different boards routinely died under different circumstances, so we would suggest simply getting another one.

[Frank]

I can build, just had to fix a few things.
The chip isn’t dead, I have programmed the chip over serial using a binary from an old project.

My project wouldn’t program over jtag so I tried a clean project. In the clean project I can flash the chip through jtag but it goes into that guru meditation error.
The chip and the debugger are working perfectly.

I removed the esp32 toolchain and downloaded it again but with the same results.

• This reply was modified 7 years, 3 months ago by Frank.

[support]

Hi,

Sorry about that. First of all please note that the ESP32 chip is very new and often behaves unpredictably, so this is to be expected.

Our best advice here would be to try something very simple and see if this works. Does building and programming a basic “LEDBlink” project with VisualGDB work? If no, does flashing the same ELF file with esptool.py work?

If you can confirm that the file built with VisualGDB does not work even when flashed with esptool, please ensure that you are using an unmodified toolchain from us and that the optimization is set to -Og, not -O0.

[Frank]

I already made a blink example, flashing works but running causes the following problem:

I (1733) cpu_start: Pro cpu start user code
	Guru Meditation Error of type IllegalInstruction occurred on core  0 at pc=40118532. Setting bp and returning..

I have a Virtual machine running with visualgdb before the update, there it works fine without a problem.
Can I uninstall visualgdb and install a older version, and copy the esp32-bsp from my virtual machine?
On the virtual machine I have a other problem though, but ill make another thread about that.

[support]

Hi,

It could be caused by updating the ESP32 IDF then.

You can try the older version by downloading the older toolchain from here: http://gnutoolchains.com/esp32/. There is no need to reinstall VisualGDB.

[Frank]

It was the -Og flag forgot it in the new project.
But now that I have a working project and copied all my sources from my old project I’m presented with my first problem.
I’m using a library. When I enable the library my flash grows from 10 to 15% and I’m unable to flash the device.

I am able to flash the program without the library and I am able to flash it with the library over my usb-serial.
But flashing with the library though the jtag debugger gives me this error:

Visualgdb: flash read err, 1000
Serial: rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) flash read err, 1000 Falling back to built-in command interpreter. OK

[support]

Hi,

Thanks, we can certainly investigate this. Please let us know whether you get an error during the FLASH programming or it succeeds, but then the firmware fails to start?

If the programming succeeds, but the program does not start, please try reading the FLASH contents via esptool, then program the image via esptool and re-read the FLASH contents. Then please compare the FLASH contents after programming with VisualGDB and with esptool.py and let us know the difference.

If the programming fails, please attach a screenshot showing the error so that we could know where exactly it happens.

[Frank]

this error occurs during the flashing of the device and does not succeed.

Screenshot:
https://1drv.ms/i/s!ArGQV6ObDq-t2SVmLSfc_BQhw0pq

error message:

VisualGDB version: 5.2.14.1318
------------------ j31+l ------------------
j31+l: Failed to erase the FLASH region starting at 0x10000
   at j31.j(qr1 a, ICustomStartupSequenceBuilder b)
   at j31.o1.b(qr1 a)
   at ot.e2.g3
1.d(qr1 a)
   at VisualGDB.Add_In.Tool_Windows.WPF.DockedProgressPresenter.a(Action 1 operation, String caption, eo exceptionHandler, String[] stages)

visualgdb remote console output:
http://pastebin.com/WNWrDye1

• This reply was modified 7 years, 3 months ago by Frank.

[support]

Hi,

Thanks for the detailed reply, this explains where the problem happens.

Looks like the code responsible for erasing the FLASH memory does not work properly. Could you confirm that he same happens with a basic “LEDBlink” application that is artificially made larger by adding code like this:

const char __attribute((section(".rodata"))) bigblock[1024 * 1024] = { 1, };
    
void app_main()
{
    volatile int x = bigblock[0];
}

[Frank]

The same does not happen when adding the code to “LEDBlink” example project.

1>  ------------------- Memory utilization report -------------------
1>  Used DATA_FLASH: 43KB out of 8192KB (0%) [-1644]
1>  Used INSTR_FLASH: 167KB out of 3264KB (5%) [-38K]
1>  Used INSTR_RAM: 77KB out of 128KB (60%) [-1624]
1>  Used DATA_RAM: 21KB out of 320KB (6%) [-712]

The same does however happen with the BLE Advertisement example project.

1>  ------------------- Memory utilization report -------------------
1>  Used DATA_FLASH: 213KB out of 8192KB (2%) [+196]
1>  Used INSTR_FLASH: 774KB out of 3264KB (23%) [+1544]
1>  Used INSTR_RAM: 90KB out of 128KB (70%) [+148]
1>  Used DATA_RAM: 64KB out of 320KB (20%) [+136]

[Frank]

not working logs: http://pastebin.com/AUYRLb2g
working logs: http://pastebin.com/AUYRLb2g
diff: http://pastebin.com/AUYRLb2g

it seems only cpu0 has halted in the notworking logs?

I would really like to figure this one out, manually halting and programming is becoming a pain.

[support]

Hi,

Thanks, we have managed to reproduce this and it simply looks like the FLASH erase takes longer than the default timeout of 5 seconds.

Increasing the timeout to 10 seconds solved the problem in our setup. We will update the default timeout in the next toolchain release. As a workaround, please increase it manually by adding the following element to your .vgdbsettings file inside the DebugMethodProperties/Entries element:

        <KeyValue>
          <Key>com.sysprogs.esp32.openocd.alg_timeout</Key>
          <Value>10000</Value>
        </KeyValue>

[Frank]

Thanks!

[Author]

Posts