Pandaboard ES Problems

I seem to be having a bit of an issue with my Panda ES. Not sure if it’s hardware or software related but I do actually suspect the former ALTHOUGH it only started recently.

The problem is as follows:
The boot time seems to have increased. Initally I thought I was imagining it, but then today, it took upwards of a minute before I got the module list on screen. Later on, when I watched it boot, I noticed that the LEDs kept repeating a cyclic pattern for quite a few attempts before eventually settling to boot and both LEDS going off.

It has frequently reset itself mid-activity, going into the Boot loop described above. It can take several attempts to get it going, sometimes requiring a full power-off and back on to get it going properly again. Even then, it can loop as above.

All of this is quite erratic and unpredictable. Sometimes it boots first time, others it takes a few cycles of the boot loop. I did notice the temperature fluctuating a bit, but it also crashes when it’s cooling down, not just when it’s getting warmer. The maximum I have noticed is just under 60C, which is well within range.

Any ideas, anyone? It’s running 5.21 (more specifically, R-Comp’s OS stable release 6).

I think I may have resolved this by dropping it down to 920MHz using CPUClock. Am keeping an eye on it and leaving it running for a bit to see what happens. Doesn’t explain the boot issues though…

Have you tried what you can see on a serial terminal?

I think I may have resolved this by dropping it down to 920MHz using CPUClock.

If you find you have to do this all the time, I have an alternative implementation of CPUClock, which I have never bothered to release. It is set up as a Boot-Configuration tool. It does not give the continuous monitoring of CPU speed, but does allow the fast (and slow if you were so inclined) speed to be set, and the setting is remembered over a reboot or poweroff.

Later on, when I watched it boot, I noticed that the LEDs kept repeating a cyclic pattern for quite a few attempts before eventually settling to boot and both LEDS going off.

if you mean the green LEDs on the board, I got that problem if my keyboard was plugged into either of the rear USB sockets – either direct or though an externally powered hub. Works fine plugged into a front socket. So far as I can tell the Pandaboard (ARMiniX) is quite fussy about what it connected to its rear sockets that are on the board.

Jim

Aren’t we all ;-)

if you mean the green LEDs on the board, I got that problem if my keyboard was plugged into either of the rear USB sockets

That might just be the issue. I recently moved around keyboard and mouse receivers between computers and no doubt rear ports, so I’m going to try different combinations to see if it stabilises it. Currently it’s been running for 24hrs at 920MHz, so I’ll pop it back up to 1.2GHz and see if it crashes.

If you find you have to do this all the time, I have an alternative implementation of CPUClock, which I have never bothered to release.

I think this may be very useful to me, so I’ll drop you an email about it. Thanks.

The rear ports on a PandaBoard (ARMiniX/PandaRO etc) are on the PandaBoards motherboard so connected to the on board USB hub.
The PandaBoard motherboard also has headers for two other USB ports. On a PandaRO we use one of those to drive the internal USB HUB and the other is connected to any internal drive (Optical, SSD or spinning). I expect an ARMiniX will probably be the same). ¹

As the reported effects are not always the same using a USB port connected to second level hub may not be a reliable solution. We haven’t seen the problem here.

? hub chips are four port so a seven port USB hub (like we use internally) has a second hub chip connected to one of the four ports of the main hub chip. Which means that four of the ports are secondary to the other three i.e. would be a third level connection in the complete system.

Check the latest ROM, there are fixes in for things like this :-D
I don’t have the problem all the time, but enough to be annoying.
But there again my RComp build is on an SD Card safely stashed away, I prefer to live on the edge
@Chris … Yeah the ArminiX is the same setup for me anyway, there aren’t a lot of options to connect a cd

The rear ports on a PandaBoard (ARMiniX/PandaRO etc) are on the PandaBoards motherboard so connected to the on board USB hub.

Mine is a plain PandaBoard ES mounted in a 5.25 bay inside a PC, so the keyboard/mouse dongle is connected via the onboard USB ports (through an extension cable to a PCI bracket). My other suspicion is that it’s a bit of a fault on the PC PSU supplying the 5v via a homemade molex to barrel adaptor cable. If it continues (it’s currently quite stable), I’m going to plumb in a regulated 5v adaptor and see if that resolves it. The adaptor is currently unavailable to me, but I can get to it next week.

Check the latest ROM, there are fixes in for things like this :-D

I’m using the PandaLand ROM image, which I updated recently to the latest stable version. If the hardware solutions don’t fix it, I might roll back a version.

I think this may be very useful to me, so I’ll drop you an email about it. Thanks.

Sent off a zip of the config-Tool version earlier. Hope it is OK.

FWIW I also used to get more ‘random crashes’ when I was using a 7-port externally powered hub. Also gave other problems. For externally powered hubs with my ARMiniX I now only use the ‘nulink’ ones that CPC sell as CS16383. I think this change has helped reduce the problems, but it may of course be some other change, or luck!

Jim

Random crashes are often a symptom of inadequate power supply arrangements. There are three specific things to check and to fix if they are wrong:

1) Use a power supply with plenty of current capability, preferably at least twice what the system consumes in the steady state. I wouldn’t like to power a system with less than a 2.5 amp adaptor.

2) Make sure that the power goes into the main board via a short and fat cable. Powering the hub, and then taking power from the hub to the main board via a long thin USB cable, is a common problem.

3) If you’re powering the main board via a USB socket, you may be seeing voltage drop across a fuse that is intended to protect the USB outlet.

I’d agree and widen the comments about power supplies. The real ‘killer’ moment for me wrt the 7-way hub was when I shut down my ARMiniX and even pulling its power plug didn’t cause the shutdown message to vanish from the screen! It was being powered back up the USB connection to the external 7-way hub. It was also putting a c 400 Hz tone onto USB audio recordings I was making.

So some hubs can give you problems with the power. And this may not simply be a question of voltage or current capacity. May be two PSUs ‘arguing’ or one of them putting garbage onto the lines.

Choose with care!

Jim

I have an even stranger one, sometimes when I power on my RISC PC it causes me to lose sound on my ARMiniX.
So I think I’ll get a better PSU for my ARMiniX

How recent is the version of OS you are using?

I don’t suppose it is related to the problems with audio discussed here?

https://www.riscosopen.org/forum/forums/5/topics/2482

Not sure which one of us you’re asking about OS version. I’m now using R-Comp’s 5.21(21-Apr14) which I presume comes from Willi. This has apparently fixed the stopping of conventional audio. But TBH for a long time now I’ve just been using USB Audio.

Some of the problems I’ve had in the past may well have been OS version related. But I doubt the entire machine remaining powered and the 400 Hz tone were. Too ‘hardware’ in nature and fixed by changing the USB hub I was using externally.

Jim

hub chips are four port so a seven port USB hub (like we use internally) has a second hub chip connected to one of the four ports of the main hub chip. Which means that four of the ports are secondary to the other three i.e. would be a third level connection in the complete system.

Does this mean that not all the outlets are the same as far as output current is concerned? If you cascade unpowered hubs, then the hub at the end of the chain will be limited to a total o/p current corresponding to the current supplied by one connector of the upstream hub. Does the same apply for a 7 port hub?

As far as 4, 7, 10 & 13 port hubs are concerned I’m confident that the power available to all ports will be the same, whether or not they are powered. Our internal 7port HUBS are powered.
Cascading unpowered hubs shouldn’t be done unless all the devices combined, draw less than 500mA

FWIW in the past I’ve developed various very low noise, etc, dc power supplies for uses where clean dc is vital. I’ve been meaning to look at making a ‘replacement’ psu for USB hubs that I know is clean and capable. But as yet I’ve simply been otherwise occupied. I may sometime soon experiment with adding filtering, though, as that’s simpler, albeit less effective.

Jim

Although it’s taken a while, I’ve resolved this problem! It wasn’t the timing of the CPU that was causing it, it was the fact that the Panda was sharing a molex 5v adaptor with a failing hard drive.

As I didn’t use the hard drive, I left it in place but removed the ribbon cable. Now I’ve replaced the hard drive with one that works properly, the problem hasn’t reoccurred for quite a few days now, so I’m going to stop holding my breath and assume it’s resolved!

Thanks for the advice and the software that helped me narrow it down.