Wio terminal sometimes won't boot

Wio terminal sometimes won’t boot.

When it stops booting, the status does not change even if you turn the power off and on again, put it in boot mode, or remove the SD card.
At that time, the backlight is off and the blue LED is lit. (If the program you wrote is working properly, the backlight is ON and the blue LED is OFF.)
The data in the SD card was not corrupted.

The only solution is to rewrite the program again, but the problem is that this method is often not available to people outside the company because the program is confidential.

I use about 25 wio terminals as loggers, and this problem has occurred on 10 of them so far.
It occurs when the power is turned on and off 20 to 300 times, and it seems to often occur when the power is turned on after a holiday.

The program is written using Arduino IDE, and the libraries used are as follows.

LovyanGFX.hpp
SPI.h
Seeed_FS.h
SD/Seeed_SD.h

Is this because the program data is corrupted or the program is failing to load?
Please let me know if there is a solution.

Hello,
The issue may be caused by accidentally pressing the key down too far during boot up, which triggered a reset of the device.

When powering on, please turn the key to the middle position and do not press it down further. Trying booting it up this way and see if the problem persists.

Thank you for reply.

However, the problem also occurs when the power switch is left in the center and the connection is made as shown in the image and the power to the connected device is turned on and off.
Is this startup method also bad?

Today, when I connected the power to the USB connector and started it up, a problem occurred.
(I use the power switch in the center position.)
When I checked the internal “.UF2” file in boot mode, I found that some data was different from the normal one.

Does this mean that the program is corrupted and cannot be started?

I haven’t received a reply from anyone, but I’m happy to report that the issue has been resolved.

I don’t know the cause, but I found that the problem occurred with programs that used “LovyanGFX”, but did not occur with programs that did not use “LovyanGFX”.

All the problems were the same: the same address range in the program was corrupted.

If a problem occurs in the future with a program that does not use “LovyanGFX”, I will come back to add it.

I have the same issue randomly also, and I don’t use that library you mentioned.
It seems related to accidentally hitting reset on a shutdown, but that shouldn’t cause this issue. It does seem that the image gets corrupted, becuse I have to reload via USB as you pointed out.

Unfortunately, a problem also occurred with programs that do not use “LovyanGFX”.
This time, not only the range from 00008022 to 0000802D but also the range from 00008030 to 00039479 was changed.
This time, it happened when I was using a stabilized power supply to the connector on the back.

There seems to be a problem with wio terminal after all.
I think it is a serious problem that the program is rewritten without permission and becomes unbootable, so I would like the manufacturer to investigate.
We can provide information for reproducing experiments.

I’m sorry I’m late. You mean that when you use the Wio Terminal Chassis - Battery to power the wio terminal, your built-in program does not start correctly via the left switch right?

Can you try to test it again with an example that makes the wio terminal screen light up? Whether the screen lights up or not is a better indication that your code is working correctly. Please make sure you have enough battery power to power your wio terminal

it’s a little different.
The problem is that if you turn the power off and on about 50 times, the built-in program will break and stop working.
The bootloader area is not damaged, so you can rewrite the program, but it will not do anything until it is rewritten.

It probably doesn’t matter how the power is supplied.
This happens with all supply methods.

I tried the code below, but so far there are no problems.
The test is a method of repeating the cycle of supplying power to the USB connector for 15 minutes and stopping it for 15 minutes.
I’ve started it 150 times on 3 machines and no problems have occurred yet.

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#include"TFT_eSPI.h"
TFT_eSPI tft;
#define LCD_BACKLIGHT (72Ul) // Control Pin of LCD

void setup() {
tft.begin();
tft.setRotation(3);
}

void loop() {
delay(5000);
tft.fillScreen(TFT_BLACK);
digitalWrite(LCD_BACKLIGHT, LOW);

delay(5000);
tft.fillScreen(TFT_RED);
digitalWrite(LCD_BACKLIGHT, HIGH);

}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

However, when we tested it with another product, we encountered a problem where the program broke after 50 to 240 startups.
This has happened to 3 units in the past week.
The problem occurred even when power was supplied from the USB connector and from the connector on the back.
This product operates with an interval timer and sends sensor information obtained by ADC and I2C via serial communication. (LovyanGFX is not used.)

What are the possible reasons why the program may or may not break depending on the contents of the program?

I apologize for the delay. We are currently arranging the testing, and if there are any results, we will leave a comment on this post as soon as possible. Thank you very much for your feedback.

Thank you for your investigation.
If you need the source and uf2 file of a program that is likely to cause symptoms, please send an email to the email address on your account so we can provide it to you.

Report of test results since last post.
We tested 4 units with software that only fills the screen and 3 units that serially send sensor information, but none of them showed any symptoms this week. (It has been activated approximately 250 times this week.)

Okay, thank you very much for your support!

Hi @oeh .
I’ve sent you an email, please check it if you are free :heart:

Hello @oeh ,

I really apologize for the delay in responding.

We have updated the Bootloader for this situation. We have tested the updated Bootloader on four Wio Terminals, performing approximately 3,000 power cycles over 4 hours, and all were able to boot up normally.

Please find the link to the new Bootloader and flash tutorial below:

https://files.seeedstudio.com/wiki/Wio-Terminal/res/update-bootloader-wio_terminal-v3.15.0-4-gaa4429b.uf2

1 Like

Thank you for your response.
I’m glad it seems like it’s resolved.
I will try updating the bootloader.

Best regards.

1 Like

I am just writing about most of the problems and those solutions. Give it a try hope so, it’s works

Possible Reasons:

  • Code Bug: There might be a bug in your code that causes the boot process to hang. This could be due to an infinite loop, incorrect library usage, or memory allocation issues.
  • Power Fluctuations: Frequent power on/offs, especially after a period of inactivity, can cause unexpected behavior. Voltage drops or surges during power on could be affecting the boot process.
  • Hardware Issue: While less likely, there could be a hardware issue with some of the Wio Terminals.

Solutions:

  1. Review Your Code: Carefully examine your code for potential bugs that might be causing the boot to hang. Pay attention to loops, library calls, and memory usage.
  2. Test Power Supply: Try using a stable power supply and avoid frequent on/offs. If possible, implement a soft power on sequence in your code to minimize boot stress.
  3. Update Firmware: Check if there are any firmware updates available for the Wio Terminal. Updating the firmware might address known boot-related issues. You can find firmware updates on the Seeed Studio website.
  4. Reflash Program: While not ideal for confidential programs, reflashing the program can sometimes resolve boot issues. See if there’s a way to obfuscate your code before flashing it to deter easy access.
  5. Contact Seeed Studio: If none of the above solutions work, consider contacting Seeed Studio support. They might be able to offer further assistance or troubleshoot potential hardware issues on some of your Wio Terminals.