Mac: ESP32 – PlatformIO – JLink – ESP-PROG2

This post is for you if you can get the esp32 blink project to load and run and blink the blue light, but debugging with hardware is a problem, and using printf has issues with the “monitor.”

I was able to get the blink program to run under ESP-IDF, but debugging was a pain.

With the older ESP32, you have to use an external JTAG Debugger. Unfortunately, the latest ESP32 units cannot handle classic bluetooth.

Under PlatformIO, I loaded the bluetooth example and had garbage print on the “monitor” before the Serial.println() came out, when using a classic bluetooth example project. I never saw that with the standard blink project.

I saw several posts out there that had that particular issue. The solution for me was to add a couple of lines to the platform.ini file for my esp32 board. Those lines are monitor_dtr and monitor_rts. Once I did this, it appeared to stop the garbage printing before my debug printf() lines were able to print my messages.

Inside the PlatforIO.ini file for jlink:

[env:esp32doit-devkit-v1]
platform = espressif32
framework = arduino
board = esp32doit-devkit-v1
monitor_speed = 115200
monitor_dtr =0
monitor_rts = 0
# JLINK to ESP32 pins
# Signal. JlinkPin  ESP32Pin
#  TDI.     5         D12
#. TMS.     7         D14
#  TCK.     9         D13
#. TDO.     13.       D15
#JLINK CAN INTERRUPT.  PROG2 CAN also
debug_tool = jlink
upload_protocol = jlink

Once the garbage printout was resolved, I started working on debugging hardware.

I used jumpers to go from the JLINK wire to the ESP32. After many trials, I finally was able to get jlink working with PlatformIO at home. I brought the project to the office, and it worked. The project I created at the office still does not work with jlink. Don’t know why, and don’t care.

PlatformIO does not know about ESP-PROG2, but no worries. Use esp-bridge. That worked for me.


Again, inside the PlatformIO.ini file:

[env:esp32doit-devkit-v1]
platform = espressif32
framework = arduino
board = esp32doit-devkit-v1
monitor_speed = 115200
# esp-bridge allows ESP-PROG2 to work
# esp-prog2 allows for breakpoint setting while running.
# that does appear to work with jlink, also.
debug_tool = esp-bridge
#upload_protocol = esp-bridge
debug_init_break = tbreak setup

The “tbreak setup” causes a temporary breakpoint at the setup() function in the blink project.

Warning About Bluetooth

I loaded the Arduino bluetooth project and compiled it. Disaster. Monitor program showed lots of trash. Serial.println() did not work well. Single Step failed a lot. Bluetooth did not work.

There were lots of posts on the internet complaining that Bluetooth Classic did not work. Some complaints of trash on the monitor.

After about a dozen search queries, I found a github page with bluetooth classic functionality for Arduino. The project linked below contained an ino file that I was able to pull from.

(For you classic “C++” programmers, a file with .ino ending is a CPP file that is managed by the Arduino project manager. It is simply another way to package a file. Underneath that file is a “main.cpp” that sets up the base environment. For ESP32, that is FreeRTOS. You can immediately start using FreeRTOS calls, etc.)

Include the <Arduino.h> in your file and the correct bluetooth includes, and you can start using Bluetooth. You may or may not have to use PlatformIO to bring in libraries. After a certain point of mucking around, I was able to get bluetooth to work.

Here is the page and project link:

https://github.com/espressif/arduino-esp32/blob/master/libraries/BluetoothSerial/examples/DiscoverConnect/DiscoverConnect.ino

I took that code and put it piecemeal into the Arduino Blink project, a bit at at time and compiled it.

It worked. Printout worked. No trash on the monitor.

I believe the Arduino Bluetooth example project is misconfigured and fails quite a bit. I suspect stack overflows and other issues.

Once I started modifying the Arduino Blink, I was able to get the Bluetooth stack to connect to an OBDII mini, query it, and get a response.

If you use ESP32-S3, the built in debugger is accessed by the following line in the PlatformIO.ini file, replacing the jlink or esp-bridge.

debug_tool = esp-builtin

Fini

The ESP32 is a remarkable and cheap system. The FCC approval allows you to use the project without having the expense of dealing with FCC testing. I’ve been down that road and if you get a bad testing facility in, for example, Texas, you can be beating your head against the wall with no success. That facility had external signals bleeding into the test room.

Some California testing facilities are better and cheaper, and go the extra steps to make sure your product works without having more “test fees” added on top of your development costs. You have been warned.

The main problem you will have in dealing with the ESP32 is the large amount of information you have to process before you can get the unit to do what you want. The official information is fragmentary and sometimes not quite right. The unofficial forums that provide information can be fairly acerbic, so you need a thick skin for some of the more biting replies.

Bluetooth works, just don’t use the official projects. Make your own and test step by step so you can verify each section as not being a problem. Especially when using asynchronous…..

NOTE: BLUETOOTH HATES SINGLE STEPPING. If you have a bluetooth connection, single stepping after a breakpoint will disconnect you and ruin your evening. Restart the processor completely after each breakpoint is triggered. You are welcome.

ENJOY!

Add a Comment

Your email address will not be published. Required fields are marked *