| Message |
to input the addresses in order to download and create a bin file. Is there no automatic way that the software can download the data and create a bin file? For one thing, those start and stop addresses are the locations in a bin file as seen with a hex editor. Not the addresses you need to access from the ecu to create a bin file. When you download the data from the ecu you are getting it from the micro. You are not accessing the eprom (impossible). You would have to know what the micro's addresses are in order to get them. It makes sense to see the info displayed in the error message. Let me explain. The address for the first byte in the eprom as how you would edit it in an eprom burner or by editing a bin file which you will store in an eprom is "0000". Once the eprom data (think of the eprom as a hard drive that loads software into the micro) is loaded into the micro, the data in address "0000" of the eprom as viewed with a hex editor is now in address 8000 of the ecu micro. In order to get data from the micro to create a bin file you have to address 8000 as the starting address. The error message is due to not being able to read that part of the micro. Let me explain the error message. Expected 36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03....ect. 1. With a start address of 0000 you are starting a byte retrieval at address 0000 of the micro which is an unreadable part of the micro. 2. What was expected is correct by the error message. The first number 36 is the inverted command for initializing a read cycle. It is always returned in the data. 3. The next expected number is 0. This represents the first part of the address you requested data from ((00)00). 4. The next expected number is 0. This represents the second part of the address you requested data from (00(00)). Now you see it repeating because the software takes over from the start address. Like this...
36, (0, 0,) Your start.
36, (00, 01) The next byte the software tries to get.
36, (00, 02) The next byte the software tries to get and so on. The software will request a maximum of 8 bytes. You can only request a maximum (or less) of 8 bytes at a time from the micro. So here is how the response would look with a start address of "0000". The values at the end of this string are made up for example only. I'll explain below. The complete response from an 8 byte read request.
36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03, 36, 00, 04, 36, 00, 05, 36, 00, 06, 36, 00, 07, FF, 8, DD, DD, DD, DD, DD, DD, DD, DD. The returned data explained (in parentheses)... This echos what was requested (8 bytes of data 00-07 at address 00). ((00)(0-7)).
(36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03, 36, 00, 04, 36, 00, 05, 36, 00, 06, 36, 00, 07), FF, 8, DD, DD, DD, DD, DD, DD, DD, DD. A header (always the same, FF).
36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03, 36, 00, 04, 36, 00, 05, 36, 00, 06, 36, 00, 07,( FF), 8, DD, DD, DD, DD, DD, DD, DD, DD. How many bytes of data will follow (8 were requested).
36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03, 36, 00, 04, 36, 00, 05, 36, 00, 06, 36, 00, 07, FF,(8), DD, DD, DD, DD, DD, DD, DD, DD. The returned bytes that were requested. These are the bytes that are written to the bin file. I made up the value DD for this example.
36, 0, 0, 36, 00, 01, 36, 00, 02, 36, 0, 03, 36, 00, 04, 36, 00, 05, 36, 00, 06, 36, 00, 07, FF, 8, (DD, DD, DD, DD, DD, DD, DD, DD,). So, with all this said, try putting 8000 as the start address and FFFF as the ending address and see what happens. Here is an example of how the addresses are different between how you look at them in an eprom with a hex editor and where they actually are in the ecu's micro. Eprom view.
 ECU view.
 www.mytwinturbo.com Nissan Data Voice - The first Nissan diagnostic software with a voice! Download my Nissan 300ZX Vin/Model Lookup. Watch an ECZA meet caravan! |
 |
