After Platformio, Python et al reinstall, can't upload to AZ-Delivery ESP-32 Dev Kit C V4 Dev board

PlatformIO Core
1

My upload fails, with the message…

Open On-Chip Debugger v0.10.0-esp32-20201202 (2020-12-02-17:38) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html embedded:startup.tcl:26: Error: Can't find interface/ftdi/esp32_devkitj_v1.cfg in procedure 'script' at file "embedded:startup.tcl", line 26 .pioinit:11: Error in sourced command file: Remote communication error. Target disconnected.: No error.

I wonder whether this is a catastrophic failure or there is a simple tweak.

This is platformio.ini:

[env:az-delivery-devkit-v4]
platform = espressif32
; platform = GitHub - platformio/platform-espressif32: Espressif 32: development platform for PlatformIO
board = az-delivery-devkit-v4
framework = arduino
board_build.f_cpu = 20000000L
upload_speed = 115200
monitor_speed = 115200

debug_tool = esp-prog
upload_protocol = esp-prog
build_type = debug
debug_init_break = tbreak setup
debug_speed = 500
build_flags = -O0 -ggdb3 -g3

I do have one question: Is it important to have the square brackets in the .ini file, or is this for we humans?

N,B. The platform URL is commented out because my system throws massive red errors otherwise. I’d be very grateful for any help for any fixes.

Thanks!

2

Does the file C:\Users\<user>\.platformio\packages\tool-openocd-esp32\share\openocd\scripts\interface\ftdi\esp32_devkitj_v1.cfg exist?

If not, delete the tool-openocd-esp32 folder and retry.

3

Yes, it does, and in exactly that place…

4

Is any antivirus active that could interfere with the execution of openocd.exe?

5

Yes, but this wouldn’t be its first encounter of this scenario and previous encounters didn’t throw up this problem. I’ll do a test with it turned off and report back.

Update:
I’d forgotten that I had problems with my antivirus software and so it wasn’t running at all.
By the way; I noticed that openocd.exe exists in two directories: “.platformio\packages\tool-openocd-esp32\openocd-esp32\bin” and “.platformio\packages\tool-openocd-esp32\bin”. The latter is from my original install - in December.

6

Hm that’s weird, mine doesn’t have that. You can safely remove the whole tool-openocd-esp32 folder (given that there are no custom modifications in there that you want to save) and PlatformIO will redownload a fresh version. Does that change anything?

1 Like
7

This is what the Terminal has to say afterwards Max:

Open On-Chip Debugger v0.10.0-esp32-20201202 (2020-12-02-17:38)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
debug_level: 1

adapter speed: 20000 kHz

WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
adapter speed: 500 kHz

Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
** Programming Started **
** Programming Finished **
** Verify Started **
embedded:startup.tcl:449: Error: ** Verify Failed **
in procedure ‘program_esp’
in procedure ‘program_error’ called at file “.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg”, line 92
at file “embedded:startup.tcl”, line 449
*** [upload] Error 1

Any idea?

8

Interesting so it got past that error. Hm,

I can only find a reference to this error in ESP32 OpenOCD can't set breakpoint. It seems weird that programming succeeds but then verification fails. Also weird that there is no output like

Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)

May also be related to JTAG flashing program_esp verify is failing · Issue #128 · espressif/openocd-esp32 · GitHub.

9

Well, it’s interesting about Manuel’s wiring suggestion because I’d already used a simple Youtube guide to wire it up and this didn’t use two USB’s. I’d already come across Manuels page when researching my earlier problems and have had both, two RS232 HS entries working and at another point one of those and a COM entry instead. In another post from Manuel he mentions that it’s probably best to use the 3.3V supply from the esp-prog to power the ESP32 and I wasn’t sure how this reconcilled with the two USB approach he’d suggested.

Yes, that AZ board is mine.

Verbose upload:

o.exe run --verbose --target upload --environment az-delivery-devkit-v4 <

Processing az-delivery-devkit-v4 (platform: espressif32; board: az-delivery-devkit-v4; framework: arduino; board_build.f_cpu: 20000000L; upload_speed: 115200; monitor_speed: 115200; debug_tool: esp-prog; upload_protocol: esp-prog; build_type: debug; debug_init_break: tbreak setup; debug_speed: 500; build_flags: -O0 -ggdb3 -g3)

CONFIGURATION: Redirecting...
PLATFORM: Espressif 32 (3.1.0) > AZ-Delivery ESP-32 Dev Kit C V4
HARDWARE: ESP32 20MHz, 520KB RAM, 16MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:

  • framework-arduinoespressif32 3.10005.210223 (1.0.5)
  • tool-esptoolpy 1.30000.201119 (3.0.0)
  • tool-mkspiffs 2.230.0 (2.30)
  • tool-openocd-esp32 2.1000.20201202 (10.0)
  • toolchain-xtensa32 2.50200.97 (5.2.0)
    LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
    LDF Modes: Finder ~ chain, Compatibility ~ soft
    Found 28 compatible libraries
    Scanning dependencies…
    No dependencies
    Building in debug mode
    ([“checkprogsize”], [“.pio\build\az-delivery-devkit-v4\firmware.elf”])
    MethodWrapper([“checkprogsize”], [“.pio\build\az-delivery-devkit-v4\firmware.elf”])
    Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
    RAM: [ ] 2.5% (used 13404 bytes from 532480 bytes)
    Flash: [== ] 15.4% (used 202264 bytes from 1310720 bytes)
    .pio\build\az-delivery-devkit-v4\firmware.elf :

section size addr
.rtc.text 0 1074528256
.rtc.dummy 0 1073217536
.rtc.force_fast 0 1073217536
.rtc_noinit 0 1342177792
.rtc.force_slow 0 1342177792
.iram0.vectors 1024 1074266112
.iram0.text 43448 1074267136
.dram0.data 8956 1073470304
.noinit 0 1073479260
.dram0.bss 4448 1073479264
.flash.rodata 48804 1061158944
.flash.text 100032 1074593816
.debug_frame 83832 0
.debug_info 1466086 0
.debug_abbrev 182103 0
.debug_loc 553243 0
.debug_aranges 32824 0
.debug_ranges 42560 0
.debug_line 726792 0=
.debug_str 909699 0
.comment 477 0
.xtensa.info 56 0
.xt.prop._ZTV9Printable 12 0
.xt.lit._ZN9IPAddressD5Ev 0 0
.xt.prop._ZN9IPAddressD5Ev 0 0
.xt.prop._ZN9IPAddressD2Ev 36 0
.xt.prop._ZN9IPAddressD0Ev 36 0
.xt.prop._ZTV9IPAddress 12 0
.xt.lit._ZN5Print5writeEPKc 8 0
.xt.prop._ZN5Print5writeEPKc 60 0
.xt.lit._ZN6String4initEv 8 0
.xt.prop._ZN6String4initEv 60 0
.xt.prop._ZNK6String3lenEv 60 0
.xt.prop._ZN6String6setLenEi 60 0
.xt.prop._ZNK6String7wbufferEv 48 0

Open On-Chip Debugger v0.10.0-esp32-20201202 (2020-12-02-17:38)

Licensed under GNU GPL v2
.xt.prop._ZTISt9exception 12 0
For bug reports, read

.xt.prop._ZTISt9bad_alloc 12 0
OpenOCD: Bug Reporting

debug_level: 2
.xt.prop._ZTVN10__cxxabiv120__si_class_type_infoE 12 0

.xt.prop._ZTVN10__cxxabiv117__class_type_infoE 12 0
adapter speed: 20000
kH.debug_macro 154961 0
z

Total 4359793
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
([“upload”], [“.pio\build\az-delivery-devkit-v4\firmware.bin”])
Info : FreeRTOS creation
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esp-prog
Info : FreeRTOS creation
openocd -d2 -s “.platformio/packages/tool-openocd-esp32/share/openocd/scripts” -f interface/ftdi/esp32_devkitj_v1.cfg -f board/esp-wroom-32.cfg -c “adapter_khz 500” -c “program_esp {{.pio\build\az-delivery-devkit-v4\firmware.bin}} 0x1000adapter speed: 500
kHz
0 v
erify” -c “program_esp {{C:/Users//.platformio/packages/framework-arduinoespressif32/tools/sdk/bin/bootloader_dio_40m.bin}}
0x1000 verify” -c “program_esp {{C:/Users//Documents/PlatformIO/Projects/Test after reinstallation/.pio/build/az-delivery-devkit-v4/partitions.bin}} 0x8000 verify” -c “program_esp {{C:/Users//.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin}} 0xe000 verify” -c “reset run; shutdown”
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 500 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Target halted, PC=0x40000400, debug_reason=00000001
Info : esp32.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Debug controller was reset.
Info : esp32.cpu0: Core was reset.
Info : esp32.cpu0: Target halted, PC=0x500000CF, debug_reason=00000000
Info : Set GDB target to ‘esp32.cpu0’
Info : esp32.cpu0: Core was reset.
Info : esp32.cpu0: Target halted, PC=0x40000400, debug_reason=00000000
Info : esp32.cpu1: Debug controller was reset.
Info : esp32.cpu1: Core was reset.
Info : esp32.cpu1: Target halted, PC=0x40000400, debug_reason=00000000
** Programming Started **
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Flash mapping 0: 0x10020 → 0x3f400020, 53 KB
Info : Flash mapping 1: 0x20018 → 0x400d0018, 103 KB
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Auto-detected flash bank ‘esp32.cpu1.flash’ size 4096 KB
Info : Using flash bank ‘esp32.cpu1.flash’ size 4096 KB
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
** Programming Finished **
** Verify Started **
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Flash mapping 0: 0x10020 → 0x3f400020, 53 KB
Info : Flash mapping 1: 0x20018 → 0x400d0018, 103 KB
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
Info : Auto-detected flash bank ‘esp32.cpu0.flash’ size 4096 KB
Info : Using flash bank ‘esp32.cpu0.flash’ size 4096 KB
Info : esp32.cpu0: Target halted, PC=0x40091856, debug_reason=00000001
embedded:startup.tcl:449: Error: ** Verify Failed **
in procedure ‘program_esp’
in procedure ‘program_error’ called at file “C:/Users//.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg”, line 92
at file “embedded:startup.tcl”, line 449
*** [upload] Error 1

10

Can you configure the wireup in such a way that the board is powered by USB and not the esp-prog adapter? (But still keep the common GND of course).

Otherwise please check that this problem occurrs or not occurrs with the minimal blinky code.

11

Max; I would have tried this already but unfortunately don’t have two micro USB cables. I am expecting one next week and so could try then if I’m still having problems. That said, I have off course had the single USB setup working - though I’ve had more trouble than I could shake a stick at - one day reasonable - the next dreadful. I must admit that I never quite understood why two drivers needed installing/configuring for one USB connection and I’ve heard that the esp-prog can comunicate quickly in principle - and this definately appeals. Todays testing has been using a sketch that is effectively the blinky sketch - two delays and two digitlal writes. Incedentally, todays install was a slightly newer version of Platformio than was deleted. I think VSC was slightyly newer too. I should also say that todays headache came after a particularly good performance yesterday. Today, I needed to plug into a different USB-A port on the same machine - and everything went west from there!

Thanks for coming back Max - I really apreciate it :slight_smile:

Update:

I’ve just seen this post from you Max:

As can be seen in the PIO forum topic which I have linked above, the on-board debugger is a 2-channel FT2232 chip. Channel 1 can be jumpered to the JTAG and channel 2 can be jumpered to the UART (which it is by default), and they both work at the same time independently. So keep the ‘Enable UART’ jumpers in place for RXD and TXD. That’s why the post also says to only change the ‘Interface 0’ USB device and not the ‘Interface 1’ one, because that’s the UART you’re using to upload the firmware.

…and that leaves me wondering what the driver configuation should be for a separate USB connection for each of the channels. Effectively, they remain, I guess - but presumably I would then need to ensure that the FTDI driver attached to the correct board, correct?

12

The purpose of the second USB cable is to provide sufficient power to the ESP32 as it can draw more current than the ESP-Prog can provide.

Don’t mess with drivers. Your setup is almost working. Drivers are ok.

At the point, the most likely causes are:

  • Insufficient power --> try the second USB cable
  • Communication issue between ESP-Prog and ESP32 --> use short cable, do not connect via breadboard, lower adapter speed (though you already seem to have lowered it to 500kHz)
  • Invalid board configured --> you do have an AZ-Delivery ESP-32 DevKit V4, right?
13

Hi Manuel, yes, that’s my board.

It’s funny, but my experience is a real roller coaster. No sooner do I feel I’m getting somewhere, than I have a new issue. Earlier, all was good - except for a peculiar inability to read outputs, back in to test the code and my circuit. I’ve long thought that intefrence or current was a consideration, because no session is the same. I’d inserted a cap on the 3.3V coming from the esp-prog to the ESP32 board because of this suspicion. My latest irritation is that my files seem to be cached. I can alter the code and the new file compiles, but without changing its behaviour when run - and I regularly “clean”. Does this make sense maybe? Could voltage levels maybe affect this too - without being noticed by the compiler? As for the debugging speed, I saw a post by Max that seemed to show this to be an art too. Based on his advice, at one point I edited a file directly rather than rely on platformio.ini to work. But again, this just falls right into my experience with the avant garde behaviour from this setup.

Thanks!

14

Hello Manuel, I thought an update would be in order…

My second cable seems to have calmed the setup down quite a bit, though I occasionally still get odd behaviour such as when the a breakpoint in the main file is hit, the IDE opens another file (not assembly but cpp) and breaks there. It would be great to know where this problem lies.

I now have mainly my own coding to debug and this is proving to be a puzzle. I have a issue whereby an array that is collecting shifted data from the output of a TLC5940 chip - to verify it’s correcteness - is showing it not to be correct. It doesn’t look like noise as such and so I suspect that something is juggling the code. Here is the commented code from the function in question:

void TLC5940_ClockInDC(void) {
  gpio_set_level(DCPRG_PIN_21,LOW); //test of original function (reversed for NPN signal conditioning)
  gpio_set_level(VPRG_PIN_22,LOW); //test of original function (reversed for NPN signal conditioning)
  uint16_t localCounter = 0; //Loop counter
  uint16_t endOfRound = 0; //Number of whole data set's having been shifted
  uint32_t delayMicros = 5; //Delay after pin set's - to allow settling
  for (;;) {
    if (localCounter > (TLC5940_N * 96) - 1) {
       gpio_set_level(XLAT_PIN_17,LOW); //test of original function (reversed for NPN signal conditioning)
       delayMicroseconds(delayMicros);
       gpio_set_level(XLAT_PIN_17,HIGH); //test of original function (reversed for NPN signal conditioning)
       delayMicroseconds(delayMicros);
       if (debug_dc) { //Global variable set in "setup"
        localCounter = 0; //For debugging - because it isn't reset "normally"
        endOfRound++; //End of array iteration, so record the complete loops
       }else{
         break; //...out of for loop
       }
    }else{
      if (dcData[localCounter]) { //If data element is HIGH
        gpio_set_level(SIN_PIN_23,LOW); //test of original function (reversed for NPN signal conditioning)
        delayMicroseconds(delayMicros);
      }else{
        gpio_set_level(SIN_PIN_23,HIGH); //test of original function (reversed for NPN signal conditioning)
        delayMicroseconds(delayMicros);
      }
      gpio_set_level(SCLK_PIN_4,LOW); //test of original function (reversed for NPN signal conditioning)
      delayMicroseconds(delayMicros);
      gpio_set_level(SCLK_PIN_4,HIGH); //test of original function (reversed for NPN signal conditioning)
      delayMicroseconds(delayMicros);
      if (localCounter == (TLC5940_N * 96) - 1) {
        digitalWrite(SCOPE_PIN_27, HIGH); //Send signal to scope to cpature outputs from shift register
        delayMicroseconds(delayMicros);
        digitalWrite(SCOPE_PIN_27, LOW);
        delayMicroseconds(delayMicros);
      }
      if (debug_dc) {
        dcTestArray_Real_Pin_State[(localCounter + 3) % (TLC5940_N * 96)] = gpio_get_level(SOUT_DEBUG_PIN_16);
        delayMicroseconds(delayMicros);
      }
      if (endOfRound > 1) {
        if (dcTestArray_Real_Pin_State[localCounter] != dcData[localCounter]) {
          Serial.println("localCounter: " + String(localCounter) + " Not equal");
          delay(300);
        }
      }
     localCounter++; //Increment loop count
    }
  }
}

Please advise whether you can see any obvious cause of the strange results when writting to “dcTestArray_Real_Pin_State” array. I hassen to add: It’s not my code per se that I feel I need help with - because it’s only test code currently - but how FreeRTOS might be doing something in the background. Incedentally, I tried to set up a interrupt that would insert the read-in values into the array (in “real time”), but I couldn’t get it to work. Aso; I’m assuming that all my code is executing on core 0 - as I haven’t requested anything to do with specifying a core.

Many thanks.

15

@2tricky You lost me somewhere along the trip. Can you give me an update: Does the upload via ESP-Prog now work? Have the PlatformIO-specific problems been sorted out?

As for your code: I’m not familiar with the TLC5940 chip. So I don’t sufficiently understand what you are trying to achieve. The only thing that comes to mind: ESP32 Arduino is built on top of an RTOS, which can interrupt your code at any time. So the precise timing the code is trying to achieve might be messed up. Have you considered using SPI instead of bit-banging?

If you really want help with this code, you certainly need to better describe the overall setup (incl. schematics), what you expect to happen and what happens instead.

16

Morning Manuel,

Yes, the upload works, and with probably slightly better reiability than the single-cable route. That said; it is still flaky for me. I still get day’s when the breakpoint in platformio.ini…

debug_init_break = tbreak setup

doesn’t stop at setup, but in another cpp file (not mine). I think I have also reported that it has also stopped in an assembly file too on occasions.

One thing that I must say is that this function was working a few weeks ago - before the two-cable trick - and I had moved onto the next function to debug. The function (above) is now misbehaving again and it occurs to me that just maybe this is part of the same problem of the erant breakpoints. It seems to me that once the system has a problem with a breakpoint, that this might wreck working code. What do you think? Is there a way to properly clean everything? I’ve mentioned that I clean quite a bit (in hope) and I’ve mentioned cached files before - and this seems related to me. I haven’t yet found a way to get out of the errant breakpoints issue reliably. I simply reboot the Win 10 PC and/or close folders in the IDE, unplug the esp-prog and the ESP32 board and “clean”. There is a feature in the Platformio menu that offers cleaning the flash, but it complains when I try to use it and doesn’t complete.

Incedentally, setting the com port in the ini file doesn’t wortk for me either - COM3 or COM[3] - as given on the espressif site. I have to set the port in the monitor at run time, using COM3 - which works.

The chip in question allows the setting of a Dot Correction facility (adjusting for brighter LED’s for instrance) and each chip has 16 channels. There are 6 bits per channel for dot correction, so there are 96 bits, per chip to be set. I have two chips currently - hense I shift 192 bits in total. My loop aims to push these FIFO bits out for recording in my array - to check the system. I am only doing this because I wasn’t getting the correct results from the chip outputs.

Thanks Manuel

17

The setup with a single USB cable has probably caused different stability issues as the ESP32 didn’t get enough power. It’s unlikely that the setup with two cables has made anything worse. You are now able to upload code reliably – that’s progress.

Breakpoints are a separate issue. They are indeed flaky on the ESP32, mainly the ESP32 only supports two, one of which is required for single stepping. But there are additional issues that I’ve observed without understanding the root cause. I can’t really help you on that.

I’m not even sure that cleaning help with breakpoints. But if it’s needed, I’ve found that deleting the .pio folder in your project directory and then rebuilding the project is the easiest and most reliable approach. There is no need to clean the MCU flash memory. The next upload will create a reliable state.

Regarding the COM port, I don’t understand your issue. Information from the Espressif site will not apply as uploading and monitoring is handled by PlatformIO. It is possible to specify the COM port in platfromio.ini.

18

Ah, so there is an invisible breakpoint so to speak, that is used for single stepping. Is it counted as one of your two, if you don’t single step? I’ll try deleting the .pio folder…

The com port can’t be specified in platformio.ini using either “monitor_port = COM3” or “monitor_port = COM[3]”. The terminal reports an error of sorts (in red) for both scenarios.

Update:

Having got nowhere as yet with this, I have an idea… What follows is the feedback from hovering over my array variable that is reading the output from the shift register chip, back in. It has a strange opposite alternating symmetry, after each loop of 192 bits having been shifted. I’m wondering whether I have a type/class-overflow somewhere. I’m not sure why the values show as a character ‘001’ - as the type is uint8_t. I should also say that the ‘input’ array holds a 1 (int) in element 0, a 0 (int) in element 1, a 1 (int) in element 2, etc., and no sequences of multiple 0’s or 1’s at all:

After completing loop 2:
“\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000”, ‘\001’ <repeats 65 times>, “\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000”, ‘\001’ <repeats 34 times>

After completing loop 3:
‘\001’ <repeats 31 times>, “\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000”, ‘\001’ <repeats 65 times>, “\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001\000\001”

Thanks Manuel!