Closed scottleibrand closed 8 years ago
How did you flash the Edisons?
I've flashed yocto onto Edisons via the Explorer board about a dozen times and never had it corrupt the firmware. I think it's more likely that subg_rfspy got into a bad state and needed to be reset. The reset that was in spi_serial was there to take care of such issues, and it may be that calling the reset function would have fixed your issue.
It's already on the subg_rfspy todo list to fix the communications protocol. If the wrong bytes are sent, it can put it into a state where the CC1110 expects more bits than the Edison thinks it should send. I'm going to put in a timeout to keep this from permanently messing things up.
On Sun, Sep 18, 2016 at 1:24 AM, Scott Leibrand notifications@github.com wrote:
I just flashed Yocto and Ubilinux onto two different Edisons using the Explorer board, and in both cases when I got everything installed the subg_rfspy firmware did not respond correctly, but rather gave me lots of �'s. Flashing spi1_alt2_EDISON_EXPLORER_US_STDLOC.hex fixed it both times.
Is there anything we can do to prevent the OS flash process from erasing/corrupting the subg_rfspy firmware?
root@edison-eb ~/src/915MHzEdisonExplorer_SW # python ExplorerTest.py ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/issues/8, or mute the thread https://github.com/notifications/unsubscribe-auth/AApIHr1lsbdoXq6C41PaLql2LQQWOmx5ks5qrPUrgaJpZM4J_1xg .
Interestingly, a full halt and power-cycle didn't recover it.
What would be the command to run the reset manually now that we've moved it to its own function? I'll give that a try if I see this again after the next flash.
Yep, looks like that was it. Had it happen again after powering it on (with no flashing involved), and was able to do python -c "import spi_serial; s=spi_serial.SpiSerial(); s.reset()"
to reset it.
For now, I just added that to my crontab to run (and then retune) if wait-for-silence gets stuck retrying for 10m. Probably should figure out a more direct way to check that...
* * * * * killall -g --older-than 10m openaps && python -c "import spi_serial; s=spi_serial.SpiSerial(); s.reset()" && cd /root/myopenaps && openaps use pump mmtune
Ultimately, the fix for this needs to be in subg_rfspy.
Short term, I recommend checking subg_rfspy status before doing anything major. If you don't get back ok, then you can reset.
On Sep 18, 2016 4:01 PM, "Scott Leibrand" notifications@github.com wrote:
Yep, looks like that was it. Had it happen again after powering it on (with no flashing involved), and was able to do python -c "import spi_serial; s=spi_serial.SpiSerial(); s.reset()" to reset it.
For now, I just added that to my crontab to run if wait-for-silence gets stuck retrying for 10m. Wondering if there's a better way to
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/issues/8#issuecomment-247886809, or mute the thread https://github.com/notifications/unsubscribe-auth/AApIHno95Md9pXlWGBoyzeuIy9ZBZ67zks5qrcK1gaJpZM4J_1xg .
Ok, will do, thx.
I just flashed Yocto and Ubilinux onto two different Edisons using the Explorer board, and in both cases when I got everything installed the subg_rfspy firmware did not respond correctly, but rather gave me lots of �'s. Flashing spi1_alt2_EDISON_EXPLORER_US_STDLOC.hex fixed it both times.
Is there anything we can do to prevent the OS flash process from erasing/corrupting the subg_rfspy firmware?