Tazzi wrote:
It will never work with a bad checksum. But doing a calibration only flash is MUCH faster.
Update the programming to do calibration only, and also to keep retrying to flash when its incorrect.
When it detects its incorrect, you can automated the software to simply increase the checksum byte by 1 and reflash. Eventually you will find the value.
OK been working on this.
Cal only reflash is about 12-15 seconds. so at this rate, it'll take only a max of 2043 years to solve.(4 byte problems)
I'm waiting on another EBCM to come in from ebay that I can setup on the bench for the purposes of wearing out its flash brute forcing.
In the meantime, I'm trying to determine ways to reduce the amount of trys. My plan right now is to increment the address that I think I need to modify by 1. Then brute force the CS. Hopefully this won't be a super huge jump in value, and when it solves I can try it in the truck with my scan tool I wrote to see if the right variable has changed. So it'll tell me if I'm correct on the location...and hopefully tell me more about the CS by being so close to the original flash.
I'm still not sure if everything is 16-bit or 32-bit. I doubt it's 8-bit by the amount of data crunching that needs to happen. I wrote a python script to sum all the binaries I have so I can compare the binary sum(without the CS(s) added in) and the checksums, in both 16-bit and 32-bit big endian. A few different clues have me fairly sure it's big endian. I was hoping to find a trend or something, but I didn't. Attached a pic of the OS's and their sums/checksums. The peach color is two OSs that are VERY similar; their sums are close but checksums very different. OS 2324 and 2327 have very close hex sums in 16 bit, and again their checksums are very far apart(about 726 years@15 seconds). The yellow OS is the one I need.
Also I tried to write infineon to get a data sheet on the Orion D2 chip but to no avail. It is not available without signing an NDA and having a company.
any ideas? Thanks
