pcmhacking.net

The BDM tools are making a world of difference with recovery on these devices. I got it 99% correct for writing chunks of data to the flash, but was missing a single byte at the end of each chunk which resulted in bricking the ecu (Simple math oversight!).

One thing I am not happy with, is using a nop loop for timing/delays, I have set it up so it does do fairly accurate delays depending how long I am after.. but I would rather use the internal timer which I can calculate exact micro or millisecond delays. Issue I am hitting is the max value is very small, so any overflow results in the timer function I built takes much longer then its suppose to.

The nop loop was accurate enough for what we were doing especially since the packets were small, the struggle got worse once they introduced clock jitter I feel ya bro

The usbjtag guy which produces the recovery tools, is an absolute champion.
Demonstrated to me some advanced features of the software to step through code to help with development, amazing little features that make a devs life alot easier.

He is absolutely down for developing for newer ECUs, so come development again with E98/E92/T87 ect, he can add bdm/jtag support which will be vital for recovery during development.

Using the 'Background Debug Mode' for debugging code, thats not often what its used for

Now why would one use 'Background Debug Mode' for debugging ... That's just crazy man!

antus wrote:Using the 'Background Debug Mode' for debugging code, thats not often what its used for

Here i am thinking using an emulator was smart... nope... why not actually just debug directly on the damn thing!!

Time for an update!
I have not had too much free time on this, but slowly making progress.

Iv noticed if I send frames too fast from the scantool, I miss them in the bootloader. It seems I am able to send frames faster then I can process them in the bootloader.
Im now allocating them directly to ram instantly and freeing the buffer so it can at least capture the next frame while doing initial processing of first message.. this seems to be working alot nicer and not dropping frames.

When I say buffer, I am referring to the 'mailbox' as indicated in the reference manual. Now, this could all be fixed by using more then one mailbox for reading, currently using only 1 for reading and 1 for writing.
I am sure I am overthinking it, but Im not sure how i would work out which frame has been received first, from my understanding the lowest mailbox (ie.. 0) would be filled first and then goes to the next highest ect ect. Now, if I processed mailbox 0.. and declared it as empty and available then moved to processing mailbox 1, would mailbox 0 or mailbox 2 be filled next?

Logic indicates it should go back to the lowest mailbox number, but not too sure. If thats the case, I would need to count which mailbox I am up to when processing otherwise would process new frames before old frames!

Anyways... probably best to figure this out as it can be copied to the E38/E67 and future bootloaders so they never have an overflow issue.

Ive got a box of e38s e67s and other random ecms in my trunk if youbwant more testers

Hi, Mr. Tazzi

I have an ecm E40 Trail Blazer 2007 bricked and e38 Silverado 2011 in the same condition. Do you think with your software Can I unbricked e40 and e38.

I download the software but say win32 aplication not valid. Can work the software in windows xp ?

Thanks in advance

Depends how you bricked them? And also it does not support win XP, since thats 20years old now.