rotwang
Posts: 243
Joined: Sat Dec 07, 2013 1:12 pm

Should this be happening

Thu Jun 26, 2014 2:01 pm

Problem - issue "sudo shutdown -h now", normal messages ending in "will now halt"
red power led remains lit (which is what I expect) BUT green activity led is lit dimly. It also doesn't do the rapid blinks thing that a model B would do.

I've pored over the schematics, but I still can't see any path which would light the led at less than full.

setup is using a motorola atrix lapdock, with cables I wired myself so I can confirm that the micro-usb power only carries 5v and Gnd, the A-type usb only carries D+ D- and Gnd, so there is no back-feeding possible.

When connected to RaspberryPi model B with same cable, at the end of the shutdown I get the usual rapid blinks, then the green led goes off and stays off.


Any suggestions where to look next? What's confusing me is the dim green led, I can't see anyway to do that except by pwm'ing GPIO47. By the way nothing is connected to any of the GPIO pins.

EDIT - possible further light
According to the Broadcom data sheet, GPIO47 has its pullup enabled high. As this goes to the gate of fet Q2, I'm still puzzled as to how the led is only partially lit, is this just a component tolerance thing (weak pullup 50k? and fet just turning on), and has anyone else noticed this phenomenon.

This doesn't matter too much at the moment (as long as it isn't a faulty board) but I would like to find some way of knowing that the board has finished it's shutdown sequence and that it's safe to remove power (running headless and unattended).

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Should this be happening

Fri Jun 27, 2014 1:51 pm

On the Model A and Model B the status LED is connected to GPIO16, so it's probably just that the firmware (which is what controls the LEDs when Linux isn't running) needs to be updated so that it knows that on the CM it should treat GPIO47 as the status LED instead :?:

Or maybe the RPF have simply decided to treat the status LED differently on the industrial-focused CM to the consumer-focused Model B?

User avatar
Gert van Loo
Posts: 2487
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: Should this be happening

Fri Jun 27, 2014 2:27 pm

I have not studied the computer module schematic but...
We have seen this on the Alpha boards. The LED lights up dimly because of power coming from the HDMI cable.
Try to disconnect that and see what happens.

rotwang
Posts: 243
Joined: Sat Dec 07, 2013 1:12 pm

Re: Should this be happening

Fri Jun 27, 2014 2:40 pm

Gert van Loo wrote:I have not studied the computer module schematic but...
We have seen this on the Alpha boards. The LED lights up dimly because of power coming from the HDMI cable.
Try to disconnect that and see what happens.
I'll have to try this with a different setup, if you disconnect the hdmi on the atrix dock it turns off the power to the usb connector which is powering the CM devkit. I'll try running the devkit off it's own power supply right now.

EDIT -

just tried this setup, devkit board on its own supply, usb and hdmi to lapdock. connect supply to devkit and it boots up normally, login and run "sudo shutdown -h now", normal shutdown messages, green led dimly lit. Unplug hdmi lead from lapdock - no change, green led still dimly lit. I've checked the schematics again and I still don't see any circuit path between the HDMI connector and the green led.

If this is indeed a difference in pin assignments between the RasPi A and B models and the Compute Module then might I venture to suggest that now would be a good time to split the image downloads and kernel sources into two separate paths so that fixing things on one doesn't affect the other. Also I can see the kernel sources diverging as the extra interfaces exposed on the Compute Module start acquiring kernel modules which will create havoc if you ran them on a model A or B.

Later edit - tried a different order with separate supply to devkit, so-
run "shutdown -h now" and wait for "will now halt" -- red led full bright, green led dim
unplug power first this time, green led off, red led very dim

That looks like it is indeed a backfeed from the hdmi connector somehow reaching the 3v3 rail via a high resistance. Does this match what you see on on your test boards? if so and its not harmful I'll stop worrying for the moment.
Last edited by rotwang on Fri Jun 27, 2014 5:53 pm, edited 1 time in total.

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Should this be happening

Fri Jun 27, 2014 4:19 pm

The foundation have already thought of that - I've been told the CM has a different revision to the existing Model A and B boards, so the firmware and kernel can automatically check what hardware they're running on :)

User avatar
gordon@drogon.net
Posts: 2023
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website Twitter

Re: Should this be happening

Fri Jun 27, 2014 10:06 pm

AndrewS wrote:The foundation have already thought of that - I've been told the CM has a different revision to the existing Model A and B boards, so the firmware and kernel can automatically check what hardware they're running on :)
The revision in mine is 0011 - that's what I'm using in wiringPi to identify a CM - I'm told it may change in the future though, so who knows.

I'm thinking the dim glow might be the GPU taking the pins to input mode with the internal pull-ups enabled. I've noticed this on the CM (maybe on the Pi too - never checked) - on my board with 46 LEDs, the first 8 light up dimly at power on (as does one other). Hang on - let me run halt on it (just sudo halt, don't bother with all the shutdown -h now stuff - far too much to type)

A-Ha - Yes - GPIO 16 flashes at halt time. I guess they'll patch that in which they've already done for the ACT LED.

with the dim LEDs at power on time - if I run:

for i in `seq 0 45`; do gpio mode $i off;done

then the dim glow vanishes, so I'm fairly sure it's the internal pull-ups. I'm sue there is a document somewhere with the default states but I can't find it right now.

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Should this be happening

Sun Jun 29, 2014 1:06 pm

gordon@drogon.net wrote:I'm fairly sure it's the internal pull-ups. I'm sue there is a document somewhere with the default states but I can't find it right now.
http://www.raspberrypi.org/documentatio ... bcm2835.md
(or see the cross-referenceable version at http://elinux.org/RPi_BCM2835_GPIOs#GPIO16 )

rotwang
Posts: 243
Joined: Sat Dec 07, 2013 1:12 pm

Re: Should this be happening

Fri Jul 11, 2014 1:06 pm

AndrewS wrote:
gordon@drogon.net wrote:I'm fairly sure it's the internal pull-ups. I'm sue there is a document somewhere with the default states but I can't find it right now.
http://www.raspberrypi.org/documentatio ... bcm2835.md
(or see the cross-referenceable version at http://elinux.org/RPi_BCM2835_GPIOs#GPIO16 )
Perhaps a note should be added to this table to the effect of "Don't try to use GPIO16 as in input in a design, it is driven as an output during boot", a behaviour which doesn't appear to be officially documented anywhere.

Return to “Compute Module”