When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Well after spending an hour uploading and writing my last post, I have now successfully recovered the PCM using the APP.
Things I tried:
I first tried to just re OS flash the PCM no dice
I turned off the the pin 19 power for 30 seconds then attempted again. nada
I unplugged my power source and shorted between GND and both +12V tried OS flash. still nothin
The successful attempt still had power on pin 20 (19 was switched off) during the hour I waited to try again, the only thing I did different was try to Clone from .bin and and it was able to communicate and recover.
What I suspect happened was the OBDLink crashed and there was still data in the buffer that wasn't cleared. This has been an ongoing issue with the Obdlink Lx more so then the Mx but they both will experience the issue from time to time. A dead giveaway the issue is with the Obdlink is the power light goes out or becomes dim and may be blinking or flashing quickly. Another sign is the HOST light on the device will turn solid red...or rapidly flash even if the app is closed.
If the Obdlink isn't exhibiting any of these behaviors there are a couple of things the App will do when its first started. When you connect to the app over BT it will configured the Obdlink, if the Obdlink doesn't respond to the setup commands with the expected answers it will give a message that there was an error. It will catch device faults most of the time but I've run into case that the Obdlink says it rebooted and then was setup correctly when its still in an error state.
Once the device is setup and you select what type of flash you would like to do the app will "Ping" the pcm to see if there is a flash kernel currently running on it...for example the app crashed while it was flashing and you are not reopening the app. If there is a flash kernel found it won't matter what type of flash you select the apps going to flash the OS+Cal regardless since it has no way of knowing what type of flash was being performed when the app crashed.
If there is no flash kernel found the app will then look for a recovery mode message on the data bus. There are 3 possible messages. One indicates that the calibration data is either missing/damaged/incomplete. The other two mean there is an issue with the OS it self or something in the boot sector doesn't match the OS/Cal data. In any of these case's the app will flash a message on the bottom of the screen letting you know the PCM is in recovery mode. If its in a Cal data recovery mode it will let you flash just the calibration. Other wise it will flash OS+Cal for either of the other 2 recovery modes.
At this point if there is no flash kernel found and no recovery mode message it looks to see if it found an OS ID Number, if it did then it will let you continue with the selected flash type, if it can't find an OS ID number meaning it came back as all F's or 0's it will bring up a message telling you the PCM OS is likely damaged and give you the option to continue or start a recovery mode flash. In this case recovery mode means the PCM may not behave as it should and the app will ignore any odd response from the PCM and try to forcefully load the flash kernel. anyways.
Now in regards to your post knowing what message the app was picking up or what point the app wasn't able to get past prior to being able to recover the pcm would be the only way I can tell you why it didn't recover it right off the bat. I will look into locking out the Camera function during a flash but that's getting into system permissions that Android is now blocking access to so it may not be even be possible at this point.
In any case if your in a hurry to flash the PCM and its had a flash fail and there is no kernel running in the PCM....the PCM won't talk/answer the app etc you can always resort to the method I cover in the video below. During an OS flash or Cloning as long as the app has written at least 8 blocks successfully there is enough data that's been written to the flash chip that is can be recovered...but you may need to ground the pin in the video to get the PCM talking again.
In some cases you can still recover the pcm with even less then 8 blocks flashed provided your on a bench harness, it may take 2....3....maybe even 15 or more tries but I have been able to recover a pcm with only 2 blocks written during an OS flash once I forced the PCM into recover mode.
You should pay attention to the sequence of toast notification near the bottom of the screen when selecting a flash type. Also notice I select calibration only flash and it detects the recovery mode and automatically changes the flash type to an OS+ Cal flash.
In regards to the Read app it's amazing it still works at all given the API changes Android has made since I released the app. It's an Alpha version for a reason, I gave the app a lot of room for errors with out breaking to speed up testing so I could collect the data I needed to start working on the write side of the app since that's what was going to be the hard part.
Once I satisfied with a stand alone version of the the write side of the app I'll be revisiting the read version and combining both parts of the app into a single app that does both read and write.
OK I spent a few hours this evening to re-visit this.
I attempted to flash using a Samsung Tab A running android 7.1.1 and kept having issues writing, I would go into more depth but I don't think the issues were the APP.
I decided to make a new bench harness even though my ugly abomination has flashed many LS1B, LB7, LLY, controllers with no issue using EFI. The new harness has no splices between the obd2 "port" and the PCM on the VPW wire. I have no issues using the Samsung Tab A to flash anymore.
I am going to try taking multiple pics with my phone again to figure out if it was actually the mess I previously called a "bench harness"
once my daughter goes to sleep I am going to steel her tablet and try it also. The new bench harness built from stuff laying around and new properly crimped Metripack 150 pins instead of some cluster pigtails scabbed in. Success with a Galaxy Tab A! No odd issues but is slower than my LG G5 phone
OK I spent a few hours this evening to re-visit this.
I attempted to flash using a Samsung Tab A running android 7.1.1 and kept having issues writing, I would go into more depth but I don't think the issues were the APP.
I decided to make a new bench harness even though my ugly abomination has flashed many LS1B, LB7, LLY, controllers with no issue using EFI. The new harness has no splices between the obd2 "port" and the PCM on the VPW wire. I have no issues using the Samsung Tab A to flash anymore.
I am going to try taking multiple pics with my phone again to figure out if it was actually the mess I previously called a "bench harness"
once my daughter goes to sleep I am going to steel her tablet and try it also.
Success with a Galaxy Tab A! No odd issues but is slower than my LG G5 phone
Odd that the wiring made a difference, NSFW has run into similar issues with the Allpro USB on his bench harness. For what ever reason he HAS to use a Y cable for his Allpro to work. I guess it just goes to prove that sometimes its the stupid little things that get over looked and can cause the most headaches.
As you found out the app is device dependent for speed. It seems most noticeable while calculating the blocks to write once it loads the bin file but does also impact the flash speed itself. I tried to narrow it down to CPU or BT speed where it was affected during the write process but was never able to pinpoint the issue there. This was one of the biggest reasons I had to block versions of Android below 6.0, devices where too hit or miss with the speed and it would lead to the app missing a reply from the PCM or the BT buffer would mix bytes up...maybe the buffer wasn't large enough?
I would be curious to know what the time difference was between the Tablet and your phone. I know from a Samsung J3($35 prepay phone) to a Note 9 there's over a 2 minute difference flashing just the calibration part of the bin file.
I will time them for you tomorrow. I noticed the largest difference was when it was calculating also.
As far as the harness I have no idea what part of it was causing the issue, but even my phone is more stable with the new harness. I tried the other tablet but is was running Android 5 something and there are no updates for it. I really thought the Tab A was just too slow to run your app it seemed like it was missing replies because it would start to write and then it would just stop during the first 2 or 3 blocks of what I am guessing is the boot loader. (before it would say erasing..)
With the new cable I was able to take multiple photos with my phone and even record video while the app was flashing in the background, the OS flash went through without a hitch.
I will time them for you tomorrow. I noticed the largest difference was when it was calculating also.
As far as the harness I have no idea what part of it was causing the issue, but even my phone is more stable with the new harness. I tried the other tablet but is was running Android 5 something and there are no updates for it. I really thought the Tab A was just too slow to run your app it seemed like it was missing replies because it would start to write and then it would just stop during the first 2 or 3 blocks of what I am guessing is the boot loader. (before it would say erasing..)
With the new cable I was able to take multiple photos with my phone and even record video while the app was flashing in the background, the OS flash went through without a hitch.
Awesome, I'm glad to hear this. While I don't recommend doing any of those things while flashing I did expect people to use their phone for other things while the flash was in progress and tried to make sure I had covered everything. Taking burst photos's was actually something I didn't account for and I don't think anyone testing the app tried anything like that so I was a bit nervous but I'm glad this turned out to be an issue that wasn't related to the app
I had a chance to play with the latest version of the Android app yesterday. I did an OS flash to my spare 0411 initially and then a calibration update. The app did exactly what I asked it to do, no errors, no drama. The interface walks you through every step very clearly. Awesome software! I've played with the OBD1 stuff for a number of years but this was my first successful flash of an OBD2 PCM.....very exciting moment! And this happened using my Android tablet, who would have thunk this would be possible a year ago? This changes everything for someone like me who is on a limited budget. Can't wait until spring gets here and I get my car back on the road!!!
Pete, thank you for the hard work and persistence to get the app to this point! Amazing stuff! What's left to do?
The greatly increased user base testing the write side of the app is well under way, a couple of more bugs have been found that I'm working on getting taken care of now......but while I was waiting for feed back on any issues I decided to start working on a face lift for the app as well as some merging of older apps
Not exactly sure what you mean by "Dial" back to your home computer. The phones more then capable of recording a data log and saving it as some type of file. The possible options would be email the log and view it either in a spread sheet or possibly some other type of existing program that would make the data easier to read though.
3)What format should the log be in and what would the preferred method of viewing it be? Using CSV format would be the simplest and likely the fastest method.
Or maybe just standardize the log format to work in tuner pro RT since it works.... even if it's old.
Hi all,
Pete, have you had any luck getting an Android Device to create a log file that can be "played back" in Tuner Pro RT?
Nice touch pete, also like your music selection lol. I can't recall if the vid like the latest one you uploaded are via a bench test with a pcm or via on an actual vehicle then with turn key to ignition or not? I am currently subscribed to your channel and i have scene you upload vids of calibrated various dash to the ls1 pcm which is awesome btw.
Nice touch pete, also like your music selection lol. I can't recall if the vid like the latest one you uploaded are via a bench test with a pcm or via on an actual vehicle then with turn key to ignition or not? I am currently subscribed to your channel and i have scene you upload vids of calibrated various dash to the ls1 pcm which is awesome btw.
Most of my Android stuff is done on a bench this time of year since I live in Michigan and work on this at like midnight most of the time so its fricking COLD outside.
My bench is more then what most would call normal though lol. I have several clusters, Bcm's, SIR modules etc I can enable on my bench to simulate the normal chatter found in a vehicle.
I have a silly question. I have the read only version, and was wondering where the read binary file is stored and in what format? All I was able to find was a Last_Pcm_Read_Full_Log.txt file. Seems to have all the hex data in it, but am not sure if I can work with it using Tunerpro.
Another note: I used the MX+ with it, and always glitches a read vin, calibration, and O.S. identification on the 1st read. After that, retrying meets with a successful read. No matter how long I wait for the pcm, MX+, or software, the result is the same. Kind of vexing, but workable. I wait at least 30 seconds KOEO before connecting the bluetooth unit, also. Not sure if it is a default protocol thing or not.
I would like to request a changeable file storage location so anyone could swap OTG flash drives between machines for editing. Just a thought, probably redundant.
