Mausberry Circuits - MIA???

[B.M.O.C.]

Hi there,

I recently finished the following project: http://retroprojects.blogspot.com.au

However I am having trouble with the shutdown circuit I ordered from Mausberry Circuits. at first it worked fine but now it shuts down during bootup when I have it connected. I've tried emailing them multiple times but I've had no reply. When I ordered my circuit in the first place I had to email three times before he shipped it.

Does anyone know what's going on with the person who runs this business? It's the only good one button on/off solution I'm aware of for the Pi, I really want to get it working. I ordered another switch after ruling out every other possibility I could think of, but god knows if it will ever arrive.

Anyone aware of a similar alternative I could investigate? I want an on/off solution that I can link to one single switch, not interested in anything that doesn't accomplish that.

[fruitoftheloom]

http://retrorpojects.blogspot.com.au

Webpage found not found.....

[DougieLawson]

Have you updated your firmware recently? Because in some cases the kernel now sets up the GPIO pins with different initial values.

You may find that GPIO23 (read from /sys/class/gpio/gpio23/value) is getting pulled high when you least expect it. When that pin is high your system will shutdown (because /etc/switch.sh is started from /etc/rc.local and is in a loop waiting for 23 to go high).

As part of testing it update your /etc/switch.sh program with this version

Code: Select all

echo "23" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio23/direction
echo "24" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio24/direction
echo "1" > /sys/class/gpio/gpio24/value
while [ 1 = 1 ]; do
  power=$(cat /sys/class/gpio/gpio24/value)
  if [ $power = 0 ]; then
    sleep 1
  else
    echo "At this point I would have run sudo poweroff"
  fi
done

that way you should be able to prove if my theory is true.

What I'd do to fix it is update /etc/switch.sh to start by configuring pin23 as an output and forcing it to low, before switching it to an input and waiting for your mausberry to pull it high as part of its power off sequence.

[B.M.O.C.]

Thanks fruit of the loom, had a typo in that URL, now fixed (and again http://retroprojects.blogspot.com.au/).

Hey Dougie,

Thanks for the reply. It is possible that this started happening when I updated firmware, it's hard to remember. But the switch definitely worked fine previously, so here's hoping you're right.

If you're willing, can you talk me through this a bit more? My knowledge when it comes to this stuff is extremely limited. I can replace the contents of the switch.sh with the code you've provided, no worries. But what you've said after that:

What I'd do to fix it is update /etc/switch.sh to start by configuring pin23 as an output and forcing it to low, before switching it to an input and waiting for your mausberry to pull it high as part of its power off sequence.

Is this an additional step? Because I don't know how to do this, I'm afraid it's a bit over my head.

But I'll do the test first, what result should I be expecting with this altered script?

[B.M.O.C.]

Ok so I didn't need to ask that last question, the result was very obvious, the text "at this point I would have run sudo poweroff" filled the screen at the point which it would usually halt and shutdown.

Does this confirm your theory?

Are you willing to talk me through the changes I need to make to get this working? I would be incredibly appreciative. I also imagine a lot of people using these switches are going to run into this issue when they update, so it would be great to have a step by step fix, I'll put it on my blog also.

[DougieLawson]

OK. Theory proven. We need to initialise both pins to expected values so update /etc/switch.sh

Code: Select all

#!/bin/bash

#this is the GPIO pin connected to the lead on switch labeled OUT
GPIOpin1=23

#this is the GPIO pin connected to the lead on switch labeled IN
GPIOpin2=24

echo "$GPIOpin1" > /sys/class/gpio/export
# Set $GPIOpin1 as output 
echo "out" > /sys/class/gpio/gpio$GPIOpin1/direction
# Initialise $GPIOpin1 to a LOW value
echo "0" > /sys/class/gpio/gpio$GPIOpin1/value
# Now make $GPIOpin1 an input
echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction
echo "$GPIOpin2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIOpin2/direction
echo "1" > /sys/class/gpio/gpio$GPIOpin2/value
while [ 1 = 1 ]; do
power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
if [ $power = 0 ]; then
sleep 1
else
 sudo poweroff
fi

[B.M.O.C.]

Ok so that stopped the reboot from occuring during boot. However it's not shutting down when I press the button.

I noticed just before emulationstation loaded that there were a bunch of error messages associated with the script.sh, there were lines from the script and then a message saying that the device was busy, or something like that?

It flashed up quick and I don't know how to capture the information, I assume there is a way to output everything to a file. How do I do that? Then I can give you the exact error messages.

Really appreciate your help.

[DougieLawson]

Install a copy of webiopi. You can use that to easily see the status of the GPIO pins.

[B.M.O.C.]

Ok so I installed WebIOPi, after booting the status of pin 23 is IN and pin 24 is OUT

Does this tell you anything?

I gather they are supposed to be the other way around? Changing them through WebIOPi didn't affect the switch functioning, it still did nothing when pressed.

Also here are the error messages that flash up just before emulationstation loads

Error opening '/dev/input/event4' No such device or address
/etc/switch.sh: line9 : echo: write error: Device or resource busy
/etc/switch.sh: line9 : echo: write error: Device or resource busy
/etc/switch.sh: line16 : echo: write error: Device or resource busy
/etc/switch.sh: line26 : syntax error: unexpected end of file
/etc/switch.sh: line16 : echo: write error: Device or resource busy
/etc/switch.sh: line26 : syntax error: unexpected end of file
/etc/switch.sh: line26 : syntax error: unexpected end of file

[DougieLawson]

Bear in mind that I've not looked at the Mausberry hardware. It's using two pins, I guess it's up to you to decide which pins are connected and which function is assigned to each. Then get the script to run with the right input and output pins.

The suggestion to use webiopi is that you can see (with a nice pretty display) what happens to the pins when you activate the Mausberry's primary function. It wasn't so you could fiddle with setting inputs to outputs or setting high values on an output to low values.

[B.M.O.C.]

Yeah ok, I guess I just thought it was worth a try. But right now pressing the switch has zero effect, and I would assume that is because the script is not functioning anymore (hence the error messages). Surely that needs to be solved first? Or do those error messages not mean anything of consequence?

[DougieLawson]

It looks like you've lost the last line in the file or have added a spurious character.

The device/resource busy either needs a reboot or, possibly, needs you to stop & restart webiopi.

[B.M.O.C.]

Actually I just reverted to the original script and those error messages are still present, and the original premature shutdown functionailty was restored. These error messages were present prior to the installation of webiopi, I think they must have always been there but I only noticed them after we altered the script.

So maybe this has been the problem all along.

[B.M.O.C.]

Ok the words done was missing from the latered script, adding that fixed the syntax error, but yeah, the busy error remains.

Edit: Should also add that adding "done" to your revised version of the script restored the original error of shutting down prematurely.

So I am assuming that these errors mean that the pins are not being set to what the script specifies?

[B.M.O.C.]

Also found another thread with someone having the same problem.

http://jp.raspberrypi.org/forums/viewto ... 28&t=84882

They only started having the issue after updating their firmware. For some reason something in the newer firmware is blocking access to the pins. Unfortunately this is so far beyond my knowledge level :/

[DougieLawson]

Try replacing the shell script with

Code: Select all

#!/usr/bin/python
 
import RPi.GPIO as GPIO
import os, time
 
GPIO.setmode(GPIO.BCM)
GPIO.setup(23, GPIO.IN)
GPIO.setup(24, GPIO.OUT)
GPIO.output(24, GPIO.HIGH)
 
try:
  while True:
     if (GPIO.input(23)):
        print ("Shutdown trigger received on pin 23")
        os.system("sudo shutdown -h now")
     break
  time.sleep(1)
except:
  GPIO.cleanup()

[DirkS]

Try replacing the shell script with

Are you sure the indentation of the 2 lines above 'except' is correct? It looks to me that the 'break' is part of the if statement and the 'sleep' should be inside the 'while' loop

Gr.
Dirk.

[B.M.O.C.]

Dougie, when you say replace the shell script, are you saying I should replace the contents of the switch.sh script with that code, or is this code meant to run from a different place?

Edit: Ok that was probably a silly question, I'm guessing the first line specifies what system that code interacts with.

[B.M.O.C.]

Ok so I tried the change and I got a similar result albiet in different words.

etc/switch.sh: 8:RuntimeWarning: This channel is already in use, continuing anyway

Just getting that for a bunch of lines in the script.

[DougieLawson]

We need to know what status the Mausberry expects the pins to have (and that isn't available in their, frankly poor, documentation). There was a firmware update from July 15th
http://www.raspberrypi.org/documentatio ... uration.md that, too me, looks like it could be the cause of the problems.

One option is revert to a commit of the firmware before that update.

sudo rpi-update d9eb023ba98317d81fc53a3f9d6752b127a8dbbf
which will take you back to 3.12.24+

If we can't work it out someone will have to mail their Mausberry to me so I can do some exhaustive testing with it.

[B.M.O.C.]

Hey Dougie, I'd be happy to mail mine to you, it's not doing me any good. Even if I roll back my firmware, the previous firmware has issues with analogue sound output which makes it no good for me either.

The thing is though, is this anything to do with the switch? Those error messages suggest to me (disclaimer: I know next to nothing about this stuff) that there is a problem changing the state of the pins period, aside from anything to do with the switch. Even if I change the script to reference different, unused pins, even if I disconnect the switch entirely, I still get those messages saying the pins are busy. So what's going on there?

Perhaps there is something else that's part of the Retropie image that is causing this conflict? What happens if you run those commands with an up to date version of plain raspbian? Do you get any such errors?

Two things I'l try as soon as I get a chance:
1. roll back to the previous firmware and confirm that the switch does work, to eliminate the possibility that my tinkering somehow damaged the GPIO pins or something (but I highly doubt this would be the case)
2. try it with the stock standard latest raspbian, rather than starting with the retropie image and then updating the firmware, to confirm that there isn't something in all the retropie software that's interfering.

[DougieLawson]

I don't have a Mausberry. From a pure software angle everything works the way I expect it to regardless of whether I wiggle the GPIO pins with a bash script or a python program. Predictable input gets predictable output.

The mystery is what the Mausberry expects on the output pin vs what it does on the input pin and what it does differently when the shutdown switch is closed.

[B.M.O.C.]

I can completely remove the switch from the whole system (physically) and I still get those error messages as soon as I run any script that attempts to manipuate the pins. I'm assuming that no matter what the switch expects, until I can run commands that manipulate the pins I'm not going to get anywhere.

There must be a reason that I get those errors, and if you aren't getting them with the latest raspbian kernel then there must be something else that's causing problems, which I have to assume is something else that's included in the retropie image.

[B.M.O.C.]

So I just tried to rolled back to the original retropie image, just reflashed my SD card from scratch, didn't update anything. Connected up the switch and installed the script. On first bootup, it worked, did exactly what it was supposed to. On second bootup, it shutdown prematurely. Wtf? Then every subsequent bootup it would shutdown prematurely. Never got any of the error messages about access to pins but it just shut down.

So I tried your first revised script, same thing, premature shutdown. Tried the python script, it didn't shut down but it didn't respond when the button was pressed. Also I had really bad stability the whole time, freezing, gamepads failing to be recognised, wifi cutting in and out. I ended up having to bypass the switch to get it to bootup without crashing, so that I could make changes to the script.

Something seriously strange going on here. Especially since there WAS a time when the switch was working 90% of the time. It's gotta be busted I think, I'll just have to wait till I get a replacement, I don't know what else to do. I might try ATXRaspi, that's a similar switch and the guy from the website responds to emails instantly so at least I can be confident it will arrive soon after I order it. I'll just have to go momentary switch instead of toggle.

[sav25]

I had a similar problem when I got my switch from them (well, I think it's a similar problem).

My switch/code was causing a reboot every time I turned it on. After trying a lot of different things and checking the GPIO being used, I eventually installed a fresh copy of Raspbian and tried the switch install again - and it worked.

Seems you've tried that though.

Might be a silly suggestion, but have you checked the GPIO pins you have used it with? I sometimes get mixed up with physical pin numbers, BCM numbering, GPIO.BOARD numbering etc...they don't make it easy!