ESP32 update problems

Sysprogs forums Forums VisualGDB ESP32 update problems

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #9942
    Frank
    Participant

    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?

    #9943
    support
    Keymaster

    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.

    #9953
    Frank
    Participant

    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, 10 months ago by Frank.
    #9967
    support
    Keymaster

    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.

    #9975
    Frank
    Participant

    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.

    #9979
    support
    Keymaster

    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.

    #10035
    Frank
    Participant

    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
    #10045
    support
    Keymaster

    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.

    #10064
    Frank
    Participant

    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, 10 months ago by Frank.
    #10077
    support
    Keymaster

    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];
    }
    #10098
    Frank
    Participant

    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]
    #10114
    Frank
    Participant

    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.

    #10128
    support
    Keymaster

    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>
    #10130
    Frank
    Participant

    Thanks!

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