-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flash non-ECU hardware on the benchtop? #112
Comments
Flashing non-ECU hardware:
2013 is also a bit old for UDS - does this module talk UDS or TP2.0? If TP2.0, then no support yet. However, there's another wrench: if your module is not communicating over OBD / CAN, then you probably shouldn't bother - reflashing over UDS is probably not possible; after all, UDS reflashing requires quite strictly that the module be talking over UDS. In this case you need a lower-level recovery - if it has a supplier bootloader, going in through that, or opening the module and reflashing it via hardware (direct chip off flash and/or some kind of bootstrap loader). I can't tell what the commercial tool in that video is doing directly, but based on the logging output it seems (???) to be going over the diagnostic service and it's unclear to me that it could recover a brick which is not responding, unless it's using some custom backdoor "knock" implemented in the module. |
Thanks much for the thoughtful response. I think BCM uses UDS, as there are many UDS modules in the vehicle. I think it is possible and maybe even likely that the BCM CANbus interface is sort-of bricked but with some limited functionality that allows it to accept certain commands related to flashing and thereby restoring full functionality. Unsure whether there is any port-knocking requirement to get in. All the uncertainty contributes to my reluctance to buy a $700 tool. I have no skill in the area of parsing frf files and generating SA2 scripts. The automation idea seems very good, @ConnorHowell. A little background: The bricked state of the BCM is speculated to have been caused by some phantom error signal causing a safety shutdown/lockdown of sorts for the hybrid battery. E.g. a stray airbag activation signal indicating a collision, although there never was any collision. When the regular 12V battery is low, lots of spurious error signals are generated, in my experience. The supplier of the BCM is Sanyo. I have not been able to find any schematics or documentation. Unaware of low level recovery mechanisms or boot loader. There are two PCBs and 100s of inputs to the controller, mostly from the battery side (cell monitoring stuff). PCB model numbers for reference (in case anyone know anything about Sanyo stuff) Sanyo 2RR4B14A69501 That's what I know, I'll just leave it here in case anyone happens to have some additional insights or might find it useful. |
I'll add a little more information that may be relevant as to whether VW_flash might be able to write to my BCM module: Here is a picture of the flash interface internally on the board, with pins marked (GND, TXD, RXD, RST, PDX, VCC) from top to bottom. Is VW_Flash capable of talking to this interface, or are there other tools I should be considering? Correction: The above is an UART/serial interface. I hooked it up to a usb2serial device, but was never able to see any signal coming back out of the interface. It was a black hole. |
Out of scope. VW_Flash is for flashing VW control modules over UDS. We might add TP2.0 or KWP support in the far future. But direct hardware programming interfaces are device specific and demand device specific code (in many cases, just a generic programming tool for the MCU used on the device will work, depending on if it has protection enabled). |
I have found out that the CANbus is alive after all. By disconnecting BCM pin F8 from Vdd=12V, the BCM sends out about 4 seconds of CANbus signals, followed by 4 seconds of constant voltage, before going to 0 volts again. Repeated connects of F8 to Vdd then float yields the same behavior. So, there is a hope that VW_flash can do the job, but I would have to learn some stuff about module scripts + SA2, and figure out the flash layout. I'll report back if any progress made, in case might be useful for other people. |
My dongle is arriving today, so now I am trying to learn how to write a module file. I am planning to call it lib/modules/FL_5C6915182___0601.py. Q1: To generate the module file, is all the necessary info present in the XML metadata that is part of the FL_5C6915182___0601.odx file? Q2: It looks to me like trying to mimic dq250mqb.py is a reasonable starting point for FL_5C6915182___0601.py. The problem is to understand how the XML values translate into the module file. But I can't find an .frf file for dq250 (to see how the parameter values in dq250mqb.py were derived). All I can find is a file called KD_DQ250_C3_05_002_sw.sgo, a binary file. If I knew how to make an .odx from from an .sgo I might be able to do something. Am I going in the right direction here? Did I overlook some documentation that explains how to generate the a lib/modules file? For reference, here is the metadata from the .odx file: FL_5C6915182___0601.odx.metadata.txt Sizes of the image files
|
I wrote a small perl script to extract the metadata and count the size of the data fields (as a sanity check). Look for the patterns @@@@@@@ to see where the original data was:
Here's the metadata as extracted by the above script:
|
Can VW_Flash be used to flash non-ECU hardware on the benchtop? In particular I want to flash the file FL_5C6915182___0601.frf into the 5C6915182B battery control module of a 2013 hybrid vw, via CANbus.
Basically what I am trying to do is to replicate the setup shown at the beginning of this video, but without spending $700 on a commercial tool and subscriptions.
https://www.youtube.com/watch?v=ti-m3lo53O4
The plan is to attempt benchtop flash operation (I think), because the BCM CANbus is no comm as seen from the obd2 connector, but I could also try via obd2 connector (incoming CANbus signals to BCM are clean, the unit just does not talk back, but that may be just because the BCM is bricked, which is what I am trying to fix in the first place).
If the above sounds plausible, is Tactrix OpenPort 2.0 J2534 a good choice for talking to CANbus directly?`
The text was updated successfully, but these errors were encountered: