Wireless Stick Lite V3 reboots after uploading a simple code

#1

I have a Wireless Stick Lite V3 in Arduino IDE configuring the WiFi Lora32 (V3)/Wireless Shell(V3)/Wireless stick lite(V3) as board, but unfortunately after uploading the simplest code possibly it reboots after initializing:

16:14:16.236 -> ESP-ROM:esp32s3-20210327
16:14:16.236 -> Build:Mar 27 2021
16:14:16.236 -> rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
16:14:16.236 -> Saved PC:0x400454d5
16:14:16.236 -> SPIWP:0xee
16:14:16.236 -> mode:QIO, clock div:2
16:14:16.236 -> load:0x3fce3808,len:0x43c
16:14:16.236 -> ets_loader.c 78
16:14:17.365 -> ESP-ROM:esp32s3-20210327
16:14:17.398 -> Build:Mar 27 2021
16:14:17.398 -> rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
16:14:17.398 -> Saved PC:0x400454d5
16:14:17.398 -> SPIWP:0xee
16:14:17.398 -> mode:QIO, clock div:2
16:14:17.398 -> load:0x3fce3808,len:0x43c
16:14:17.398 -> ets_loader.c 78
…

Code:

#include “Arduino.h”
#include “WiFi.h”
#include <Wire.h>

void setup()
{

Serial.begin(115200);

delay(5000);

Serial.println("HOLA");

}

void loop()
{
// put your main code here, to run repeatedly:
delay(99990000);
}

Thank you in advance!

Heltec v3 infinite loop (SPI_FAST_FLASH_BOOT)
#2

I usually start with the Blink example, because it doesn’t involve any ‘extra’ libraries. If that won’t load and run, I look at my installation of the core hardware libraries. If it does load and run, I work through more complex examples (i.e. with additional libraries) to check for incompatibilities there.

#3

Thanks for your answer.

In fact I test it with following code:

void setup()
{

Serial.begin(115200);

delay(5000);

Serial.println("HOLA");

}

void loop()
{
// put your main code here, to run repeatedly:
delay(9999);
}

Obtaining this:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78
ESP-ROM:esp32s3-20210327
…

#4

OK, I can confirm that the boot message that is generated when I reset my WSL V3 after uploading your code is unusual in that it suggests that there has been an error in the upload:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x43c
load:0x403c9700,len:0xbec
load:0x403cc700,len:0x2a3c
SHA-256 comparison failed:
Calculated: dcde8d8a4817d9bf5d5d69a7247667264e4e10ac7493514868b61f5aa6146539
Expected: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Attempting to boot anyway...
entry 0x403c98d8

but a few seconds later I see

HOLA

suggesting that the program did indeed upload and execute successfully, in spite of the apparent error message.

And on closer inspection, it seems that that initial message is issued any time I upload a sketch, but the sketch executes normally thereafter.

There would, however, appear to be a problem with the WSL V3 definition in that the LED_BUILTIN variable does not appear to be being set correctly. When running the Blink example as provided (i.e. using the LED_BUILTIN variable to specify the pin to be ‘blinked’) does not result in a blinking LED. If I note from the WSL V3 pinout diagram that GPIO35 is identified as the LED_Write pin, and use “35” instead of LED_BUILTIN, all is well—I see a blinking LED. But I also see the above type of message, reporting SHA-256 comparison failure, before the code ultimately executes as expected.

Given that I have also found errors in the WiFi LoRa 32 V1 board definition, I wonder if other elements of the new code might not have been QA’d as well as they might have been…

Looking again at the two error messages, I note a difference between the upload modes:

mode:QIO, clock div:2

vs

mode:DIO, clock div:1

I remember fiddling with this at some point in the past (nothing to do with the V3 boards), and it is a selectable option when dealing with some ESP32 devices, but there doesn’t appear to be any way to easily switch between the two, so I wonder how this difference has arisen—I think this comes from the boards.txt file, and I would have thought we were both using the same version (0.0.7?).

Having just looked at the boot.txt file, I see the following two entries (the WiFi_LoRa_32_V3 definition applies to the three V3 boards, as listed in the board selection):

WIFI_LoRa_32_V3.build.flash_mode=dio
WIFI_LoRa_32_V3.build.boot=qio

so maybe that’s all it is, the different between the initial load that I’m seeing

rst:0x1 (POWERON)

and the reset that you’re seeing

rst:0x7 (TG0WDT_SYS_RST)

Other than the above observations, I’m at a bit of a loss for anything else to suggest at this point.

#5

Hi there Pete,
I have been having the same problem as mrojas but instead with the Wireless Stick V3 (not lite).

I am presented with the exact same message as mrojas(with mode:QIO). This message occurs no matter what the code I am uploading.

I am using the same ‘WiFi Lora32 (V3)/Wireless Shell(V3)/Wireless stick lite(V3)’ as board.

There is no Wireless stick V3 board option so I thought that this would be the next best thing. What are your thoughts on this?

This is because when I selected the ‘Wireless stick’ it threw an error because the chip was the esp32-s3 not the esp32 (Presumably the wireless stick library is for older versions of the wireless stick).

I have tried changing all reference to QIO in the boards.txt file with no luck. The boot message still displays mode:QIO as well. Where is the boot.txt file you mention? I could not seem to find it.

I just received the board yesterday and this has proved highly frustrating.

Any help with this matter would be much appreciated.

Kind Regards,

Max

#6

Hi @max-j,

Given that Heltec seems to have bundled the definition of all of its S3-based modules into one, I would have thought your guess on which definition to use was as good as any. I’ve never used a Wireless Stick, so I’m not sure what difference the on-board display makes to anything, but it shouldn’t impact either the basic processor or LoRa stuff, so I can’t imagine there’d be any difference when it comes to working with sketches that don’t involve the display.

On my Mac, the boards.txt file is located in the user’s Library folder:

~/Library/Arduino15/packages/Heltec-esp32/hardware/esp32/0.0.7/boards.txt

But on inspection, I can’t see a definition in there for a Wireless Stick V3 board, so I’m not sure what’s going on there—it may just pick up what appears to be the common definition for the other S3 boards and really, it should be much the same at the Wireless Stick Lite V3 board. But maybe have a look (in that boards.txt file) at the definitions for the original Wireless Stick, Wireless Stick Lite and WiFi LoRa boards and see if you can see anything in there that might give you a lead.

There is a pins_arduino.h file down there too, in the 0.0.7/variants folder. I don’t know if anything in there might give you a hint as to the source of the problem, but I can’t really see how anything in there would impact the boot process.

We could hope that @mrojas reads your post and lets us know if he got his problem sorted.

Once again, because I haven’t actually seen the problem you’re reporting, it’s hard to suggest what else might help. I think those of us working with the new boards have encountered problems at all levels—with the actual hardware, with the board software and with the IDE software—which makes it difficult to pinpoint the source of any particular problem. At this point, while it might not help much, I don’t think we can eliminate any one of those possible sources.

If you read through the various accounts, I think you will find a common thread to be the fact that people have resolved their issues through stubborn perseverance and dumb luck as much as, if not more than any particularly logical approach to problem solving.

#7

Hi @UniquePete

We seem to have solved the issue by changing from running Arduino on Linux, to running Arduino on windows with new USB to UART drivers. (No sure if the drivers were important or not but that’s all that was changed).

It still runs using the ‘WiFi Lora32 (V3)/Wireless Shell(V3)/Wireless stick lite(V3)’ as the board.
It’s now in the state which you showed in your first post,

SHA-256 comparison failed:
Calculated: dcde8d8a4817d9bf5d5d69a7247667264e4e10ac7493514868b61f5aa6146539
Expected: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Attempting to boot anyway...

but with the code executing successfully afterward which is the main thing.

Thanks for your suggestions and help.
#8

I’m getting the same kind of symptoms. The board is a new Wifi Kit 32(V3). It works just fine sending a sketch from Windows 10, but not from Linux (Redhat 9)

It seems like the board is being detected correctly by Linux after compiling and the code is pushed and verified:
Serial port /dev/ttyUSB0
Connecting…
Chip is ESP32-S3
Crystal is 40MHzFeatures: WiFi, BLE
MAC: f4:12:fa:83:0a:f8
…ending with…
Wrote 688800 bytes (446067 compressed) at 0x00010000 in 9.7 seconds (effective 569.0 kbit/s)…
Hash of data verified.

I’m using the Arduino IDE 2.0.3 AppImage, trying to run “GetChipID”

#9

Same here, using the Lora V3 on Manjaro Linux. Stuck in boot loop after an attempted upload. Will try to use MacOS or Windows and see if it works.

#10

Managed to fix the boot loop!

I found this issue on github describing the same problem: https://github.com/Heltec-Aaron-Lee/WiFi_Kit_series/issues/159

I got the upload to work by replacing the contents in ~/.arduino15/packages/Heltec-esp32/tools/esptool_py/3.3.0/ with the directory contents from ~/.arduino15/packages/esp32/tools/esptool_py/4.2.1/

1 Like
Wireless stick lite V3 - Boot loop