Bugzilla – Bug 12971
Reset MSP if no I2C, rather than reprogramming
Last modified: 2009-10-05 14:37:37 UTC
I have still seen some cases of the MSP out to lunch. I think that the kernel should give the MSP a reset if it can't communicate, before reprogramming. The correct solution, of course, is to never have the MSP go to lunch in the first place.
Reset priority before triage.
== Auto-comment from SVN commit #7012 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7012 == Bug #12971 If we can't read the firmware revision from the mcu, reset it and try again before reprogramming. Sometimes it seems to fail to respond, and resetting it may workaround this problem.
Caleb this is done, please review the patch. I have tested this via the command line and it appears to work, but can't verify the MSP is really reset: # echo "program" > /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/flash firmware: requesting msp430-0003.txt # i2c-adapter i2c-1: ACK not received Couldn't read msp ID register, resetting mcu ssi1_irq SISR 800120 SIER 180100 fifo_errs=2 WARN audio_thread_execute:759 xrun (snd_pcm_wait) WARN audio_thread_execute:710 underrun!!! (at least 21444.427 ms long) i2c-adapter i2c-1: ACK not received Couldn't read msp ID register, resetting mcu ssi1_irq SISR 8001a0 SIER 180100 fifo_errs=3 WARN audio_thread_execute:759 xrun (snd_pcm_wait) WARN audio_thread_execute:710 underrun!!! (at least 648.910 ms long) i2c-adapter i2c-1: ACK not received Couldn't read msp ID register, resetting mcu ssi1_irq SISR 8001a0 SIER 180100 fifo_errs=4 WARN audio_thread_execute:759 xrun (snd_pcm_wait) WARN audio_thread_execute:710 underrun!!! (at least 633.520 ms long) msp430: upgrade (-1 to 716) ssi1_irq SISR 8001a0 SIER 180100 fifo_errs=5 WARN audio_thread_execute:759 xrun (snd_pcm_wait) WARN audio_thread_execute:710 underrun!!! (at least 11198.220 ms long) msp430: upgrade complete (716)
Richard, it doesn't seem to actually reset the device. It needs to pull RST low. Unless ResetDevice does this, I don't see the code that pulls the pin low for a few microseconds.
== Auto-comment from SVN commit #7036 to the jive repo by ccrome == == https://svn.slimdevices.com/jive?view=revision&revision=7036 == Bug #12971. Needed a longer delay with the new MSP code.
== Auto-comment from SVN commit #7064 to the jive repo by ccrome == == https://svn.slimdevices.com/jive?view=revision&revision=7064 == Bug #12971. Had to move the delay to *before* the irq_restore so that nobody else could come along and attempt to use the I2C bus before the MSP is back on line. Without this, if something else access the I2C bus, it hangs and causes a reboot.
Richard, please take a look at my change. See comment above.
Created attachment 5616 [details] Special MSP load for testing this bug If you echo 1 > /sys/bus/i2c/devices/1-0010/kill it will send the msp into a 'while (1);' loop. That way you can verify that the msp gets reset. i.e.: echo 1 > /sys/bus/i2c/devices/1-0010/kill; echo program > /sys/bus/i2c/devices/1-0010/flash will cause the msp to hang, then the reprogram will fix it. if there is too much time between the kill command and the program command, the app tries to touch the i2c interface, and it hangs and reboots.
== Auto-comment from SVN commit #7144 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7144 == Bug #12971 Fix lockup in msp430 driver when the i2c bus fails. Increased the start up delay after programming (this was failing here), and moved this after the irq's are enabled now the lockup is fixed.
I've moved the delay after the irq is enabled, and fixed the lockup (it was in the msp430 driver). I also had to increased the start up delay, otherwise the programming appeared to fail. Caleb, I'm not expecting this bug back, so if your happy you can close it now :). I tested with the following sequence: 1. kill msp430 (while loop) 2. several cat's to do reads from msp430 3. reprogram, checking the msp430 is reset 4. cat to make sure it's working again. Log is below. # echo "1" > /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/kill # # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/fw i2c-adapter i2c-1: Data not transmitted i2c-adapter i2c-1: Could not set I2C Bus Busy bit to zero. cat: read error: Operation not permitted # # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/fw i2c-adapter i2c-1: Bus Arbitration lost i2c-adapter i2c-1: Could not grab Bus ownership cat: read error: Operation not permitted # # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/fw i2c-adapter i2c-1: Bus Arbitration lost i2c-adapter i2c-1: Could not grab Bus ownership cat: read error: Operation not permitted # # echo "program" > /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/flash Requesting msp430 firmware msp430-0003.txt firmware: requesting msp430-0003.txt i2c-adapter i2c-1: Bus Arbitration lost i2c-adapter i2c-1: Could not grab Bus ownership Couldn't read msp ID register, resetting mcu i2c-adapter i2c-1: Bus Arbitration lost i2c-adapter i2c-1: Could not grab Bus ownership Couldn't read msp ID register, resetting mcu msp430: upgrade (-1 to 747) msp430: upgrade complete (747) # # cat /sys/devices/platform/i2c-adapter\:i2c-1/1-0010/fw 747
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.