I took a three-day road trip to Yosemite this week with the v3.0 module in the car. It seemed to work fine, communicating over the modem except for the spotty reception in the Yosemite Valley due to the high stone cliffs. But back at home, some time after I had plugged in to start charging, the module stopped communicating via modem or wifi. I tried plugging in the USB cable to see what was wrong, but the /dev/tty.SLAB_USBtoUART device did not get created on my laptop so I could not see what went wrong. At that point, I decided I needed to cycle power to reboot, then the module came back up as verified via the home wifi, but the USB was still not responding. Now I have taken the module out of the car and brought it in to connect to the laptop and USB is working again. I guess that must imply that the USB physical connection, although the cable seemed solidly inserted while in the car. I have had the module configured to go to gdb rather than reboot on crashes since that was helpful for development, but I may need to change that setting to use the module in the car. On the other hand, with small RAM of the v3.0 module I don't think I can afford to have the SD card plugged in for logging, so being able to investigate crashes via USB might be best for now if I can figure out why that didn't work this morning. -- Steve
Today I found that the OVMS V3.0 had again become comatose. Again when I connected the USB cable to my laptop there was no response. Does the gdb stub depend upon the USB being connected at the time a crash occurs? I didn't like having to disconnect the car cable to power cycle the module when it gets hung like this, so I implemented an external reset button by repurposing the red plastic "RESET" button from a recycled hair dryer GFCI plug. (This may be a US-only oddity so those of you who live elsewhere may not have GFCI plugs on hair dryers.) In the GFCI the reset button has a shaft that pushes on electrical contacts. To use it for OVMS I needed to shorten that shaft slightly to match the distance between the inside of the case and the top of the reset button and then cut a slot in the OVMS box to fit the oblong shape of the button. -- Steve On Fri, 18 May 2018, Stephen Casner wrote:
I took a three-day road trip to Yosemite this week with the v3.0 module in the car. It seemed to work fine, communicating over the modem except for the spotty reception in the Yosemite Valley due to the high stone cliffs. But back at home, some time after I had plugged in to start charging, the module stopped communicating via modem or wifi. I tried plugging in the USB cable to see what was wrong, but the /dev/tty.SLAB_USBtoUART device did not get created on my laptop so I could not see what went wrong.
At that point, I decided I needed to cycle power to reboot, then the module came back up as verified via the home wifi, but the USB was still not responding. Now I have taken the module out of the car and brought it in to connect to the laptop and USB is working again. I guess that must imply that the USB physical connection, although the cable seemed solidly inserted while in the car.
I have had the module configured to go to gdb rather than reboot on crashes since that was helpful for development, but I may need to change that setting to use the module in the car. On the other hand, with small RAM of the v3.0 module I don't think I can afford to have the SD card plugged in for logging, so being able to investigate crashes via USB might be best for now if I can figure out why that didn't work this morning.
-- Steve
participants (1)
-
Stephen Casner