Brewpi keeps rebooting after script update [Solved]

Hello,

After updating the script to the lastest version, my brewpi spark keeps rebooting when conntected to the Raspberry.

Before the reboot, the Spark core LED starts flashing red. This only happens with the lastest script version.

I already reflashed the spark with:

python flashDfu.py

This is the stderr output:

 Dec 25 2015 20:59:04   Opening serial port
 Dec 25 2015 20:59:04   Notification: Script started for beer 'My First BrewPi Run'
 Dec 25 2015 20:59:14   Checking software version on controller... 

 Dec 25 2015 20:59:14   Found BrewPi v0.4.1 build 0.4.1-0-g69ee566, 
running on a Particle Core with a V2 shield on port /dev/ttyACM0

 Dec 25 2015 20:59:16   Serial Error: Write timeout)
 Dec 25 2015 20:59:33   Serial Error: [Errno 5] Input/output error)
 Dec 25 2015 20:59:33   Lost serial connection. Error: [Errno 2] No such file or directory: '/dev/ttyACM0')
Terminating due to fatal serial error

Any idea?

Can you try flashing it again with flashDfu.py? Run it with sudo.

Also can you check what the pattern is in the red flashes?

Hi Elco,

Thank you for the fast response.

I tried reflashing. Same problem.

 sudo python flashDfu.py
Using dfu-util binary at downloads/dfu-util
Detecting DFU devices
Found 1 devices:  ['1d50:607f']
Device identified as Spark Core
Downloading latest firmware...
Latest stable version on GitHub: 0.4.1
downloading https://github.com/BrewPi/firmware/releases/download/0.4.1/brewpi-0.4.1-core.bin
Firmware downloaded to /home/brewpi/brewpi_spark/utils/downloads/0.4.1/brewpi-0.4.1-core.bin
Now writing BrewPi firmware /home/brewpi/brewpi_spark/utils/downloads/0.4.1/brewpi-0.4.1-core.bin
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x1d50 product = 0x607f
Opening DFU capable USB device... ID 1d50:607f
Run-time device DFU version 011a
Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/20*001Ka,108*001Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
No valid DFU suffix signature
Warning: File has no DFU suffix
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08005000, size = 109956
............................................................................................................
File downloaded successfully
Transitioning to dfuMANIFEST state
Error during download get_status
Programming done
Now resetting EEPROM to defaults
Opening serial port
 Dec 26 2015 10:09:03   Opening serial port
 Success! Found BrewPi v0.4.1 build 0.4.1-0-g69ee566, running on a Particle Core with a V2 shield on port /dev/ttyACM0

 Resetting EEPROM to default settings
 INFO MESSAGE 15: EEPROM initialized

The LED blinks in red short flashes then 8 times in long red flashes, again in red short flashes then 8 times in long red flashes and reboots.

Hi Doomy,

8 flashes means “Out of heap memory”

I have been able to reproduce this and I am going to look into it.
It seems to happen when json is generated of all control objects, which puts a lot of objects on the heap. I have been testing mainly on the photon, so this went unnoticed.

You can revert back to 0.2.11 with:

sudo python flashDfu.py --tag=0.2.11

Another temporary fix is to never trigger that command and comment out:


Found a fix. The core was running out of heap memory when creating the JSON output for the control algorithm tab.
In the last update of the script, this was requested at startup instead of only when clicking the refresh button. That is why the core did not crash before when starting the script.

In the update, the JSON output is sent to serial directly, instead of being buffered in a string. This requires less memory and does not crash.

Released a fix in version 0.4.2.

Now I can go back to celebrating Christmas in peace again :christmas_tree: :smile:
Thanks for reporting the bug.

Wow, thank you elco. You are the best!