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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
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!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Depends how you bricked them? And also it does not support win XP, since thats 20years old now.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726