|
prj
|
 |
« Reply #1950 on: December 07, 2022, 04:31:42 PM »
|
|
|
Since I've never read much about flash storage chips, I am unsure if it's possible to write only in specific memory locations or is it per sector memory. So thats my next goal. You can write only one byte at a time. But you can only erase a whole page. There is no point to load anything to RAM. The correct way is to use a streaming compressor e.g. zlib to pack the data and unpack it on the fly as it's transferred. Using this technique you can reach much higher flashing speeds. Also, I don't know how the Volvo ECU works but you should consider how to recover from a failed state as well when the key is cycled. |
|
|
|
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
 Offline
Posts: 131
|
|
« Reply #1951 on: December 07, 2022, 04:46:48 PM »
|
|
|
You can write only one byte at a time.
But you can only erase a whole page.
There is no point to load anything to RAM.
The correct way is to use a streaming compressor e.g. zlib to pack the data and unpack it on the fly as it's transferred.
Using this technique you can reach much higher flashing speeds.
Also, I don't know how the Volvo ECU works but you should consider how to recover from a failed state as well when the key is cycled.
The on-chip RAM has limited space for the kernel. The original kernel that Volvo supply aka the SBL reads data from the serial interface, yes serial, or CAN. I am not certain, I didn't dig much deep into that. So it streams in this way and can write what-where anywhere without size limits. The method I propose is for skipping setting up the code to communicate in the same manner and do it quick and dirty so I can finally apply my changes. As for writing per-byte or per-word, that is just perfect for me. Speed of flashing is of no concern to me right now. And you may wonder why I don't use the original SBL? It cannot flash maps. As for bricking, since I am not touching the Sh7055 ROM, the chances are a bit fair lower of that happening. The external 29LV chip is more at risk, but the docs say there are built-in protections if any of the voltages fluctuate or anything of the sort. And even if I fail to write mid-programming, I have backups of the original maps(or will create such when I have to before proceeding). So to summarize, the main MCU's internal ROM is never written to, only external memory devices which is just the maps chip. On another note, I found some more common code for 29LV chips -> https://github.com/ARM-software/u-boot/blob/master/drivers/mtd/jedec_flash.c |
|
|
|
« Last Edit: December 07, 2022, 05:11:01 PM by dikidera »
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1952 on: December 08, 2022, 05:14:14 PM »
|
|
|
So the person who provided me with the SBL proved to me that the SBL can indeed write to the external memories. I can only assume that when you set up the SH7055 to be flashed, it also enables the internal circuitry to drive the CE,WE,OE pins high or low of the external memory and automatically sends the special unlock commands to the external flash chip. However this was not in the docs, or not presented in a way that made this clear.
I've also searched the byte patterns 0x555 and 0x2AA that are the special unlock commands that need to be sent to the 29LV chip and they don't exist in the ROM or SBL and are not even mentioned in the SH7055 hardware manual but they are required by the chip to unlock programming.
|
|
|
|
« Last Edit: December 08, 2022, 05:39:44 PM by dikidera »
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #1953 on: December 08, 2022, 10:01:24 PM »
|
|
|
Here is full 01-03 Denso ECU dump.
|
|
|
|
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1954 on: December 09, 2022, 02:52:49 AM »
|
|
|
Very nice indeed. My test ecu is a 02 or 03, but my car is a 05+ with 500kbps CAN speed.
And there are all the files I could find which are 05+. Just to clarify, I found these files online, I didn't dump them.
|
|
|
|
« Last Edit: December 09, 2022, 03:18:31 AM by dikidera »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #1955 on: December 09, 2022, 03:56:04 AM »
|
|
|
The on-chip RAM has limited space for the kernel. The original kernel that Volvo supply aka the SBL reads data from the serial interface, yes serial, or CAN. I am not certain, I didn't dig much deep into that. So it streams in this way and can write what-where anywhere without size limits. The method I propose is for skipping setting up the code to communicate in the same manner and do it quick and dirty so I can finally apply my changes. As for writing per-byte or per-word, that is just perfect for me. Speed of flashing is of no concern to me right now. And you may wonder why I don't use the original SBL? It cannot flash maps. You missed the fact that before you can write you need to erase a page, and the minimum realistic granularity is writing that whole page + the checksums page. As for bricking, since I am not touching the Sh7055 ROM, the chances are a bit fair lower of that happening. The external 29LV chip is more at risk, but the docs say there are built-in protections if any of the voltages fluctuate or anything of the sort. And even if I fail to write mid-programming, I have backups of the original maps(or will create such when I have to before proceeding). So to summarize, the main MCU's internal ROM is never written to, only external memory devices which is just the maps chip. If the software is marked as valid, and the maps contain errors or are half empty, e.g. 3d map but one axis FF, you are going to get a reset loop on the ECU most likely. There are usually facilities in place to mark that programming has started and mark that it has finished, otherwise the MCU should not start the main program. |
|
|
|
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1956 on: December 09, 2022, 05:18:05 AM »
|
|
|
You missed the fact that before you can write you need to erase a page, and the minimum realistic granularity is writing that whole page + the checksums page.If the software is marked as valid, and the maps contain errors or are half empty, e.g. 3d map but one axis FF, you are going to
That was my question before where you said I could write byte by byte. I took that to mean that I do not need to erase the page/sector. So even if I change one byte, I still have to erase a whole page/sector? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #1957 on: December 09, 2022, 05:37:22 AM »
|
|
|
That was my question before where you said I could write byte by byte. I took that to mean that I do not need to erase the page/sector. So even if I change one byte, I still have to erase a whole page/sector?
Yes of course, this is how flash memory works. You can write byte by byte (in some exceptions there can be ECC, but not here most likely), if the page was previously erased. Even more precisely, in flash memory all bits are 1 when it has been erased, and you can flip any bit that is 1 to 0. You can not go from 0 to 1, only way to do that is erase the page. |
|
|
|
« Last Edit: December 09, 2022, 05:39:38 AM by prj »
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1958 on: December 09, 2022, 07:17:43 AM »
|
|
|
Thanks for the clarification. An erase is a must then. I also have to look into the checksum, although that would be when I am actually able to write data. I did some more experiments and soldered a wire to the WE pin of the 29LV flash. It is connected to pin 226 of the MCU(or 35), however the pin is multiplexed and I could not find a way to make it work. I used the pin function controller to change the pin to general IO, and then made it output. But after attempting to write a logic low I could not make the pin change states, at least not at the 29LV WE pin. But we know that the SBL can erase/write this chip which means that at some point the logic low/high states can affect this WE pin. If this was not the correct pin, the next candidate is pin 35 at Port F. Progress is slow, because my gf is playing LoL on my PC all day, if she isn't she is playing the guitar, when she's not doing that, she wants to go out for a walk.  Addition: I had to bust out my multimeter and was able to trace the pin to Port J 9 aka Pin 186. This wasn't easy btw. The traces come out of the other side in a resistor to come back out the other. And resistors are tiny. Further tracing revealed that there is an AND gate chip connected to the WE enable pin of the 29LV chip, that seems to drive it high constantly. I am tracing that chip as well. Addition 2: I accidentally broke the WE pin of the 29LV chip as well the trace it was connected to. So either I manage to fix it or I get another test ECU. |
|
|
|
« Last Edit: December 10, 2022, 09:16:35 AM by dikidera »
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #1959 on: December 11, 2022, 09:57:54 AM »
|
|
|
It looks like volvo community are still died. Where are all these revolutioners?
I've added TCMDataLogger class (very awful implementation) for logging RAM for TF80 gearbox. AW55 gearbox isn't supported due to nonimplemented 0xb4 0x21 0x34 command. it can be implemented with A7 command but this command accepts only 3 byte for address.
|
|
|
|
|
Logged
|
|
|
|
s60rawr
Full Member
Karma: +18/-784
Offline
Posts: 148
|
|
« Reply #1960 on: December 11, 2022, 04:04:28 PM »
|
|
|
It looks like volvo community are still died. Where are all these revolutioners?
I've added TCMDataLogger class (very awful implementation) for logging RAM for TF80 gearbox. AW55 gearbox isn't supported due to nonimplemented 0xb4 0x21 0x34 command. it can be implemented with A7 command but this command accepts only 3 byte for address.
we're here working in the background  |
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #1961 on: December 11, 2022, 10:40:38 PM »
|
|
|
we're here working in the background Half year gone By the way one very experienced guy helped me with A7 command. message should be filled with next data: canTx[0] = 0xCF; canTx[1] = ecu; // 0x6E in case of TCM canTx[2] = 0xA7; canTx[3] = dataAddress.byte.UB; canTx[4] = dataAddress.byte.HB; canTx[5] = dataAddress.byte.LB; canTx[6] = 1; canTx[7] = Numbytes addrs filled with next values: 0x000000:0x0FFFFF ROM 0xFE0000:FE7FFF EEPROM 0xFF6000:0xFFFFFF RAM for SH7055 0xFF0000:0xFFFFFF RAM for SH7058 |
|
|
|
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1962 on: December 12, 2022, 07:59:38 AM »
|
|
|
Is the A7 command the same as B4 in ECM, but A7 for TCM?
|
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #1963 on: December 12, 2022, 08:15:04 AM »
|
|
|
Is the A7 command the same as B4 in ECM, but A7 for TCM?
No, it's common command. Here is command for ECM: 7A A7 FF FF FF 01 01 But Alexander which have great experience for Denso ECUs told me that 0FFFFE CAN message doesn't processed inside Denso ECM for almost all commands. I'll check what CAN message is generated for Denso ECM for A7 command. May be there is different CAN id is generated for this ECU type. By the way if you want commercial solution of your problem then Alexander is best person for this. |
|
|
|
|
Logged
|
|
|
|
dikidera
Full Member
Karma: +7/-6
Offline
Posts: 131
|
|
« Reply #1964 on: December 12, 2022, 08:19:33 AM »
|
|
|
No, it's common command. Here is command for ECM:
7A A7 FF FF FF 01 01
But Alexander which have great experience for Denso ECUs told me that 0FFFFE CAN message doesn't processed inside Denso ECM for almost all commands. I'll check what CAN message is generated for Denso ECM for A7 command. May be there is different CAN id is generated for this ECU type.
By the way if you want commercial solution of your problem then Alexander is best person for this.
I had bench ECU, whenever I did 0x7A<command> it all gets executed there. But this was bootloader commands. However there is also a mysterious chip next to the SH7055 which I have no idea what it is, and only a few russians know what it does. Going down to the car to test my VIDA proxy. Excited but also well prepared for various bugs. Well first bug was..my mobile hotspot network had an addition space inserted in the name, and I had configured the rpi to connect to the network manually, and I wondered why it wasn't connecting. now back to the car I go. Ok, so here is what happened. I plugged in the cable, set up everything and could see the CAN bus communication going on, however!!! After sending command 0xFF86000000000000, the whole car restarts, this unfortunately stops power to my RPI, restarting it as well. And the only thing that can do this is the CEM, so perhaps the CEM doesn't like this command? |
|
|
|
« Last Edit: December 12, 2022, 11:09:42 AM by dikidera »
|
Logged
|
|
|
|
|
