I had to drag out a pretty old version of LS Droid and its a read-only Alpha version but I needed one that still had Elm Command support to do some early testing with Ls Droid since the firmware for the tool I've been working on isn't finished quite yet but it had all the necessary Elm commands working to test out reading with.

What your about to see is gonna blow your mind......this is the ACTUAL speed the tool I've been developing with Envyous Customs using Elm commands. This would be VERY comparable to the Allpro and uses the exact same commands, the difference is the quality of the hardware and the design of the tools firmware that set it apart from the Allpro.

 

Great to see the progress.
How close would you say you are to Releasing the new tool?

I have a question regarding recovery of a bricked PCM. You showed an option to recover a Bricked PCM in Post #309 and mentioned it in Post #296.

I have some P59 PCM's that failed during a flash. I suspect it happened due to a low voltage issues with the previous owner during the flash. I was quoted an obscene amount to have them recovered. Lets face it, for $50 I can get replacements all day long at the local wrecking yard. But If I can recover them Like you showed us, I sure would like to try.

Are there any tips to be successful when using a commercial software?
Are you essentially doing a full flash?
Have you tried this process when they have COS?

 

There will not be any ADX,, several people including myself suspect that Tuner Pro may be what lead to premature failure of the Allpro's. Tuner pro is also about as difficult as it gets to create an accurate data display and there would not have been any simple way for an end user to make any changes to what was displayed/logged. Rather then trying to work with a very ridged logging tool that in the end would still be far from ideal; we decided it would be more beneficial to add compatibility for programs like ScanXL, Torq and Software on Elmstreet. They all do a much better job at displaying data and creating useful data logs then Tuner Pro could even dream of.


As far as I know, no one has done any development for V6 XDF's. Nothing from the LS computers can be applied towards a V6 XDF(much different file structure) so who ever decides to create the first one is going to have a lot of work ahead of them.

 

If I tried to give a specific time frame I'd likely be sticking my foot in my mouth. We honestly expected to have it done by now, but we are not going to move to a production design until we're happy the hardware is rock solid and the firmware works exactly like it should with all protocols it supports. At this point I'd say no sooner then the middle of July until anything could be ready for sale, production and shipping will take almost 4 weeks once were ready to have the first batch made.


It's not specific to the OS, so yes.... a COS can still be recovered depending on what happened. The type of flash required depends on what state the PCM is left in, On the LS Pcm's there are 3 recovery modes and only 2 of them have guaranteed recovery ability, the 3rd is a craps shoot if its going to be recoverable.
Commercial tools typically only offer 1 form of recovery mode and its a full write. How successful it is will depend on what tool your using, what recovery mode the pcm is in and how much data was correctly written to the PCM.

In a LOT of cases low voltage during a flash will end up permanently damaging the flash chip, it can also cause the flash kernel to do things it shouldn't. A common one I've seen is where the flash kernel attempts to restart the flash and erases the entire flash chip as voltage drops off right before the PCM would shut down. To determine if the Pcm's even have a chance at recovery you'll need a tool you can "watch" the data for for activity. a cheap Elm327 is capable of this, all you need to do is see if the pcm's talking. If the bus is silent it's possible the PCM is unable to boot, I have a number of videos explaining/showing how to force boot the pcm. If after jumping the pin the PCM still won't start talking then there is no chance of recovery over the data bus. If the PCM does start talking then its very possible it could still be recovered.

 

Hi all,
Pete, thanks for the reply...

SO what you are saying is that we will be better off NOT using Tuner Pro's Data logging ability;
but instead using another app such as SOE or Torque, THEN using the log that is created to edit the bin in TP?

Sounds like a plan, especially given that I have all 3 of the apps you mention.

Would I be better off using my BAFX ELM327 to datalog, and using another tool (such as the one you and Tazzi(?) are creating) for Reading and Writing the PCM?

Guess I'll be waiting for an XDF for my LA1 3400 V6 before I can tune it! Still have 2 0411 PCM's out of 4.3l V6 equipped Blazers to play with!

Mike

 

Pete,
Are there any updates on the new tool from Envyous Customs?

Thanks to you and all who are involved in this project, this is a very interesting development for P01 and P59 users. Can't wait to see where this goes.

 

The tool is actually a joint venture with Envyous Customs, while they do develop and sell tools for use with their own software what we are creating goes well beyond what they typically make and the firmware has taken more time to develop then initially expected.

What we have working so far is the byte based protocol, this would be a protocol similar to what the AVT-852 would use. This is working over USB and over Bluetooth.

Elm327 protocol is lets say about 90-95% complete, reverse engineering how each AT command worked has proven to be a lot more difficult then it might seem. This command set is also working over USB and Bluetooth.

Enhanced "Elm Like" protocol, this is how we feel the Elm command set should have been implemented and greatly expand the possibility beyond what actual Elm commands are capable of. Also working over USB and Bluetooth.

Some notable apps we have the tool working with include Torq and Dash commander for Android using Bluetooth, Scan XL and Software On Elmstreet over either USB or Bluetooth on a PC. The refresh rate in all the programs is significantly faster then any other tool we have tested regardless if we are using USB or Bluetooth.

The delay releasing the tool has been due to a lack of a secure and reliable way to field update the firmware at this time. Developing a way to over come that limitation of the processor will take a significant amount of time, time that we felt would be more valuable spent completing the command set's rather then shipping a tool that had only partially complete firmware and promising an update at some point in the future. That's a road a lot of projects go down and it never seems to end well. We felt is was best to ship the tool with the firmware 100% completed and that we are able to verify works correctly the first time.

 

Wow, thanks for the detailed explanation! I totally understand that this sort of thing takes time and that is why you won't promise release dates for things.

Am I safe to assume that any further updates on the app or the tool developed WITH Envyous Customs will be posted here, and therefore just sit tight and stay tuned?

Thank you again in advance for your contribution to the community and any replies.

 

Any insight here? Have I bricked my PCM the first time I tried it lol.

Sounds like something I'd do.

 

What exactly did you do?

 

Read the Bin with Lsdroid, transfered it to PC, changed the VATs to off in TunerPro, and attempted to reflash it with LSDROID.

Now it can't be read, by Torque, LsDroid, PCMhammer, or HpTuners.

I was able to clone the bin to another 411 I have,so no huge loss, but it was definitely completely unrecoverable.

 

It is not possible to "brick" a P01 or P59 no matter how "badly" the flash goes if all your doing is flashing Calibration data.

However it IS possible the PCM may be stuck in a boot loop and is unable to respond to any commands but that is much different then a bricked PCM and I have a very simple method to bring the PCM out of a boot loop.

So my first question would be, what type of flash did you do when the PCM became unresponsive? Did the app tell you the flash was complete or did the flash die while it was still writing the data to the pcm?

 

I received this message, I started recovery mode, and it went into the PCM timeout like a loop.

 

Well now...... this is starting to make sense. Any of the Alpha version....were to be used with EXTREME caution and could exhibit unpredictable behavior when used in a vehicle that had other modules present on the data bus. There was a massive rework between the Alpha and the first release of the Beta version of the app. There is also a note on the Alpha 6.1.1 in the Beta version that the Alpha was not fit for use in a vehicle unless it was a swapped vehicle. Maybe I should have spelled it out a bit clearer and just said that no other modules should be present on the data bus.

You also did not answer my question as to what type of flash you were performing, if all you did was turn off VATS then it should have been a calibration only flash. Looking at your last screen shot I suspect you were doing an OS+Cal flash and is why it prompted recovery when the flash was interrupted by the BCM that had not gone into flash mode as it was commanded. Yes.....the BCM is the reason the flash was interrupted and I've highlighted the BCM being picked up during the flash in your screen shot.





In this case what happened is a message was sent to the PCM and either there was a data collision(where 2 devices sent a message at the exact same time and the messages attempt to over write each other) or the OBDLink picked up a random message from the BCM that was talking on the data bus when it should have been dormant. This is one of the biggest issues using an Elm type device for flashing, it is only able to return messages for a couple hundred milliseconds...or until a response is found. In this case the device picked up the next message that came up on the bus and it wasn't from the PCM. It's very likely the PCM did in fact respond but the OBDLink had already closed the port and sent the message it picked up(from the BCM) back to the app so the PCM's reply was never seen. This is the reason why the app was not suitable for use in a vehicle with other modules present on the data bus.

At this point the flash had already gone south and was in BIG trouble BUT the flash kernel was still running in the PCM's RAM and was very much still recoverable but only so long as the key was not turned off and you were able to get messages past the BCM talking. It's possible the BCM had crashed the flash kernel if there were multiple data collisions during a block write where what ever message the BCM was sending was mixed in with the bin data the OBDLink was sending.... but it's unlikely. What should have been done was pull the BCM fuse so it would have shut up and not interrupted a recovery flash. Again I have no idea how far into the flash it was but looking at the screen shot it looks like it was interpreted VERY early in the flash. Had it been able to flash a dozen or slow blocks for an OS+Cal or Cloning the PCM would have still been recoverable even after turning the key off and unhooking the battery. I've done it hundreds of times developing these flash kernels and I test it every time before releasing a new version of the app. If the first 4K bytes of an OS or Clone are flashed it doesn't matter what happens it can be recovered, it may get stuck in a boot loop but thats easy enough to pull the PCM back out of. And if your only flashing calibration data, well you don't even need to write anything to be able to recover the PCM, calibration data isn't necessary for the PCM to boot.

While it's very unlikely there was enough data flashed on the PCM and the boot sector is probably only partially written, have you tried hooking it up on a bench harness and seeing if it will respond to a Beta version of LS Droid?

Have you flashed anything with the App since this PCM flash failed? There are logs the app creates for trouble shooting that would have exact details as to what was flashed and what caused the interruption.....however its over written every time you flash a PCM so if you flashed anything else that log is now gone.

 

Initially I tried Calibration Only with the Beta, it was in a vehicle, although not a daily vehicle or anything, so that was my fault for not reading more carefully.

I was able to reflash with HP Tuners the first time and it worked again, tried to reflash with LSDroid and it crashed again, this time unrecoverably.

I will attempt a bench flash now and report back. Obviously, all my future attempts will be bench flashes lol, live and learn I guess.

 

Coming to your favorite Android powered device very soon......

 

How's version 0.2.7 coming along? Not that you aren't busy enough as it is. I am also ready to post stock binaries to the repository as I obtain them. (only have 2 for now)

 

So what is this very simple method you speak of @PeteS160?

 

 

Hi all.

At present the ONLY supported devices are the 2 OBDLink Bluetooth devices: The LX and MX.
They are working on a new interface that is going to be MUCH faster than either of those two as it supports the 4x mode.

From MY own research, the main reason for the lack of support for USB devices with the Android OS is the lack of Native Driver support for ANYTHING that does NOT use an FTDI chip,
If anyone has TRIED a USB interface with one of these chips please let us know if it worked!
Just checked on the AVT website and it instructs people to get the Drivers directly from the FTDI website!
SO..,
it MAY work!
NO Guarantees though.
May as well give it a try.

Mike S.