Changes

#*$31 eraseMemory##**What is says. Deletes the entire CAL area so the whole block is grey to represent this.#*$34 requestDownload##**Ask to initiate a data transfer#*$36 requestDownload##**Actually move the bytes from the flash tool to the ECU#*$37 requestTransferExit##**Terminate the transfer after all bytes have been copied over. If you look the picture now, you’ll see that the blue data transferred doesn’t quite fill up the flash block. There is still a little bit of grey space remaining. That’s intentional, the flash block really is bigger than the blue CAL data. That little bit of spare space is used in the next steps.#*$31 checkMemory##**“Performs checks to write security keys for reprogrammed components. Security keys in flash memory to secure the reprogramming session if checksum and coherence are fitting. They are tested at start-up of the ECU. If one of the Security Keys is not valid, the applicative software is inhibited and there is no system operation”. So that’s the OKAY bytes written in green. NB – it’s a routine in the ECU that writes these OKAY bytes onto the flash after all checks are successful (checkMemory). Once the block has got the OKAY bytes, the block is allowed to be used. The OKAY bytes are written into the flash just after the blue data. If you look at a full 4MB file, you can see the OKAY bytes yourself just after the end of the CAL data. If there’s something invalid about the CAL data, then the check won’t write the OKAY bytes and the block is invalid…