"Script not running!" but it is?

Hi All, I’m having some issues with a fresh install of brewpi on a Raspberry Pi 2 and a BrewPi Spark. I’ve run through the usual:

sudo apt-get update
sudo apt-get upgrade
sudo rpi-update
git clone https://github.com/BrewPi/brewpi-tools.git ~/brewpi-tools
sudo ~/brewpi-tools/install.sh
sudo python /home/brewpi/brewpi.py --kill
sudo python ~/brewpi-tools/updater.py
(I chose the develop branch for both /home/brewpi and /var/www)

I created a config.cfg containing:
boardType = spark-core

But when I check the web interface I get the following:
http://imgur.com/WeKRAf1

However, brewpi.py --status shows that it is running:
[{‘cfg’: ConfigObj({‘scriptPath’: ‘/home/brewpi/’, ‘wwwPath’: ‘/var/www/’, ‘port’: ‘/dev/ttyACM0’, ‘altport’: ‘/dev/ttyACM1’, ‘boardType’: ‘spark-core’, ‘beerName’: ‘My First BrewPi Run’, ‘interval’: ‘120.0’, ‘dataLogging’: ‘active’}),
‘pid’: 3515,
‘port’: ‘/dev/ttyACM0’,
‘sock’: {‘sock’: 0, ‘host’: ‘localhost’, ‘type’: ‘f’, ‘port’: None, ‘file’: ‘/home/brewpi/BEERSOCKET’}}]

There are no errors in stderr.txt:
Mar 31 2015 11:34:03 Notification: Script started for beer 'My First BrewPi Run’
Mar 31 2015 11:35:03 Notification: Script started for beer ‘My First BrewPi Run’

I’ve manually run sudo /home/brewpi/utils/runAfterUpdate.sh and
sudo /home/brewpi/utils/fixPermissions.sh. But that didn’t help.

The only oddity I’ve noticed is that the socketfile isn’t getting created?
ls -lta /home/brewpi/BEERSOCKET
ls: cannot access /home/brewpi/BEERSOCKET: No such file or directory

If I manually run the script and ctrl+c it, this is the result:
Mar 31 2015 13:21:13 Notification: Script started for beer ‘Test’
^CTraceback (most recent call last):
File “/home/brewpi/brewpi.py”, line 358, in
hwVersion = brewpiVersion.getVersionFromSerial(ser)
File “/home/brewpi/brewpiVersion.py”, line 28, in getVersionFromSerial
ser.write(‘n’) # request version info
File “/usr/local/lib/python2.7/dist-packages/serial/serialposix.py”, line 511, in write
_, ready, _ = select.select([], [self.fd], [], None)
KeyboardInterrupt

I’ve been troubleshooting this for hours now with no success. Any ideas?

Thanks!

I have noticed this too when debugging the Arduino programming bug.

The script hangs in writing to the serial port while trying to read the version from the Arduino. I don’t know why it hangs on the serial write. Something’s up with the serial port. A reboot will fix this.
The version check happens before the socket is opened, which is why the web interface thinks the script is not running.

We could enable write timeout on the serial port and add an exception handler. But I don’t know how to resolve it other than rebooting the Pi.

Thanks for the reply, I had done numerous reboots without resolution but I hadn’t actually checked on the BrewPi Spark itself. After the brewpi script starts (for the first time after a reboot) the spark goes into a screen calibration menu where you have to press the screen in two places. Immediately after calibrating the screen, the script no long hangs. This is repeatable as well- after every reboot and brewpi script starts- I have to physically do the screen calibration. Is this something you see on your end as well? Is the screen calibration required?

Thanks!

I have not been able to reproduce this actually but I have seen it before, so I’d would really like to know why this happens.

When you calibrate the screen, are the coordinates around 1600,1600 and 300,300?

Could you make a dump of the entire external flash memory (the calibration settings are stored here), so we can investigate?

To do this, you will have to put the Spark Core in DFU mode. This is done by holding the mode button during startup.
With the Spark core being inside the enclosure, this is a bit trickier, but the holes in the bottom are right above the buttons. You should be able to press them with a paperclip.

If you look into the USB connector, the right hole is the mode button and the left hole is the reset button.
You have 2 options:

  • Hold the mode button, press the reset button, wait until yellow flashing after about 3 seconds. Let go. Don’t hold it 10 seconds. This will cause a factory reset.
  • Hold the mode button, insert USB cable to power on.

If you do it right, a yellow LED should start flashing inside. The Spark Core is now in DFU mode.

You can now run this command to download the entire contents of external flash memory into a file:

dfu-util -d 1d50:607f -a 1 -s 0x0080000:0x200000 -U memory-dump.bin

@mdma, please correct me if I have the wrong memory area.

Sure thing, I’ll see if I have time to do this tomorrow.

Looks good to me!

@maxxoverclocker the flash dump is immensely useful to us so want to thank you in advance for going through the pain of getting it. :wink: (DFU is a pain.) :-/

If you don’t already have dfu-util installed instructions are here: https://github.com/spark/firmware/#3-device-firmware-upgrade-utilities

Good luck!

I’m also having an issue like this. My Spark is having me recalibrate all the time (every time I restart Pi and Spark). It’s also saying that it can’t get the version, and tells me to (re)program my arduino. Should I have to reprogram my Spark all the time? It seems like it isn’t saving the settings…

Hi @ZBrew! Could you please install dfu util and dump the contents of your core’s external flash.

Neither Elco nor I have been able to reproduce the issue, so your help by producing the eeprom dump file is greatly appreciated!

Absolutely, I’ll get you this file hopefully tomorrow. Thanks for the help!

I’ve been having a heck of a time getting dfu-util working on my pi, but finally think I have it working. I’m going to be busy tomorrow but perhaps tomorrow night i can get it uploaded.

@Elco, @mdma, I just sent you a private message with the memory-dump.bin file you requested. Just a little more info on my issue…looking at the stderr.txt file I see that a temperature sensor is being disconnected periodically (but the address doesn’t match any of my sensors). I’m also getting A TON of broken pipe messages. Let me know if you need additional information.

I should also mention that I can control in ‘Beer Constant’ mode, but it’s extremely unreliable. After a couple hours, the website says the script isn’t running anymore and I can’t get it started again without restarting the Spark. When I do the Spark reset, it says it can’t find the version of software I’m running and tells me to (re)program.

How are you powering your Raspberry Pi? It sounds like the supply voltage might be too low.
Which version are you running on the Spark Core?

@Elco, @mdma

Sorry for the delay- to answer your question Elco, the coordinates are a bit off from what you had mentioned: 1679,1600 and 324,373. Here is a copy of the memory dump: http://s000.tinyupload.com/?file_id=26721758652117489161. Let me know if you guys need anything further.

1 Like

Thanks so much @maxxoverclocker and @ZBrew for the memory dump files! Much appreciated.

It’s late here now - I will take a look at them tomorrow, see if we can’t get to the bottom of this mysterious bug!

Hey @maxxoverclocker, @ZBrew!

Can you confirm the device was asking for touch screen calibration when you made the memory dump?

If not, could you wait until the device asks for calibration and then repeat the dump process.

Many thanks!

@mdma that’s a good point, I know for a fact mine was not on the calibration screen when I made the memory dump, I had already calibrated. I just re-re-re-re…-programmed the spark core last night from the webgui and I just tried to reproduce the issue this morning and the pi and brewpi came up without any coaxing. The script started and the brewpi didn’t ask for calibration. I’ll be watching for the problem and take a memory dump if or when I see it.

2 Likes

@mdma has tested your memory dump and found out it was fine. All settings were stored correctly. When he flashed the memory dump to his spark core, it did not ask for calibration.

It seems that the controller is receiving the a “T” over the serial port from the Pi, which is the command to trigger serial calibration. Where this T is sent, I do not know.
This can be reproduced by rebooting the Pi, then connecting the controller.

This is dangerous, because if you do not have physical access, there is no way to skip through the screen. During the calibration routine, the controller is not reading from the serial port, so it won’t even listen to a reset command.

A way to restart the controller when it is completely unresponsive, is to disable power to the entire USB bus for a second:

sudo su
echo 0x0 > /sys/devices/platform/bcm2708_usb/buspower; sleep 1; echo 0x1 > /sys/devices/platform/bcm2708_usb/buspower

This will restart the controller and get it out of touch calibration. It will also temporarily disable power to Ethernet and WiFi.

Proposed solution for the next release is to remove the serial command to trigger recalibration and replace it with a boot screen that says “tap screen now to recalibrate touch” and boots to normal operation after 5 seconds. After that moment, touch screen calibration cannot be triggered.

Awesome. That sounds about right. Do you know why the controller is receiving the “T” command? And why it’s only sent after the pi reboots? Because the behavior you described sounds about right. I don’t get the screen when I unplug power to the spark core and plug it back in. Only when the pi reboots.

Thanks for the update!

I don’t know why the data is lingering in the serial port. The script now flushes all pending data on opening the serial port and we have removed the command. It was the only command that could put the core in a mode where it does not respond to serial, so it was a dangerous command. They way it is solved now in the boot screen is much better.

I’m not sure if I am having the same issue, it seems to be. I updated the raspi firmware yesterday and when the reboot was completed everything boots up but I get the error script message.

I have tried to reboot the raspi several times and also unplugged the raspi and BrewPi from the power source for about a minute and then plugged back in. The calibration came up for about a second then went to the normal temp display screen.