SWCAN Wakeup Issue

General Discussion
#1

Hey guys - I just go a M2 this week and have been playing around with it on my vehicle - I have a 2014 Silverado and a 2019 Traverse.

My goal is to setup a M2 in each with a Digi LTE modem paired with a custom app to run remote start, and door locks. Maybe do GPS tracking eventually as well.

I am fairly new to the Macchina World (obviously) but not new to CANBUS. I have been developing CANBUS modules in the Ag Industry for a while. Its pretty similar, but this is my first project with SWCAN.

Anyway…I’ve got my module reading message with no issues, and I’ve determined what frames I need to replicate from the OnStar Module to run my commands (both vehicles have an active subscription right now for testing). The frames I came up with are the same as other have posted, so that a good sign.

I have started just trying to wake the vehicle up, but can’t get that to work even.

The 2 frames that my silverado seems to be sending are the 0x100 wake up, and 0x62D with data {0x01,0x40,0x00,0x00,0x00,0x00,0x00,0x00}

My flow is this, and I’ve changed it up a few different ways with no luck.

  1. change Mode to 2
  2. wait 200ms
  3. Send 0x100 wake up (tried this with len = 8 with all 0’s and with len = 0)
  4. wait 200ms
  5. Send the aforementioned 0x62D message
  6. wait 200ms
    7 change to mode 3

That should wake my vehicle up? I sometimes get random message the first time I try it, but not the same message or even the same volume as when the Onstar wakes it up, or I open a door, insert key, etc.

I’ve also tried sending the 62D with the data mentioned in this post: Here

I hooked up my M2 to my desk power supply and looked at voltage on the SWCAN pin (not attached to a bus so might be why I’m seeing this).

When the M2 first boots I get 0V on the Pin 1 of OBD
I switch to Mode 2, and still 0V
I send the 100 Wakeup, and I read 7V on Pin 1 (Verified 12V at VBat yet)
the 7V stays after the Wakeup is sent, and if I switch modes back to 3, it goes down to about 3.1V and stays there regardless of what I send.
Im using just a multimeter so I understand I might not pick up the varying voltages during a transmission, however I find it odd how it goes to 7V and stays. If I switch back and forth between modes the voltage on the bus will continue to swap between 7V and 3.1V

EDIT: I hooked up the multimeter while plugged into my silverado - and I get different behavior voltage wise, which doesn’t surprise me I guess. When bus is idle it reads 0V on SWCAN. When I wake it up by opening a door it bounces from roughly 1.5 to 2.5v which seems right (for reading from a multimeter anyway). I don’t see the 12V wake up at all which is probably happened too quick. However when I put the M2 in mode 2 with the bus asleep, and send the 0x100 wake up, I don’t get any voltage change. It stays at 0 and no frames come through. I did hook the M2 up to a Arduino Due with CAN and I can receive frames from the M2. The due is not SWCAN though so no testing the HVWU of course.

Any ideas? Seems like I’m doing the same thing as most others, but obviously got something wrong, or its hardware issue.

Sorry for the long winded first post…hopefully this make sense to someone and I can get it working!
Thanks,
Tom

P.S. I got my feet wet with SavvyCan as well…what a powerful tool…wish I would have found this a long time ago!

#2

Finally!!

After countless hours of testing and trying different things. Tonight I finally was able to get my silverado to wake up and respond to the commands to lock, unlock, start engine, and stop engine.

What finally did it was I hooked a logic analyzer up to the bus and ran that while I tried transmitting with the M2 and found that my messages werent all making it to the bus.

I’ve always used MCP_CAN library for my Ag projects, so I ditched the SWCan and MCP2515 libraries that downloaded with the M2 package, and wrote a couple functions to control the Mode pins for SWCAN manually.

This worked, so I’m not sure what is different between the two, but I will have to look into that when I get a chance. It may have been something in my program too, but I was pretty much using the same functions as the examples. I may have a issue with multiple libraries or something of that nature too.

Either was it works, and I can now move on to wireless connection and an App to control it!

I read the Frames on my 2019 Traverse and they are the same as my silverado, but the car doesn’t respond to them so something must be a little different. I can read the Frames from the OBD port but wondering if there is a gateway that isn’t sending them back through when I transmit. Probably not going to tear into the dash to find out since it’s still in warranty. Can’t find a wiring diagram anywhere either.

FWIW, on my 2014 silverado it all works right from the OBD port.

#3

Hi Tom

Glad you got it figured out on the Silverado. It is interesting that the libraries were giving you trouble.

I took a look at our wiring diagrams for your 2019 Traverse and you are definitely dealing with a gateway.

#4

I will admit, it very well could be something on my end still - either way it works now. I’ll post back if I figure exactly why.

Thanks for looking at the wiring diagram - that is what I suspected, but good to know for sure. Maybe I’ll go down that road if I come up with something that works well for my Silverado, but it would have to work well as its my wife’s vehicle, so it would have to have her stamp of approval of course! :wink:

#5

Gateways are pretty much a safe bet on any newer GM, especially a 2019.

I have the same issues you do with a 2020 Bolt - the gateway will allow an external device to wake up the bus, but you cannot issue precondition/unlock/lock/etc commands from the OBD connector.

I’m planning on splicing into the radio’s SWCAN eventually, but I need to find a source for radio harness connectors as I don’t want to splice into the existing harness but do a passthrough breakout instead.

#6

Look for a harness that allows you do add an Aux port or something similar. Some newer cars may be using a universal port that I ran across to connect their radios. PAC has a number of adapters to do things. I would suggest looking there for adapters that may help you. May be a more expensive route but you at-least get the ports you need. Then again if you can get a hold of the dealer shop manual for the car you are looking at it should tell you a lot of what you are wondering. Places like Aldata will sell you a snapshot of the shop manual which you can go through but it is not as nice as the actual shop manual in paper form or on disk. With the shop manual you can find out the specific socket and pins used and be able to order the correct setup from somewhere without a lot of issues. I was able to do this with some of the ports on my vehicles although my CTS is a 2012.

With the shop manual you can also generally look through the troubleshooting tips that shop mechanics use and get some hints on how stuff is supposed to work. It is also likely that if you look through a shop manual it will tell you how to handle the programming. If the OBD connector is firewalled then they should have a programming port elsewhere to connect to each module directly somehow.

#7

I have a service manual in PDF form (given how little it cost on fleabay, it’s almost surely a webrip made by someone with a service manual subscription), unfortunately the particular connector is unobtainium unless you’re GM. (Don’t have the part number here at the moment)

However, it appears that these have been standardized enough by USCAR that Molex STAC64 may be interoperable. https://www.mouser.com/ProductDetail/Molex/34729-0203?qs=1%2FkFHMS5B%2FiH1nOHqH4nlg%3D%3D - I can’t find wire-termination mating connectors, only PCB-termination.

#8

They generally give the name and model number of the connectors and the pins etc… I have been able to locate them that way by doing a google search on them. And if all else fails a lot of the components can be had at a GM dealer. Maybe not 100% but most can. I have done that and rewired stuff or added support for features my vehicles didnt have.