[Podunk]

Not sure what is going on with MHD, but pretty sure it just bricked my DME, i went to flash a custom tune that i corrected an error on in tunerpro and saved the new bin, downloaded it, flashed back stage 0 then went to reflash the custom tune to make sure everything took fully got to 51% and then "IO_PathNotFound/ etc etc/android/etc/etc /<tune file>
i got option to "retry from failed flash" and selected it.. the 10 minutes timer dropped to 1 minute, got to 100% reset everythign said all good, then.. no DME contact.. protools shows no DME, MHD refuses to contact the DME, there is just NOTHING from this DME now.

SO.. anyone have a recommendation for a good MSD81 recovery service to get this back to a stock tune and then maybe try to flash a OTS map to get MHD on the DME THEN flash my custom tune withotu the failure.. otherwqise i'm seriously considering going standalone like a Syvecs..

[CarAbuser]

Do you have a laptop with Tool32 or INPA installed?

Extremely unlikley that MHD hard bricked the DME as they have good safeties in place during the write. But it is possible to soft brick when writing their MHD+ bin files from Github.

If you can use Tool32 and get any sort of successful communication when running the ident job or fs_lesen then you are ok and can recover it. Otherwise it's a new DME that is needed.

Syvecs would be a waste of time though. You'll spend thousands getting it set up and it'll drive like crap.

[Podunk]

Originally Posted by CarAbuser

Do you have a laptop with Tool32 or INPA installed?

Extremely unlikley that MHD hard bricked the DME as they have good safeties in place during the write. But it is possible to soft brick when writing their MHD+ bin files from Github.

If you can use Tool32 and get any sort of successful communication when running the ident job or fs_lesen then you are ok and can recover it. Otherwise it's a new DME that is needed.

Syvecs would be a waste of time though. You'll spend thousands getting it set up and it'll drive like crap.

no coms on Tool 32 at all. wont' even run the job, jusdt get initialization error

i'm sending it to ECU pros, figure it will need the case cracked and pogo pins on the board to reload the infineon tricore processor boot sector.

[CarAbuser]

Originally Posted by Podunk

no coms on Tool 32 at all. wont' even run the job, jusdt get initialization error

i'm sending it to ECU pros, figure it will need the case cracked and pogo pins on the board to reload the infineon tricore processor boot sector.

Sometimes with soft bricks the logic gets stuck in a boot loop. If you can spam a job like fs_lesen and get a result 1/20 times then it can be recovered.

Initialisation error usually means there is a config or cable issue. If you try an ident on the TCU or DSC module do you get a response?

With the MSDx I believe they can only gain access to the Tricore if it is healthy. I think if it really is hard bricked then they wont be able to get the keys to enter "boot mode".

[Podunk]

Originally Posted by CarAbuser

Sometimes with soft bricks the logic gets stuck in a boot loop. If you can spam a job like fs_lesen and get a result 1/20 times then it can be recovered.

Initialisation error usually means there is a config or cable issue. If you try an ident on the TCU or DSC module do you get a response?

With the MSDx I believe they can only gain access to the Tricore if it is healthy. I think if it really is hard bricked then they wont be able to get the keys to enter "boot mode".

yeah i don't think the full hardware would be bricked, since the MSD81 is pretty stout from what i've read, however according to my reading, it is possible it is stuck in a boot loop and would require a board based over ride like you get from a Alientech KESS3, Hexprog ETC.

all other modules connected and populated in Protool just fine, just couldn't get DME to say "hello" at all

i also dont' have a bench setup to test off car by powering the wake up pin power pin Ground and CAN PT pins, i also don't have a crimper, the pins, and the time/patience to make a bench OBD box ATM since i'm having to re-orient myself back to night shift after my week and a half vacation.

i beleive NFS was able to pull soem kind of HEX data off it, but not fully communicate with it.

i wanted to try and get the BMW coding tools to work and setup the files fully but missing MSCOMCTL.OCX and even the windows download for VB 6.0 won't put it on my machine for some stupid reason

Another issue i found was the ZUSB files none of them matched the usual suspects for MSD81 N54 numbering sequence. had the right .prg files though.. but not a single .0pa and .0da file matched the numbering sequence from what i was able to find for V69 MSD80/81 Datens, so F me for daten files.

either way DME is in a box on a ups truck now with CAS3 and FOB. and as much as i'd like to learn this particular stuff more and make sure i have all the right files and tool32 project/item requests, it's such distorted, tribal, debased knowledge it's infuriating. especially when you have to go to multiple different sites to even attempt to get the full picture and knowledge and even then it's with a grain of salt cause it could be false information or expired information.

all this to say i TRIED to get this thing opened up for recovery from like 10 AM till almost sundown and ran in circles trying to find all the stuff and project requests all cause BMW has a stick up their ass and so does autotuner/alientech/etc for the info and files needed and MEGA keeps kicking files offline too so F them as well.

[CarAbuser]

I appreciate the struggle. The BMW coding tools are bootlegged so nobody is going to host them and maintain them as they'll just end up with a take-down request from Softing/BMW.

I'm very curious to see if they manage to recover the DME for you. My understanding of the process needed to manually write to the internal tricore memory is that the need to be able to communicate with it first to retrieve some information from the memory and then send that to a remote server to calculate the password for the tricore that allows writing in a boot loader type mode.

If they try and fail to recover it, then send me a PM. I had the same issue as you when writing bin files from the MHD GitHub to one of my bench DMEs. The DME would end up stuck in a boot loop where it would response to KWP requests for around 2 seconds, then lock up and reboot.

I added a function into my app to recover in those circumstances. It's not in the pubic release yet but I can add you to the beta test for it. You just open the app and hit recover and it will attempt to barrage the DME with KWP erase requests. Once the data is erased the DME can be flashed again as normal using whichever app you want.

Most tools fail because they take too long talking to the DME before it reboots again.

It's free so worth a shot if the bench recovery fails.

[Podunk]

Originally Posted by CarAbuser

I appreciate the struggle. The BMW coding tools are bootlegged so nobody is going to host them and maintain them as they'll just end up with a take-down request from Softing/BMW.

I'm very curious to see if they manage to recover the DME for you. My understanding of the process needed to manually write to the internal tricore memory is that the need to be able to communicate with it first to retrieve some information from the memory and then send that to a remote server to calculate the password for the tricore that allows writing in a boot loader type mode.

If they try and fail to recover it, then send me a PM. I had the same issue as you when writing bin files from the MHD GitHub to one of my bench DMEs. The DME would end up stuck in a boot loop where it would response to KWP requests for around 2 seconds, then lock up and reboot.

I added a function into my app to recover in those circumstances. It's not in the pubic release yet but I can add you to the beta test for it. You just open the app and hit recover and it will attempt to barrage the DME with KWP erase requests. Once the data is erased the DME can be flashed again as normal using whichever app you want.

Most tools fail because they take too long talking to the DME before it reboots again.

It's free so worth a shot if the bench recovery fails.

thanks for the offer and i will likely send you a DM if bench recovery fails

hopefully the bootloader isn't totally cucked ( i don't think it would be, but who knows)

and yeah USA right to repair needs friggin teeth the current iteration is useless, as we see with john deere, and current car manufacturer methodologies used to squash it in order to force the trade in/trash cycle while also removing the primary aspect of purchase: Ownership.

i don't know where the timeline went wrong but someone make a time machine please to fix it.