Electrical Schematics - short between CORE2 PCB layers?

I received my CORE2-ROS a few days ago, and setup was fairly painless. Linked to my cloud account and had demo code uploaded in only a few minutes. All in all, it made a good first impression. But a day later, I couldn’t get it connect to the internet, or even reset. PWR LED is steady red and L2 has a slow (0.5-0.25Hz) green blink. Holding hcfg and reset could get something like a reset to happen, but still no network connection and the ‘green blink’ always returned.

It had been plugged in overnight, but powered off. After closer inspection of the board, I noticed some discoloration around components near the power hookup. Looks like burned Flux (maybe?), see upload. I also noticed that the standoff closest to the power hookup was hot (but not hot enough to burn). I check my PSU with a Fluke and a DIY dummy load, and it checked out at 15V, 0.5A - which seems to be compatible per available documentation. The tinker board it came with operates just fine after being removed from the setup, so I don’t think the short is in there.

I’ve found a couple suspect pins on ICs near the power circuit - don’t seem to connect to anything (even other pins on the same IC), or have less than 1 ohm resistance to ground - but it’s hard to know without access to an electrical schematic. Will Husarion be making any electrical schematics available for the CORE2?

Hi brownem,

thank you for the great description! I think I know what has happened.
It looks like your PSU gives more voltage when the load is low, or in other words, the output voltage is not stabilized very well. If the voltage is higher than 16V and the current is even as low as 0.1A, then the overvoltage protecting transil (D2 on the schematic below) starts conducting and dissipating power. The intention of the circuit was to protect the rest of the board from high voltage but you have to make sure that the supply voltage is stabilized and does not exceed 16V.

What can you do now?

  1. Please measure the output voltage of your power supply with NO load. This measurement confirms whether your power supply can be used with CORE2 or not.
  2. Probably the transil is damaged due to long-term overvoltage and needs replacing.

This is the location of the transil:

1 Like

Hey Radeknh,

Thanks for the quick response, and the relevant schematic.

Just tried the PSU on a 0.5Ω load (I hesitate to measure current with no load in series, for the sake of my meter) and you were spot on. The PSU voltage jumped to 25V. I had previously measured the current with the dummy load configured for 400KΩ, which seems to be the total system equivalent resistance, measuring at power jack.

I have a second PSU that clocks in at 12V with the same 0.5Ω load, but it still doesn’t want to work. Something definitely seems to be dead. Solid red PWR, green blink on L2, and refuses to reset. However, I am largely guessing at the reset procedure since an official one doesn’t seem to be posted in the online documentation just yet; holding hCFG while powering up, holding reset while power up and power down, holding reset and hCFG during power up and down have all be attempted.

Looking at D2, I think it might actually be fine? Looking at the pad closest to the board edge, I read 0.5Ω to any ground pin on the board headers, so I am assuming (and referring to as such for the rest of this reply) that this is the ground pin. Looking at resistance across D2, immediately after removing power, it starts out around 18MΩ and dissipates down to a steady state of 37.15KΩ over the course of a minute or so. Seems to follow a pretty linear path during the middle, with a bit of a logarithmic decrease for the first few MΩ and an instant jump from 67KΩ to 37KΩ at the very end. Looking at its diode functions, D2 reads as open with the common lead on the grounded side of D2 and the sensing lead on the same node as R33, and D2 gets a reading of 1.003V with the common lead on the same node as R33 and the sensing lead on the grounded side.

Is it possible that a different component is what failed? It did seem to run just fine for a few hours of use on the bad PSU before I started running into any signs of trouble.

So, as an update, I was briefly able to get the board to reset and re-pair it to my Husarion cloud account - however, it still would not register as being online. I could not get it to talk to Visual Studio Code. It ended up taking a lot of fiddling with switches. The sequence that ended up working this time was:

  1. Hold Reset until steady blue light (LR2)
  2. Hold hCFG until flashing blue light
  3. Power off CORE2 while holding both Reset and hCFG
  4. Power on CORE2 while continuing to hold both Reset and hCFG
  5. Upon steady blue light (LR2), release Reset and continue to hold hCFG
  6. Hold hCFG 30 seconds until yellow light (LR1) and blue light (LR2) begin to alternate flashing
  7. Continue through pairing sequence like normal using the phone app

Unfortunately, I was not able to replicate this result by repeating this sequence. This started getting me curious about the switches and button on the CORE2 - particularly the hCFG button.

Measuring resistance across Reset, hBtn1, and hBtn2, I find:

  • 10.5KΩ when the switch is in the initial open position.
  • Less than 1Ω when the switch is closed
  • 10.5KΩ when the switch is released and allowed to return to the open position.

However, I find something different when measuring hCFG:

  • Steady 10.5KΩ regardless of the switch being open or closed.

I wonder if my hCFG switch is intermittent (in the wrong way), that is what is actually leading to my headaches. That would explain why it took 30 seconds for the light sequence to start flashing, and sometimes the green flash (L2) doesn’t happen at all when holding hCFG.

Hi Michael,

there is only one simple procedure for connecting CORE2 to the Husarion cloud and your Wi-Fi network:

  1. power off CORE2
  2. hold hCFG button, power on CORE2 and wait until LR1 and LR2 start blinking in sequence: 10----delay—>01----delay—>10----delay—>01—…
  3. connect your smartphone to the HusarionConfigXXXX network
  4. open hConfig smartphone app and follow two steps to connect CORE2 to a local Wi-Fi network and your cloud account

If it doesn’t work this way, the most probable issue is hCFG button - exactly as you noticed:

What you can do is:

  1. try to measue resistance across hCFG once more and try to press button in different ways - “more from up”, “more from down”, etc. - we will find out whether hCFG button is completely damaged, or you need to press this in the different way
  2. on the other side of the board, under hCFG button there are solder pads for external hCFG button - used for example when your CORE2 is closed inside the robot’s housing, so you can solder your own hCFG button that can be easy to be pressed by the robot user. If hCFG button is dead, please try to solder your own push button to these pads.

Please let me know about results. We’ll fix any issues with your CORE2!

Yeah, that method worked the very first time I set it up. Took less than a minute, I was really impressed with how easy it was to get everything paired and running. But that was the only time I got that specific method with no ‘additional steps’ to work. I listed my full method that did work once just to be complete in my troubleshooting steps. “Data, data, data! I cannot make bricks without clay”, and what not.

I spent a couple days playing with it, and the resistance reading it pretty solidly consistent. 10.5KΩ no matter how I measure across the switch (pads on the bottom of the board, from the top to the bottom of the board, across the switch on top of the board), or how I pressed and/or held the switch - it is solidly open.

That said, I have soldered small ON-NONE-OFF rocker switch onto the hCFG pads, verified 10.5KΩ to 0Ω (actually 0.01Ω) both between the pads, and through the switch itself (measure from top to bottom of PCB). Leaving it in the closed position and powering on has not solved the issue. Even playing with the reset switch through various power on-off scenarios has not produced the blue-yellow alternating pattern on LR1 and LR2.

The only thing that has changed is the green flash has reduced its cycle time from 0.5-0.25Hz to 0.0833Hz. I do not know if this is related to the new switch or not, or if the failure is just slowly cascading through the board and changing other behaviors.

I think something else is pretty sick on my Core2.

EDIT
It occured to me to check the voltage across the hCFG switch: 0.2mV, intermittent.

This strikes me as both low and wrong, respectively… unless it isn’t so much a steady-state ‘clear’ signal that triggers the configuration process, but a digital word of some kind? I don’t have an oscilloscope as part of my bench-top hardware, so I can’t check for any digital words.

1 Like

Hi Michael, hCFG button is connected to the Tinker Board part of your CORE2-ROS. Please check the voltage on this pin:

If hCfg is pressed, the voltage between this pin and GND is about 0V.
If hCfg is released, the voltage between this pin and GND is about 3.3V.

If hCfg works as I described (and we still have a problem with entering configuration mode) means that, there could be a problem with corrupted Linux image on your ASUS Tinker Board. Please install the latest Linux image from this site at your Tinker Board’s SD card: Downloads | Husarion .

Description how to do this is here: Raspberry Pi Documentation - Getting started (of course use image for CORE2-ROS, not standard RPi image)

Just checked, using the ground pin on the D motor header:
hCFG closed: 0.00V (as expected)
hCFG open: 2.81V (0.5V missing)

I can also confirm that the Linux image is fine. That was actually one of my first suspicions. I pulled the Asus Tinker off of the CORE2-ROS, and put it on my SBC station (just a simple KVM setup, plus some PSUs. I also play with a RasPi and a Tegra TK1). Powered up and booted into the Husarion image just fine. I even re-flashed it to the image located at the link you provided - following the instructions there, and using Etcher - just to be on the safe side. No change in performance with it. I checked both ethernet and WiFi network connectivity by doing some light web browsing and some file transfers across my local network without issue as well, with everything performing as expected for an entire afternoon of usage.

OK, so let’s check now whether CORE2 part of CORE2-ROS works. Please try to flash your CORE2 using offline IDE (Visual Studio Code + Husarion extension): https://husarion.com/core2/tutorials/howtostart/offline-development-tools/ .

You can even disconnect Tinker Board in this configuration from CORE2-ROS (but it can stay connected). We will just check whether everything is fine with STM32 microcontroller inside your CORE2.

Ok, it seems to have programmed correctly, though I did have some initially trouble programming through Zadig (got to see the sense of humor of whomever programmed it - as you approach the 5min timeout, the porgram message starts asking how your day was :laughing: ), but it was my fault for doing it wrong the first time.

Programming CORE2ROS

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

E:\Code\Husarion Projects\Husarion_VSC>set PATH=%PATH%;C:\Users\...\.vscode\HusarionTools\b
in\

E:\Code\Husarion Projects\Husarion_VSC>"C:\Users\...\.vscode\HusarionTools\bin\ninja" flash

[1/2] cmd.exe /C "cd /D "E:\Code\Husarion Proj...5.5\sdk\tools\win\core2-flasher myproject.hex"
Connecting to the Husarion device... OK
Checking settings...  OK
Connecting to bootloader... OK
Checking configuration... OK
Erasing device... 4 5 OK
Programming device... OK
Reseting device... OK
==== Summary ====
Time: 29156 ms
Speed: 4.59 KBps (37585 bps)

E:\Code\Husarion Projects\Husarion_VSC>

Running the Configuration Wizard:

Everything ran just fine, and seems to be online. Finally. At least at first (see below).

fun fact: leaving the hCFG switch closed during the setup procedure after getting LR1 and LR2 to begin flashing doesn’t seem to have a negative impact on the setup process. I forgot to turn my DIY rocker switch off until just before I powered the board off.

I reloaded my original project, which was just some of the demo code provided by Husarion for the CORE2ROS, specifically the LED blink code. I am not sure if it was something in here that caused my issues.

#include <cstddef>
#include <cstdint>
#include "hFramework.h"
#include "hCloudClient.h"

void printfOnConsoleInWebIDE()
{
	for (;;) {
		platform.printf("asd %d\r\n", sys.getRefTime());
		sys.delay(1000);
	}
}

void cfgHandler()
{
	//uncomment if you want to stream video from your project using smartphone
	//platform.ui.video.enableTransmission();
	platform.ui.loadHtml({Resource::WEBIDE, "/ui.html"});
	auto l1 = platform.ui.label("l1");
	auto lb_bat = platform.ui.label("lb_bat");
	auto l2 = platform.ui.label("l2");
	auto b = platform.ui.button("btn1");
}

void onKeyEvent(KeyEventType type, KeyCode code)
{
	//press "up key" on your keyboard in your device UI
	if (code == KeyCode::Up) {
		if (type == KeyEventType::Pressed) {
			LED3.on();
		} else {
			LED3.off();
		}
	}
}

void onButtonEvent(hId id, ButtonEventType type)
{
	static int cnt = 0;
	if (id == "btn1") {
		UiButton b = platform.ui.button("btn1");
		if (type == ButtonEventType::Pressed) {
			b.setText("pressed %u", cnt++);
		} else {
			b.setText("released %u", cnt++);
		}
		LED1.toggle();
	}
}
void hMain()
{
	platform.begin(&RPi);
	platform.ui.configHandler = cfgHandler;
	platform.ui.onKeyEvent = onKeyEvent;
	platform.ui.onButtonEvent = onButtonEvent;
	platform.ui.setProjectId("@@@PROJECT_ID@@@");

	sys.setSysLogDev(&devNull); //turn off sys logs
	sys.setLogDev(&Serial);     //default console setup - USB Serial
	Serial.init(115200);        //default baudrate for USB Serial is 460800

	sys.taskCreate(printfOnConsoleInWebIDE);
	for (;;) {
		sys.delay(500);
		printf("\r\nuptime %u", (unsigned int)sys.getRefTime()); //print on default console - USB Serial
		platform.ui.label("l1").setText("uptime %u", (unsigned int)sys.getRefTime());
		platform.ui.label("lb_bat").setText("%f [V]", sys.getSupplyVoltage());
		LED2.toggle();
	}
}

another fun fact: when you click on the “pressed” button, but drag your mouse off before ‘unclicking’, L2 - the LED associated with the software button “pressed” stays lit. Just something I found interesting.

Trouble Returns

Turning off the CORE2ROS shows it as ‘offline’ in the web IDE after refreshing the webpage. However turning on the CORE2ROS back on brings me back to the dreaded L2 blink.

Maybe it is something with the LED Blink example code that leads to this behavior? Maybe it doesn’t like being shutdown suddenly? But I’m not sure how else to shut it down other than just the power switch?

Hi brownem.

We know about this problem. Now we are working on it to fix this issue. Until this time, temporary solution is to hold reset button on CORE2 until ASUS Tinker Board will boot themselves (LR2 led will turn on).

Regard
Hubert.

Thanks and good luck on the bug hunt, let me know if you want me to test anything out on my end.

I was starting to suspect it had to do with the link between the Tinker board - discussed in the other thread. Occured to me that both seemed to be functional, but if it was trying to connect to the internet while booting, it would have to do so through the Tinker board. Any failure at this point would likely result in a loop stopping the boot cycle from completing.

Maybe move the network initialization to the very end of the boot cycle, or disconnect it from the cycle all together (if that is even possible)?

I can also confirm that the reset trick you mentioned in the other thread work for me, but only during a power cycle (power on → hold reset → power off holding reset → power on holding reset → hold reset until LR2 lights solid blue)

Update

I haven’t been able to consistently replicate this, nor get a a consistent timing down, but I have run into a few cases of my CORE2ROS disconnecting from Husarion Cloud and the internet in general. Not necessarily inclusive of one another. I’ve lost connection to just the cloud, but remained on my local network. Haven’t had a chance to ping out to some place like Google during one of these events to see if I still had access to the internet in general.

Just thought I would add this data to the pile, in case it helps with the troubleshooting. I will be the first to admit that it could be unrelated to the CORE2 or Husarion, and could just be something on either my local network, ISP, or something else all together.

Hi brownem.

I can also confirm that the reset trick you mentioned in the other thread work for me, but only during a power cycle (power on → hold reset → power off holding reset → power on holding reset → hold reset until LR2 lights solid blue)

Yes, it’s necessary to do this during a power cycle, becouse CORE2 start faster then Tinker Board and when run command:

platform.begin(&RPi);

CORE2 sends via serial some information to Tinker Board and that’s why Asus blocks during start-up. It’s very easy to fix this issue without this procedure. You have to add few line in your code flash on CORE2. Create a function like below:

void platformStart()
{   
    sys.delay(5000);
    platform.begin(&RPi);
}

Delete this line:

platform.begin(&RPi);

And add one line in the begining of main function:

sys.taskCreate(platformStart);

This will ensure that the Tinker BOARD will start without any problem.

Regard,
Hubert.

So my main.cpp files now looks like:

#include "hFramework.h"
//#include "hCloudClient.h"
#include <stdio.h>

using namespace hFramework;

void hMain()
{
	sys.taskCreate(platformStart);
	sys.setLogDev(&Serial);
	//platform.begin(&RPi);
	for (;;)
	{
		hLED1.toggle();
		printf("test 111 %d\r\n", (int) sys.getRefTime());
		sys.delay(500);
	}
}

void platformStart()
{   
    sys.delay(5000);
    platform.begin(&RPi);
}

However, VSC does not like the way platformStart is declared, so it does not build at all - never mind upload. Perhaps I misunderstood your directions?

Hi brownem.

The problem arises from the way the compiler works. Function

void platformStart()
{   
    sys.delay(5000);
    platform.begin(&RPi);
}

have to be declared before you will use it.

Second thing. Platform is the object of hCloudClient.h so line:

#include "hCloudClient.h"

is nessesary. One more thing. It will be better if you use just

platformStart();

instead of

sys.taskCreate(platformStart);

Sorry for my previous mistake. Final code should look like this:

#include "hFramework.h"
#include "hCloudClient.h"
#include <stdio.h>

using namespace hFramework;

void platformStart()
{   
    sys.delay(5000);
    platform.begin(&RPi);
}

void hMain()
{
	platformStart();
	sys.setLogDev(&Serial);
	for (;;)
	{
		hLED1.toggle();
		printf("test 111 %d\r\n", (int) sys.getRefTime());
		sys.delay(500);
	}
}

Regard,
Hubert.

1 Like

Bingo. That did the trick. Actually had a little trouble at first because the SD card wasn’t fully inserted into the Tinkerboard (my mistake, I had just neatened up my desk and almost certainly ejected it while doing this), so that is another way someone might run into this same issue.

Remember kids, you need the boot drive installed in order to actually boot the computer:sweat_smile:

Since I’ve seen at least two other threads with similar issues so far, I’ve created a Github Repo just to put everything in a neat package for anyone else who may run into this problem before the Husarion team gets the official fix put out through their own channels. Should be super simple this way for someone to get this into VSC and onto their Core2. I don’t claim any ownership or responsibility for the code in this Git, I’m still learning my way around the Core2 and my C++ is rusty. All credit goes to @Hubert_Zwiercan and the rest of the Husarion team.

As a side note:

I did get a few warnings. They all seem to center around IntelliSense and the way it interacts with the hCloudClient.h library. Initially, I tried commenting it back out since it was commented out in the original code - but that threw a couple of actual errors instead of just warnings, even though it looks like it can’t even properly use the hCloudClient library. It probably has more to do with my setup than anything else, but figured I would pass it along.

file: 'file:///e%3A/Code/Husarion%20Projects/Husarion_VSC/main.cpp'
severity: 'Info'
message: '#include errors detected. Please update your includePath. IntelliSense features for this translation unit (E:\Code\Husarion Projects\Husarion_VSC\main.cpp) will be provided by the Tag Parser.'
at: '1,1'
source: ''
file: 'file:///e%3A/Code/Husarion%20Projects/Husarion_VSC/main.cpp'
severity: 'Info'
message: 'cannot open source file "stddef.h" (dependency of "hFramework.h")'
at: '1,1'
source: ''
file: 'file:///e%3A/Code/Husarion%20Projects/Husarion_VSC/main.cpp'
severity: 'Info'
message: 'cannot open source file "hCloudClient.h"'
at: '2,1'
source: ''

Edit

One thing I have also noticed is that maintaining connection to the internet and Husarion Cloud seems to still be a struggle for the Core2-ROS. Left it on for a few hours, and came back to it registering as offline on Husarion Cloud, and a pattern of yellow and blue blinking lights on LR1 and LR2 reminiscent of when doing the initial pairing with a cloud account. Not quite sure what to make of this now, but it is much less of an issue now that basic on-off cycle of the board brings it back online.