Jump to content

Orange Pi One - Hardware debugging


klaute

Recommended Posts

Hello everyone,

 

this is my first post so please be patient.

 

I am using armbian for a long time on my cubietruck, but this time I got a problem with my Orange Pi One.

 

I have build a Embedded Cluster [1] out of a cubietruck, 5 Orange Pi PC and one Orange Pi One system.

 

Since yesterday I have modified my cluster chassis. Maybe but just maybe ;) a short circuit happened on my OPiOne because of some assembly issues I had during it's installation.

The problem is that it OPiOne does not boot any more. The red and green LED are still turned off. The two LED'S of the ethernet port are always switched on.

 

Nothing to see on a screen attached to the HDMI port. It also looks like that no data are transmitted on the serial port but I have to verify that again.

 

I also tried to use a different power sources, but my cluster's main power source is able to deliver 5V and 12 ampere and the other 6 systems are work well.

 

To test if it is a SDCard problem I have tried to boot from 5 different cards - multiple producer and types which are ok for other systems and also worked in the OPiOne before.

I also have used different SDCard images, a plain Armbian OPiOne jessie server image and my own modified backup. But I have no success.

Maybe today in the evening I have the time to test a lubuntu xulong original image but I think it is a hardware problem.

 

I have found a schematic file [2], I will have a look at it.
Does anyone knows a something further about the electronics?

 

Maybe I can measure the board voltages or frequencies (using my oszillator) on the board to verify that

there an other problem. With my measurement devices I have already metered some voltages and in my eyes they are ok but until I have no reference it is hard so say it is correct or not.

 

I already ordered two new boards yesterday, but they will arrive hopefully in about 7 weeks. :(

 

Maybe we could share some information about to debug the OPi electronics...

 

Looking forward to get in touch!

 

[1] : https://klautesblog.blogspot.de/search/label/ChinaCluster

[2]: http://linux-sunxi.org/images/7/7e/ORANGE_PI-ONE-V1_1.pdf

Edited by klaute
Link to comment
Share on other sites

 

It also looks like that no data are transmitted on the serial port but I have to verify that again

That is the key for debugging success.

You should check what's appearing on this serial in the early boot, you will probably figure out the real reason.

Maybe a bad SDCard, otherwise something else ...

Link to comment
Share on other sites

Maybe I can measure the board voltages or frequencies (using my oszillator) on the board to verify that

there an other problem. With my measurement devices I have already metered some voltages and in my eyes they are ok but until I have no reference it is hard so say it is correct or not.

First, verify voltage on available test points (1V2S, 1V2C, 1_5V, AVCC)

Second, try powering the board without SD card inserted and connecting OTG port to another board or PC - new USB device should be detected on the other side if CPU is still alive.

Link to comment
Share on other sites

Thank you for the information!

 

It was an really interesting expiration to see what happened on my board - or more likely not happen.

 

A few days ago I tried to receive some information from the UART debug port of my broken OrangePi One, but nothing happened there.

There was no communication to measure between my Laptop and the board (used 115200 Baud). My hterm screen keeps blank.

The measured voltage level also looked nice...

 

Then I left the device (frustrated) for about 2 to 3 hours. At this point I forgot to disconnect the power supply, but the serial port was disconnected.

 

After I came back the board the LED's on the board are flashing fast. Anf after I attached a HDMI screen to the board I see that the system has been booted the linux just as normal.

The LED's stopped flashing after I connect a LAN cable, so this behaviour seems to be correct.

 

Since that the board runs quiet well but I still don't know why.

 

Thank you again!

Link to comment
Share on other sites

I have build a Embedded Cluster [1] out of a cubietruck, 5 Orange Pi PC and one Orange Pi One system.

 

 

Just out of curiousity: Why do you operate the cluster nodes mounted horizontally without heatsinks?

Link to comment
Share on other sites

Just out of curiousity: Why do you operate the cluster nodes mounted horizontally without heatsinks?

This is a very good question! As we did not planned how to build the case, it was just the simplest way to attach them together.

The heatsings are on my TODO list...

 

BTW 70 degree celsius is not exceeded. even in case of a permanent system load of 8 for about 30 minutes.

Link to comment
Share on other sites

70 degree celsius is not exceeded. even in case of a permanent system load of 8 for about 30 minutes.

 

Then without heatsinks this is a clear sign that your cluster is pretty much inactive ;)

 

'Average load' on Linux include tasks in the uninterruptable state (usually I/O), so by looking at this parameter especially on SBCs (especially with slow SD cards, random IO is important here and there most cards horribly suck) you're most probably just fooling yourself since high average load is mostly related to processes being stuck in IO. Two other important pieces of information are also:

  • cpufreq governor (if you use the wrong one and IO intensive stuff happens, cpufreq won't be increased)
  • CPU clockspeeds -- we allow an Orange Pi PC to choose cpufreq between 480 and 1296 MHz, so a higher load while remaining at lower clockspeeds is irrelevant

If you run a most recent Armbian release then you could install RPi Monitor by simply doing an 'sudo armbianmonitor -r'. On H3 boards another daemon will be installed (rpimonitor-helper.sh) that provides more accurate info by querying /proc/stat instead of the useless /proc/loadavg every few seconds and calculating percentage of different activity:

Bildschirmfoto%202016-07-18%20um%2021.17

 

Load value only increased due to IO activity. And this is on rather fast eMMC!

 

And RPi-Monitor also draws nice graphs so you get the idea what was going on also later:

 

 

Bildschirmfoto%202016-07-18%20um%2021.25

 

 

Bildschirmfoto%202016-07-18%20um%2021.28

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines