Lora 32(v4) and arduino setup

#1

Hi
I updated Heltec ESP 32 Series Dev-boards in Arduinos board manager (old version 3.0.2, new version 3.0.2) but after update i dont have new v4 board on the list.
So i downloaded .zip from github https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series
and pasted it where my current lib was:
C:\Users\XxX\AppData\Local\Arduino15\packages\Heltec-esp32\hardware\esp32\3.0.2

But now i cannot compile it atr all:
compiler cannot find partitions.csv, bootloader.bin and other files.
Any one know good way to update Arduino for v4 board ?

LORA V4 Won't switch to bootloader mode
#2

I tried it myself and had to jump through many hoops. I know quite well how the Arduino system works but it took me half an hour to get going, and I cannot make simple instructions out of all the steps I triedā€¦ hoping @navi or @Supporter can help out with a clean update!

1 Like
#3

I found installation far simpler than actually flashing a v4.

Oh, wait, I donā€™t have a v4 because Iā€™m not special enough. :sob:

#4

Good to know I am not the only one with such problems.

#5

hello, I have the same problem, I canā€™t find WiFi LoRa 32 (V4) in my boards list.
My setting is:

Any help ?

#6

Similar problems hereā€¦ The only way I could get the V4 board to appear was to download the latest version (and I mean the latest version, not the version labelled as ā€˜Latestā€™ and dated 10 May) of the Heltec_ESP32 library from GitHub.

Iā€™m using a Mac and had to go to a relatively recent version of macOS (14.7.1), update to the latest Arduino IDE (2.3.6) and download all support software from GitHub (the most recent updates, not the ones labelled as the ā€˜Latestā€™), just to get code to compile. I tried doing everything from inside the IDE, but my efforts failed as did your own. And they failed many times before I gave up and updated my OS and the IDE (because Iā€™m one to let sleeping dogs lieā€¦ if it ainā€™t broke, I donā€™t try to fix it. My life is busy enough as it is and things have been just fine for years on macOS 10.14.5 and IDE 2.2.1).

Either way, things are still not really working as they should, but I canā€™t yet eliminate my local software environment as the cause of my remaining problems.

I always buy two of anything (I wasnā€™t special enough to be given a sample to test either :wink:), so that I have a reference when trying to sort out these sorts of problems. The modules as supplied ran the factory software they were shipped with. They both ran pretty much as Iā€™d expect, based on what Iā€™ve seen with other modules in the past. Iā€™ve now uploaded some of the example sketches to one of these, but the sketches Iā€™ve uploaded do not produce any output to the Serial Monitor, even the most basic of sketches. I can blink the LED, write to the display, and run general code, but I canā€™t yet get anything from Serial.print(). Also curiously, thereā€™s absolutely nothing on the Serial monitor when I reboot the module, although the module as shipped is similarly silent (i.e. no apparent boot message)ā€”in the past, there has always been some sort of boot message.

And while there is a WiFi_LoRa_32_V4_FactoryTest.ino sketch available on the GitHub repo (that you will only get if you download the most recent version of the example sketches), I do not believe that this is the software that is loaded on the module when shipped. I can upload and compile this sketch (I made sure I had a copy of what I thought would have been the software on the module when shipped, in the belief that, if all else failed, I would be able to return it to this state), but it does not behave like the factory shipped module. It too now fails to produce any Serial Monitor output, unlike whatever the factory shipped software originally on it was, which did, ultimately, happily send output to the Serial Monitor, although it writes several things to the display before doing anything with the Serial Monitor. The aforementioned Factory Test sketch [should] write the Chip ID to the Serial Monitor immediately after displaying the Heltec logo on the displayā€”this is not the behaviour observed with the module as shipped from the factory.

Anyway, I just thought Iā€™d add this to the discussion at this point. Iā€™ve still a way to go before I could declare my efforts a success, but I recall that we also had trouble getting things set up satisfactorily when the V3 module was first released. I was really hoping that Heltec might have improved their quality control process since then butā€¦ here we are againā€¦

#7

Iā€™m starting to move to virtual machines to accommodate such idiosyncrasies rather than update one thing and find another stops working. Whilst I can roll back on my Mac, its still a PitA.

Asking for feedback on a pretty much finished design rather than doing a feature survey was pretty much a sign. Not getting Alpha boards to those that can just to check the BSP package. I got a tracking number in the end but it shows no sign of anything being shipped. The Meshtastic thingy took weeks but Ali can send in days.

I know it goes against the spirit of it all, but the best solution is to not reveal the fixes so that those that need assistance petition Heltec rather than us giving up our time to solve such things.

The frustrating thing in all of this is that once weā€™ve got the docs & BSP sorted, the kit is good.

1 Like
#8

Thank you for having posted your experience, very interesting for me.
I want to mention that I have requested directly to Heltec a way to address WiFi LoRa 32 (V4) in my Arduino environment.
Heltec replied in a couple of days as follows:

Sorry,
For now, it can only be updated via GitHub. We will update the Arduino library in the coming days.
** Richard**

so, Iā€™m waiting for this update to happen ā€¦ and waiting ā€¦

#9

Really struggling to get my V4 to run as-well. Sketch uploads but no display or serial output

#10

Well itā€™s a little reassuring [for me] that someone else isnā€™t getting serial outputā€¦

Did your display work when the module was first powered on [and ran the factory installed software]? Mine did, and it also produced serial output then. But Iā€™ve not yet seen any serial output from any code that Iā€™ve compiled and uploaded.

Are you using the Arduino IDE? Platform IO? How did you load the Heltec support software?

#11

Did you guys remember to configure the USB CDC on boot? Because it doesnā€™t have a Serial chip, USB is connected straight to the ESP32.

1 Like
#12

Huh! That was it! After enabling USB CDC On Boot I am seeing serial output.

I had noticed that the USB interface was different, and I had seen all the ā€˜newā€™ configuration options, but had not appreciated the implications. Do you have any insight into the impact of the other [new] configuration options? Some are a little more obvious than othersā€”there are several there, for example, that appear to relate to the use of the USB interface, which it might ultimately help to understand. Are these ESP32 things, since it would seem they relate to this ā€˜newā€™ style of USB interface, identified in a data sheet or the like somewhere?

Just for the record then, hereā€™s the setup thatā€™s now working for me. Iā€™m currently working on a Mac running macOS 14.7.5 and the Arduino IDE 2.3.6 (default setup).

  1. Create the directory ~/Documents/Arduino/hardware/heltec/esp32
  2. Download the current version of the WiFi_Kit_series software (from the GitHub repoā€”click on the CODE button and download the .zip file. At some point this may become the release you get if you download via the ā€˜Latestā€™ button, but it wasnā€™t when I tried that option) into this directory
  3. Using the Terminal application, navigate to the ~/Documents/Arduino/hardware/heltec/esp32/tools directory and enter the command: python3 get.py
  4. Create the directory ~/Documents/Arduino/libraries
  5. Download the current version of the Heltec_ESP32 library (from the GitHub repoā€”same deal as before, download the .zip archive via the CODE button) into this directory
  6. [Re-]Start the Arduino IDE
  7. If this has all gone according to plan, you should be able to find WiFi LoRa 32(V4) in the BOARDS list, something like /dev/cu.usbmodem14101 Serial Port (USB) in the PORTS list and the so-called WiFI_LoRa_32_V4_FactoryTest.ino under the File > Examples > Heltec ESP32 Dev-Boards > Factory_Test menu. To compile and run this sketch, you will also then need to load the Adafruit_GFX and Adafruit_BusIO libraries through the IDE Library Manager.
  8. When compiling a sketch for the V4 module, from the Tools menu, ensure that USB CDC On Boot is enabled

EDIT-1: Fix a typo
EDIT-2: Correct the order of the last two steps in the above
EDIT-3: The requirement for Step 8 above is a result of the default settings in the boards.txt file. A pull request has been submitted to rectify this situation but until that change is made, the ~/Documents/Arduino/hardware/heltec/esp32/boards.txt file can be updated at lines 2777 and 2778 to set the defaults to Enabled and 1 respectively. As the settings suggest, this will enable USB CDC On Boot by default when the V4 board is selected.

#13

More ā€œMCU that supports USB directlyā€ things - of which there were many like SAMD and STM32 before it became ā€˜easyā€™ to use on ESP32, the C3 & S3 range seems to have taken it to heart.

There is also a ARDUINO_USB_MODE - which is the more fundamental flag that enables the USB capable pins to actually do USB mode which includes JTAG debugging. The CDC flag directs the Serial.println from the default serial pins to the USB as a Serial device.

The boot loader activates both USB & default serial to negotiate a flash cycle when the boot pin is enabled on power up / reset. On a good day, with a fair wind and the right number of freshly slaughtered chickens, USB will automagically reset the chip to allow you to flash. But typically it doesnā€™t reset at the end to run your new firmware. YMMV. It may be humidity related. Or tracking the Dow. The serial works as it always did, as long as the MOSFETs are there to use the serial signals to do the boot/reset combo for you.

USB is substantially faster for flashing unless you have a really solid USB to serial adapter that can go at full tilt. On my Mac I frequently have to plug a C3 or S3 directly in to the Mac as going through the powered hub on my desk is unreliable.

#14

Thanks @nmcc, you learn something new every day (if youā€™re lucky)! I also found some additional discussion in the ESP32 docs, and no doubt Iā€™ll find more now that I 've got some idea of what Iā€™m looking for.

#15

@UniquePete those are pretty clean instructions. My journey was a mess and I ended up copying the core and a whole lot of missing files into the AppData/Local/Arduino15 hardware folders which is where the actual cores are installed. Couldnā€™t get the documented instructions working.

About the Serial: from the C3/S3 onwards, all ESPā€™s have a dedicated USB host controller directly in the chip. This means that the PC connects to the ESP, instead of to the CP2102.
This has the following effects:

  1. Whenever you reset the ESP, the computer needs to reconnect, because the connection got killed during reset. So you wonā€™t ever see reboot messages unless the ESP does a soft reset.
  2. The default Serial (if you donā€™t set USB CDC) is now ā€˜redirectedā€™ to the actual Tx/Rx pins that are labelled Tx/Rx. So you could have caught the Serial prints using a separate USB controller.
  3. If you donā€™t set USB CDC, you can use USBSerial instead of Serial to get the output over the USB host lines (D+/D-).
  4. If you set USB CDC, the USB host is set as the native Serial comms. In the early days of CDC I think this happened by #define Serial USBSerial but to my knowledge, itā€™s now changed to being handled somewhere internally in a proper way.

For those of you using PlatformIO and wishing to use USB CDC, these two flags are required:

build_flags = 
    -D ARDUINO_USB_MODE=1
    -D ARDUINO_USB_CDC_ON_BOOT=1
#16

A side effect of this is that if you have a serial monitor program, it will report the disconnect. I use CoolTerm and it automagically reconnects when the port returns.

Which means you can actually have two at the same time, Serial over the Rx/Tx pins and USBSerial over the USB. Which has its use cases for debugging via Serial and using USBSerial to talk to a desktop app of some sort.

#17

The aforementioned MOSFETs arenā€™t on the schematic so not automagic reset to flash mode - if you use the serial port, itā€™s the manual two finger shuffle all the way, yeah baby yeah.

#18

The USB host controller has some intelligence. Iā€™ve had automagic flashing on boards without the MOSFETs before. But then I did slaughter about a dozen chickens beforehand.

#19

Focus my man, focus. I said serial, not USB. Itā€™s serial connections that need the MOSFETs

#20

To answer my question from above, a description of all the relevant options in the Tools menu when an ESP32 board is selected is provided in the Espressif on-line documentation.