Jump to content

Recommended Posts

Posted

Hi,

I am having issues with a 2021 Silverado 1500 LT 5.3L. The issues I have are Service Power Steering Message, Service ESC Message, No Cruse Control, No rear backup guide lines (even when guide lines are turned on). 

 

Error Codes: 

C1512 Control Module Power Circuit Low Voltage

C0051 Steering Wheel Angle Sensor Signal / Clock Spring

U0415 Invalid Data Received from Electronic Brake Control Module

 

I purchased a new clock spring assuming the steering wheel angle sensor was integrated into it, but I am no longer certain that assumption is correct. I have searched extensively for documentation identifying the exact location of the steering wheel angle sensor on this model truck. On earlier versions it was a standalone sensor. I contacted the dealership, but they were unsure of its location and suggested it may be integrated into the steering column assembly, which I also have not been able to confirm. I have also checked the ground strap that is located behind the passenger wheel and it looks okay. 

 

I am assuming the issue is related to either the clock spring or angle sensor (if I can find out where its actually located). From what I have read the cruise control is disabled when you get ESC error, and I assume the no rear backup guide lines (even when the guidelines are turned on) is related to the truck not able to read what angle the steering wheel is at.

 

Any guidance on this would be greatly appreciated. Thank you

 

Posted

This may not be the issue, but worth checking before you get too deep in the weeds, I'd think:

 

 

Posted
1 hour ago, Gman2500 said:

Hi,

I am having issues with a 2021 Silverado 1500 LT 5.3L. The issues I have are Service Power Steering Message, Service ESC Message, No Cruse Control, No rear backup guide lines (even when guide lines are turned on). 

 

Error Codes: 

C1512 Control Module Power Circuit Low Voltage

C0051 Steering Wheel Angle Sensor Signal / Clock Spring

U0415 Invalid Data Received from Electronic Brake Control Module

 

I purchased a new clock spring assuming the steering wheel angle sensor was integrated into it, but I am no longer certain that assumption is correct. I have searched extensively for documentation identifying the exact location of the steering wheel angle sensor on this model truck. On earlier versions it was a standalone sensor. I contacted the dealership, but they were unsure of its location and suggested it may be integrated into the steering column assembly, which I also have not been able to confirm. I have also checked the ground strap that is located behind the passenger wheel and it looks okay. 

 

I am assuming the issue is related to either the clock spring or angle sensor (if I can find out where its actually located). From what I have read the cruise control is disabled when you get ESC error, and I assume the no rear backup guide lines (even when the guidelines are turned on) is related to the truck not able to read what angle the steering wheel is at.

 

Any guidance on this would be greatly appreciated. Thank you

 

 

 

Steering angle sensor is integral to the steering gear.

 

What was the full code?  Should have a symptom byte at the end of it.  

 

DTC C0051 byte 4B

Steering Wheel Angle Sensor = Not Calibrated

DTC C0051 byte 58

Steering Wheel Angle Sensor = Internal Malfunction

 

I would double check the ground straps as @taze linked to.  Very common of them to go bad and cause steering issues.  

Posted
24 minutes ago, newdude said:

 

 

Steering angle sensor is integral to the steering gear.

 

What was the full code?  Should have a symptom byte at the end of it.  

 

DTC C0051 byte 4B

Steering Wheel Angle Sensor = Not Calibrated

DTC C0051 byte 58

Steering Wheel Angle Sensor = Internal Malfunction

 

I would double check the ground straps as @taze linked to.  Very common of them to go bad and cause steering issues.  

 

Here are the full codes with byte

Bytes:

C1512 Byte 03

C0051 Byte 58

U0415 Byte 00

Posted
2 minutes ago, Gman2500 said:

 

Here are the full codes with byte

Bytes:

C1512 Byte 03

C0051 Byte 58

U0415 Byte 00

 

 

So...

 

I would focus on the first two.  The U0415 likely set because it can't see the steering angle, and its just a loss of communications code for the missing data.

 

The C0051 byte 58 sounds like the main culprit as that is an internal malfunction code for the steering angle sensor

 

Very little testing for that failure other than make sure the connector is installed and seated properly into the power steering control module.  If its good, and everything is clean on the terminals, then its going to need a steering rack. 

 

Before throwing a rack at it, again, just make sure those ground straps are good.  That video in that linked thread like 3rd or 4th post in is a fantastic view of where they are.  

Posted
28 minutes ago, newdude said:

 

 

So...

 

I would focus on the first two.  The U0415 likely set because it can't see the steering angle, and its just a loss of communications code for the missing data.

 

The C0051 byte 58 sounds like the main culprit as that is an internal malfunction code for the steering angle sensor

 

Very little testing for that failure other than make sure the connector is installed and seated properly into the power steering control module.  If its good, and everything is clean on the terminals, then its going to need a steering rack. 

 

Before throwing a rack at it, again, just make sure those ground straps are good.  That video in that linked thread like 3rd or 4th post in is a fantastic view of where they are.  

 

Sounds great, I greatly appreciate your help with this.

 

I just checked the grounds again that South Main Auto showed on his video. Both of them I checked looked good. (Passanger side head to fire wall, and one behind front right wheel) I also checked voltage drop between negative post and frame and don't have any voltage drop.

 

I will check the connection to the power steering control module. If that looks okay then ill throw a rack on it to see if it solves it. 

 

Thanks again for your help

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Latest Articles

  • Posts

    • I hope to high heaven this is wrong. My Chevy farm trucks frame is lasting way longer than a newer Nissan Titan XD I got for a steal, and it only pulls trailers. A decade younger and it's frame is already way rustier than the waxed Chevy I drive across longs and ditches. Also, hasn't Ford been having tones of troubles with rusted frames? 
    • Batteries don’t always show signs of a few years ago my vehicle started fine in the morning and took me to work. After work the battery was completely dead and I needed a jump. No, I didn’t leave anything on and the battery was only a couple months old. It was replaced under warranty. 
    • AFM is confirmed in the Corvette engine, so I'm assuming the higher volume trucks will get it as well
    • If his battery was that bad I would think it would have been showing signs before this that were ignored. Stinks that it happened the way it did in rush hour traffic, but this seems like a pretty fringe scenario. I don't mind it that bad and never turn it off. The only slight annoyance for me is the slight delay between brake to gas, but I have gotten used to it and figure if it can save a little gas why not.
    • That is a good correction. I think “severity” was probably the wrong word for what I meant. What I really mean is closer to event priority, relevance, and actionability — not “this code is severe” or “replace this part.” I agree that a truck can have a lot of trivial or historical communication codes, and if the product starts pushing alerts for every stored or low-value event, people will ignore it very quickly. So the alert logic would need to be filtered. For example, I would not want a random old communication code to generate a push notification by itself. A useful alert would probably need to be based on things like: - new vs historical - active vs stored - repeated vs one-time - duration of the event - whether it happened near the driver-marked symptom - whether it happened together with voltage drop, reset, bus-off, misfire, oil-pressure change, etc. - whether the same pattern repeats under similar conditions So instead of saying “severity,” maybe the product should organize events by affected system and priority. For example: Misfire event: Show misfire counts / roughness first, then fuel trims, RPM/load, DFM/AFM state if available, coolant/oil temp, voltage, and related DTCs. Oil-pressure event: Show oil pressure first, but only in context — RPM, load, oil temperature, coolant temperature, DFM/AFM state if available, voltage, and baseline comparison. Communication event: Show which module/network/message dropped, whether voltage dropped, whether the recorder reset, whether it was active or historical, and whether it repeated. Voltage/reset event: Show battery voltage, crank/wake/sleep state, module reset, communication dropouts, and what came back online first. That also solves the display-order problem you mentioned. The main report should not always show the same fixed list first. It should show the system that appears abnormal first, and then the supporting values for that system. I also agree that the truck already has an oil pressure gauge and MIL. The point would not be to duplicate those. The value would be in showing what else was happening before and after the warning or symptom. For example, if the MIL comes on for a misfire, the truck already told the driver there is a problem. The useful part would be: - which cylinder or bank looked abnormal first - whether it happened after an AFM/DFM transition - whether fuel trims were already moving - whether oil pressure or voltage changed at the same time - whether the same pattern happened previously without a MIL On the OBD port point, I think you may be right for a consumer-facing version. OBD is much easier for the average owner: - easier install - easier removal - inside the cabin - easier phone connection - easier data download - easier to include a pass-through port for another scanner OBD is also the right place for DTCs, freeze frame, VIN, calibration information, Mode 6, and normal scan-tool parameters. The reason I was looking at ECM-side recording is that some events may be gone by the time someone plugs in a scanner, and some powertrain-side network evidence may not be available the same way through the DLC. But I agree that if an OBD-based version can capture enough useful evidence for most owners, that is probably the cleaner consumer product. Maybe the split is: - OBD/DLC version for most consumers - ECM-side version only if it proves it adds evidence that the OBD version cannot get - shop/pro version if deeper powertrain-side event evidence is actually useful So I would not want to force the inline approach if the OBD workflow solves most of the real-world problem. Your last point is probably the key product requirement: the report should be specific to the system showing the abnormality. Not “here are 50 parameters.” More like: “Misfire-related event detected. Here are the misfire/fuel/DFM/context values.” or “Oil-pressure-related event detected. Here is oil pressure compared with RPM/load/temp/baseline.” or “Communication event detected. Here is what dropped, when, and whether voltage/reset happened first.” That is a much better way to think about the report.
  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...