Troubleshooting

Troubleshooting

In this documentation, you will find some of the problems that you may encounter.

πŸ‘

Help us expand this section! Go to the community page and report any issue you may encounter. We will help you!

Programs

WSL

When you are installing WSL, you may face some errors. A common one is:

  • Error: 0x80370102 The virtual machine could not be started because a required feature is not installed.

This error usually occurs in the following cases:

  • Windows Subsystems for Linux, Virtual Machine Platform, Hyper-V, and Windows Hypervisor Platform are not enabled.
    • You can enable them by going to Turn Windows features on and off and checking them. It is possible that sometimes it doesn't enable them even after selecting them. To fix that, open the Windows Terminal and run the following: bcdedit /set hypervisorlaunchtype auto start.
  • Virtualization is not enabled in the BIOS. Fix that by going to the BIOS and enabling SVM (for AMD CPU) or Intel Virtualization Technology (for Intel CPU).

For more information regarding this error, check here.

You can also access WSL's official troubleshooting documentation.

Vitro Crystal

Ethernet Connection

  • If you are having trouble connecting to the internet via an Ethernet cable, usually the problem is with the cable. Test it with another device. Another recommendation is to try with a smaller one. It is possible you have a bad cable or there is electromagnetic interference. You can also try to use a Cat6 or Cat6e cable if this is the case.

  • If the cable is working properly, it can be the DNS service. However, usually, the DNS is handled by the DHCP server. Check if it is working properly by running the command:

systemctl status systemd-resolved
  • Check if the DHCP client is working properly:
systemctl status systemd-networkd
  • Sometimes an internet connection problem may arise thanks to a wrong system time. You can fix it by reading this section.

Time

  • If you encounter some different strange behavior, it is possible that the perpetrator is the wrong system or hardware time. First thing is to check if the system time is correct by typing:
date

Now, check the RTC time:

hwclock -r

Now you have the following cases:

  • The hwclock is wrong, but the 'date' is not: You need to synchronize the RTC with the system time:
hwclock --systohc

πŸ“˜

'systohc' means system to hardware clock.

  • The system time is wrong, but hwclock is not: You need to synchronize the system clock with the RTC:
hwclock --hctosys

πŸ“˜

hctosys means hardware clock to system.

  • Both are correct: you need to check dmesg for more details on the problem.

  • Both are wrong: You probably have an internet connection problem and a low RTC battery. The RTC should be able to keep the correct time. If it is unable, maybe its battery is low. The system time should also synchronize with the server via the internet. As there is no internet, there is no synchronization. If this is the case, here are some solutions:

    • Change the ethernet cable. Usually, it is the main culprit.
    • Measure the RTC battery on the bottom of the board (or top, the negative terminal is next to J19 and the positive above U37). If it has low voltage, you need to change it. The battery model is CR1620 (3V) and it is soldered on the board. If you don't know how to remove it and install a new one, you can follow the steps in this video.
    • Set the date and time manually. Sometimes there are issues with the communication protocols when the date and time are wrong. To do that, you can type:
date -s "<day> <month> <year> <hour>:<minutes>:<seconds>"

πŸ‘

For example, date -s "12 10 2021 18:55:10"

Now you need to synchronize the 'hwclock':

hwclock --systohc

Low RTC Battery

Measure the RTC battery on the bottom of the board (or top, the negative terminal is next to J19 and the positive above U37). If it has low voltage, you need to change it. The battery model is CR1620 (3V) and it is soldered on the board. If you don't know how to remove it and install a new one, you can follow the steps in this video.

Vitro Shard

ST-LINK

  • If you encounter problems with chip detection, make sure that Vitro Shard Vitro and Shard Edge are powered on. You can measure the input voltage on the board with a multimeter (it should be around 12 V). If this is not the case, test the conductivity of your SWD header pin (i.e., if you soldered it correctly). Finally, make sure that you are connecting the header and the ST-LINK programmer as shown by the schematics and there is conductivity between both ends.

  • After a flash failure, the Nucleo board must be powered off and on again. Simply unplug and plug Nucleo board from PC and try flash Vitro Shard again.

The API

Building

If you are having trouble compiling the application, usually you can fix it by doing one of the following:

  • The application should be compiled with Mbed OS taken from the commit #5e23fbaa8398f1a455ba882bb154655b04d183a7.
  • When including files in your application, mbed.h has to be included before shard-sdk.h.
  • User application should contain an object of type Serial named pc. This is required for logging throughout the application, API, and SDK. As an example, the declaration should look something like this:
#define SERIAL_BAUDRATE 115200
Serial pc(UART_DEBUG_TX, UART_DEBUG_RX, SERIAL_BAUDRATE);
  • You may have an unsupported GCC by either Mbed OS or the API. The recommended GCC version for that commit of Mbed OS is the GNU Arm Embedded version 9 (9-2019-q4-major). Release version 10.3-2021.07 was also tested and worked.
    • The Ubuntu repository has an out-of-date version, but it seems to work after installing the libnewlib-arm-none-eabi package.

Vitro Shard Edge

  • If you are having trouble, please let us know by asking on our community page!