USB Device Malfunction - Center Console Port #598
Comments
|
I’m only a recent user of TeslaUSB, i’m using a Pi Zero W and was getting this exact issue.. resolved it by changing to a better quality micro USB cable. Haven’t had it since. |
|
Got a link to the cable(s) you're using? |
|
I get the same error message after about an hour of driving. I tried removing my hub and everything and nothing helped. |
|
Same. This same setup (Pi Zero W, center console port, Model 3 from a few years ago) has worked since for ages, and my wife started noticing this error about once a day since the 2020.48.30 update. The Pi is on a battery backup (I have a battery connected to the microUSB power port, in addition to the cable on the data port) - not sure if that's a common factor or not with the other reports. |
|
I'm using the same cable as @CMDRPhaedra and still getting this issue. |
|
The only times I've seen "USB device malfunction" was when the Pi was drawing too much power (the car seems to complain when there's a high load on the USB port for more than a few seconds, like for a Pi4+SSD booting up), or when I unplugged a (battery powered) Pi0 from the car immediately after getting in to the car. |
|
It seems to happen when the Pi loses WiFi (e.g., when about a block from the house) - Is there anything that happens in the archiveloop when that event occurs? |
|
I'm seeing the issue after about an hour of driving. Pi0, with or without hub / phone chargers / other usb devices plugged in. It has persisted through at least two fw updates and a complete reinstall of tesla USB |
Have you tried it on 2020.48.35.5? |
|
Yeah. Still saw it a couple times already unfortunately. |
My Pi4 has no USB attached. Just an SD card. Admittedly, Pi4 versus Pi0, so more power hungry to start. I am not 100% sure this is TeslaUSB though. Someone on the Tesla Discord server mentioned getting the same error with a flash drive. He said his car was being brought in to have a working session with the Tesla engineers on the phone. Same error, but different circumstances. |
Damn. I haven't driven with 2020.48.35.5 installed yet, was hoping this was one of the bugs. I did report the issue to Tesla via the support chat. But they stated TeslaUSB wasn't supported, so they don't appear to be giving the complaint too much weight. Not sure if others want to report the issue as well, see if we can it sorted through a volume of complaints. |
|
Same issue here. Details below:
EDIT:
|
|
I've had the same problem and error messages using a few of the latest car firmware versions including 2020.48.35.5 But earlier i used a power bank connected to the pi to supply backup power. Disconnected the power bank, no more error messages. 👍😃 |
|
@JohPePe Isn't that solution amounting to "reboot the Pi when the car comes out of sleep"? (I have my PiZeroW connected to a battery bank as well, so I can SSH into it "whenever", not just when the car is awake) |
|
@ScottESanDiego yes, I guess that’s why it’s working for me... 😀 |
|
Same here. Sucks though as this is probably a car issue, not a Pi issue. |
|
Same issue here, happens randomly and regularly since late December 2020. Pi0, SD card only connected. |
|
Getting the error but it's still working fine. More annoying than anything. The irony is that my car is MIC so the pi zero is in the glovebox, but it still says central console. |
|
I removed the battery that was driving my PiZeroW (per the above discussion), and didn't have any change in behavior. There's still the more-or-less random failure, and associated noise and message on the screen. Looks like I have to reboot the Rpi (aka, unplug/replug the microusb connector) to get the car the recognize it again. This is super annoying. :-/ |
|
For what it's worth, I moved over to a RPi4 and the problem disappeared. |
How do you power a RPi4? I’d do it in my Model 3 if I could figure out how without taking console apart. |
|
@miles267 I deleted my previous comment because I had my mind all messed up haha. Basically just get a USB-Y cable and plug the data side into the Pi's front USB ports, and the power side into the USB-C connector (you'll need an adapater). Then just plug it into the console's port |
I just ordered the two cables you had previously linked. Are there others that are recommended instead? (Am sure I’ll use those prev 2 cables for another project sometime in future anyway; won’t hurt to have them on hand) |
|
@miles267 I was thinking about it wrong and the ones I linked are the wrong gender, if I remember right. |
If you wouldn’t mind linking the appropriate cables it use it would be greatly appreciated. Will definitely grab them and try a RPi4. Also like the benefit of 5 ghz WiFi as my RPi Zero is only 2.4 ghz. I have one sitting, unused. Also, I’ve found that if I turn on Sentry Mode at home it keeps my USB powered in the console and the car doesn’t go to sleep. That caused my errors to go away. It confirms they were happening since teslausb isn’t keeping the car awake. |
|
@miles267 Now that I'm thinking about it, use that Y-cable I linked, and plug the data side (all black) into the RPi4's USB port. Plug the USB OTG cable into the charge-only side (the red/orange side). Then use this (link) to plug the Y-cable into the car. And yeah, that makes sense. I keep sentry on here at home too. I did, however, get random disconnects while driving with the PiZero. |
|
I'm getting the same random failures on my 2021 Model 3, using a Pi0 with an SD card, and a single USB cable from the Pi0 to the glovebox USB slot. I'm using sentry mode all the time/everywhere. I'm also missing some video clips from time to time, and I guess it's related. In a sentry-folder, there is usually about 10 minutes of footage, from 4 different camera's, so about 40 files (all 1 minute long), but I'm often missing a few of those minutes, making the footage unusable. I thought it was a CIFS/rsync issue, but it looks like the files just are not on the SD-card to start with, which makes sense if the car and Pi0 lose connection from time to time. Any hints on how to start debugging this? Maybe I should write a script with some Pi0 debugging data, such as the power it's drawing, or the read/write bandwidth etc, to find out what could be causing this? |
Thanks. It looks like I also need to get a "coupler" adapter to connect the male USB-A end of the OTG cable to the Y adapter. Didn't realize that. I'll find one. You're not having any issues supplying enough power to the RPi4 this way? |
|
Here are some test results which took a lot of time but might be helpful to isolate it:
As a side note I thought I fixed it when using the Tesla option for format the "DashCam USB drive" (TeslaUSB). It would be nice if this was supported, I don't think it is as I couldn't get it to mount afterwards. But the errors went away in this situation so I wonder if the problem with the USB is something to do with the way the partitions are mounted, not the USB emulation itself? Is it possible to test different layouts from the view of the car in the USB emulation/mount commands? What I wonder is, if we get the "format USB" to work from the car, then maybe we fix the other problem. Because shouldn't this TeslaUSB appear exactly like a USB stick. So long as it doesn't support formatting, then it suggests it is not fully compatble as a "USB stick". |
|
@CodeChief I would strongly advise against having the vehicle attempt to format that drive - it is anticipating a greenfield USB device, which your teslausb CAM slice most certainly is not - it is a living, breathing Linux partition masquerading as one. I would instead advise updating your teslausb installation in-situ, then copying debug logs here so we can help diagnose. A recent commit, live now, will help |
|
Also @CodeChief be aware some cables are just not meant to carry data - indeed, sometimes they transmit power only, or they transmit power and intermittent and/or unreliable data. You will have to pick and choose to find a production-ready solution. |
It does appear exactly like a USB stick. The problem with formatting it in the car is that the car will format it as ExFAT, which TeslaUSB doesn't support. |
BTW I'm a developer not a PC noob with lots of experience with virtual file formats for numerous technologies (Microsoft, VMware, Hyper-Converged). This is pretty low tech in my opinion and if there is an issue with formatting a virtual drive then the system used for emulation is not good. |
Again so what, and why not use the same default format as Tesla chose for their system? If not possible, again then the problem is the tool selected for drive emulation and this could be the reason it's confusing the car into thinking the USB port/flash-drive has gone bad. |
I've amassed hundreds of USB cables in over 30 years of IT experience and actively sort and throw-out crappy power-only cables. I keep a few labelled for nostaliga/tests. I've tested TeslaUSB with Pi0, Pi 4 with new and old single and split cables. All of these cables work on a PC even high speed NVMe drive external enclosures. It has to work, it's not the cable. |
|
I'd bet this issue has to do with the behaviour of the OS as orchestrated by the TeslaUSB scripts. You can't claim to be a USB stick but then behave like a network service (popping-up for a few seconds then disappearing before finally returning for a long time, then off again randomly when WiFi is available, like an on-demand service). The problem I think is rooted in the constant dismounting of the drive. Why is this necessary? Is it the snapshot mechanism (actually violating the whole point of a snapshot, by not being online)? It's also not very flexible or user friendly. Think about a design where the drive was always mounted, then remote commands could freely check status, even the SMB server could be used to remote browse regardless if/when it syncs. Why have this limitation that the TeslaUSB has to "see" WiFi then dissappear and reappear randomly? There must be many alternative snapshot/copy systems available for Linux and fully featured (online snapshots or robust locking/retry behaviour)? Perhaps the current tool is already capable of online snapshot/difference scans but the wrong configuration is used? I'll test the default format of Tesla on a normal stick tomorrow, but if it is ExFAT then I see that as a unit test of "USB stick emulation" and so a requirement even if some may not like it. If the system as configured by the scripts cannot be treated EXACTLY like a USB drive (including format) then something else could start to fail (as we see now). |
|
@CodeChief Your comments are coming off very arrogant. If you're so sure of the issue, I invite you to fix the issue on your own and submit a pull request. As you say you're a developer, please review the TeslaUSB source and you can see how the snapshot process and drive emulation works for yourself. Additionally, as you can see at the start of this issue, the problem in question originated after a car update, not a TeslaUSB push. And finally, to address your concerns about exFAT - the exFAT file system was added and made default in the car MCU as of version 2020.12. The Raspberry Pi bootloader does not support exFAT. Additionally, as of my last check, USB gadget tools does not support the exFAT FUSE module. |
|
Experience, not arrogance. Like if you tell an electrician more than once how to turn the lights on and off, don’t be surprised if you get an abrupt answer ;-) Anyway, no offence intended. Let's get on with troubleshooting...
What's left to examine as a potential root cause? I've thrown in some possibilities in a hope to trigger some positive line of investigation. Let's not repeat old responses which cannot be recreated/confirmed. |
|
If the pi mounts the shares to a PC using the same cable, yes, we can eliminate the cable as a potential cause. There used to be a .conf option to not use snapshots, but that has been deprecated and that functionality recently transferred to a lesser-used branch. I don't know if (strictly speaking ) |
|
Ok, so, I'm not 100% certain, but I think I have something on this. To preface this a bit, historically, when I get this error it's been on long drives and it occurs about every 45 minutes or so on the long drive. Alternatively the car has been sitting still somewhere and the Service>Notifications area is littered with errors from Sentry mode being on. I also have set "Cam storage" to 100% because, why not, it's not like I'm using it for music, I want the most storage available for videos. This is the default settings in the TeslaUSB config file: Notes on sd card and image sizes:* A 128 GB or larger sd card (or USB drive, when using Pi4) is recommended. Theminimum supported size is 64 GB.* When specifying sizes for the recordings and music drives, you can use specificsizes (e.g. 24G) or use sizes relative to the available space (e.g. 10%)* The setup script will reserve a fixed 6 GB of space regardless of sd card size.* CAM_SIZE should generally be somewhat small, around 16G to 32G, unless you planon accumulating a lot of footage between archive operations, in which case youshould increase the value (an hour of recordings, or 6 Sentry events, is about7-9 GB of data).* As of Tesla software version 2020.48.10, the car will warn when the recording driveis smaller than 32 GB, but smaller values will still work. Tesla appears to usepower-of-ten based sizes, presumably because most storage manufacturers do too.Because teslausb uses power-of-two sizes, you can specify "30G" for the size andnot get the warning.* MUSIC_SIZE should be large enough to hold your music library, obviously.* If no music size is specified, no music drive will be created.export CAM_SIZE=30G In speaking with Marcone, on Discord, using this 30G setting is recommended because TeslaUSB works predominantly off of snapshots, so you don't want the setting at 100% because the snapshots won't work. Taking this recommendation to heart I rebuilt both my TeslaUSB instances to use the above 30G configuration. My Model X has had no issues since this change was made. My Model 3 has had the issue with a vastly lower frequency count. When it does occur the logs seem to show that the snapshots ran out of space and were cleaning up a bit. However, ultimately, for me at least, the issue appears to tie back to the CAM_SIZE setting. As opportunity permits, can you all look and see what your CAM_SIZE setting is and perhaps lowering it, then seeing if the issue goes away? |
|
To add: take note of both CAM_SIZE and also the physical capacity of your media. The first should be significantly smaller than the second. If it's not, that is a good indiction the snapshots are being stomped on and potentially causing issues.
|
|
I'm about to go for a complete reinstall on my RPI0, 64GB SD card, and I will use a CAM_SIZE of 30GB as suggested (it was 32GB untill now). Not using music partition. |
|
@marnikvde any update on this? How'd it work out? |
|
I'm still getting malfunction errors/warnings from my Tesla Model 3. There's always a triangle on the left of the sentry icon (about the malfunctioning USB device), no way to get rid of the error, so I would conclude that the issue persists. |
Which version is your Tesla on? Mine are on 2021.4.15.5 and 2021.4.15 now. Maybe the issue as gone away in a later version and the CAM_SIZE variable is a fluke to when I got those updates? |
|
It has been on 2021.4.15 for a few weeks now. |
How does one recover from this? I have this problem - because my pi0 had the slow USB error. And seemed to stop recording altogether, as I never saw the dashcam icon on the car after that. I formatted it in the car. Do I SSH in and delete the backing file, or is there a nicer way to handle it (or re-install from scratch)? |
Either reinstall from scratch, or delete the backing file and run setup again. |
What battery bank do you use? are you constantly swapping cables between charging the batter itself and powering the pi? Or do you have one that has passthrough charging? Ty. |
|
Is this a duplicate of #564 (glovebox port incompatibility reported as error in "center console" port) or are we also tracking issues with power on pre-refresh model 3 and Y who are actually inserting it into the center console port and get the same error? If it is duplicate @marcone maybe close this one? |
I am a pre-refresh (2019) owner tracking this problem. |
|
"Dashcam USB drive not plugged into glovebox" is a different message than "USB device malfunction", so let's keep the issues separate for now. That being said, I am not seeing either problem myself so there isn't much I can do here. This is probably one of those cases where the community will have to find a solution. |
Oh okay, then we have confusing information depending on who is looking at it....
How annoying, that this "Center Console Port" error has been re-used for the glovebox :-/ |
We also get that error (2 variants mixed, I noticed sometimes more center console messages with the Pi4 vs Pi0)!
|
|
Me too. Set up the Raspberry Pi Zero W yesterday, installed it today, got a bunch of these errors. I'm using a 256Gb SD card with it set to 40G for cam and 10G for music. My first thought is that maybe the power supplied by the USB port is less than constant and reliable, and I plan to look up whether the Pi would let me supply additional power via its other micro-usb port (the one labelled "PWR" on the board).
|
|
I just merged a change that may help with the "device malfunction" error. Would be nice if someone can check whether or not it does. |
|
I believe I’ve just upgraded after the merge. Rebooted the Pi Zero 2. Not sure yet how to tell if it worked. There was USB alert but not certain whether that message preceded the upgrade. Will keep an eye on it.
…________________________________
From: marcone ***@***.***>
Sent: Saturday, January 8, 2022 7:50:00 PM
To: marcone/teslausb ***@***.***>
Cc: miles267 ***@***.***>; Mention ***@***.***>
Subject: Re: [marcone/teslausb] USB Device Malfunction - Center Console Port (#598)
I just merged a change that may help with the "device malfunction" error. Would be nice if someone can check whether or not it does.
(run setup-teslausb upgrade to update to the latest version)
—
Reply to this email directly, view it on GitHub<#598 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANKVGTFVR5EHHHXNOAZXMV3UVDSURANCNFSM4V22VQ7Q>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I was having the same experience as everyone else. But now that you mention it, this hasn't happened in probably 2 months. I am on 2022.8.3 now. I still have a problem where it randomly unmounts from the car and I have the red X. |
and others
After 2020.48.26 I started getting this error in my Model 3:
https://imgur.com/lS9PRoG
And, now that I have my Model X back, I can confirm I get it on my Model X as well, after 2020.48.30.
In both vehicles I'm using a Raspberry Pi 4. The fix is enough enough, unplug and plug it back in again. Not sure if it is because there's a point in time where it starts drawing too much power or something, but it is a noticeable issue.
I don't have a PI Zero to determine if there's an issue with this there now too.
The text was updated successfully, but these errors were encountered: