Simos 18.1 how to write eeprom and flash correctly?

[PwrMusic]

Hello!
Thanks bri3d and contributors for the amazing work!

I'm trying to transfer immodata to simos 18.1.
I successfully read data from both ECUs and sent them for correction. They sent me a modified eeprom and flash.

When trying to flash eeprom with the command: "write_file AF000000 018000 eeprom1.bin" the writing process starts but not a single byte is written.
At the same time, the write passwords work ("erase_sector 80800000" works ok).

The changes in flash surprised me. These are 6 bytes at address 0x1150. If I understand correctly, this is part of SBOOT.

After unsuccessful eeprom flashing, I tried to write flash with the command: "write_file 80000000 200000 flash1.bin".
The writing started and stuck after 1 minute. Repeated attempts to write stuck at the same place.
When trying to read: "dumpmem 80000000 200000 flash1.bin" the reading process stuck and the read file contains all the information up to the point where the flash was changed (at address 0x1150).

Please answer the questions:
Is it possible to write eeprom? What am I doing wrong?
What died during the flash wrighting? And how to fix it )

Maybe need to erase areas before writing?

Thanks for your help )

[bri3d]

I never added DFlash (eeprom) write support; my recollection is that I at least need to adjust some base addresses for it. Trying to write flash starting at 0x80000000 will eventually run against OTP which can never be overwritten. I am not sure if this is your problem or if it is something else (like not erasing first) but it’s definitely not going to work completely as written.

…

On Sat, Nov 16, 2024 at 4:07 PM PwrMusic ***@***.***> wrote: Hello! Thanks bri3d and contributors for the amazing work! I'm trying to transfer immodata to simos 18.1. I successfully read data from both ECUs and sent them for correction. They sent me a modified eeprom and flash. When trying to flash eeprom with the command: "write_file AF000000 018000 eeprom1.bin" the writing process starts but not a single byte is written. At the same time, the write passwords work ("erase_sector 80800000" works ok). The changes in flash surprised me. These are 6 bytes at address 0x1150. If I understand correctly, this is part of SBOOT. After unsuccessful eeprom flashing, I tried to write flash with the command: "write_file 80000000 200000 flash1.bin". The writing started and stuck after 1 minute. Repeated attempts to write stuck at the same place. When trying to read: "dumpmem 80000000 200000 flash1.bin" the reading process stuck and the read file contains all the information up to the point where the flash was changed (at address 0x1150). Please answer the questions: Is it possible to write eeprom? What am I doing wrong? What died during the flash wrighting? And how to fix it ) Maybe need to erase areas before writing? Thanks for your help ) — Reply to this email directly, view it on GitHub <#5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTO2MVWCE4KIMNMI2WWED2A7FZPAVCNFSM6AAAAABR5I2656VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DKMBVGY2DMNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[PwrMusic]

Thanks for the answer!
How can I try to roll back to stock after flash write?
If I split the flash into segments and erase before writing - will it work? It's scary to erase the SBOOT segment)

I never added DFlash (eeprom) write support; my recollection is that I at least need to adjust some base addresses for it. Trying to write flash starting at 0x80000000 will eventually run against OTP which can never be overwritten. I am not sure if this is your problem or if it is something else (like not erasing first) but it’s definitely not going to work completely as written.
…
On Sat, Nov 16, 2024 at 4:07 PM PwrMusic @.> wrote: Hello! Thanks bri3d and contributors for the amazing work! I'm trying to transfer immodata to simos 18.1. I successfully read data from both ECUs and sent them for correction. They sent me a modified eeprom and flash. When trying to flash eeprom with the command: "write_file AF000000 018000 eeprom1.bin" the writing process starts but not a single byte is written. At the same time, the write passwords work ("erase_sector 80800000" works ok). The changes in flash surprised me. These are 6 bytes at address 0x1150. If I understand correctly, this is part of SBOOT. After unsuccessful eeprom flashing, I tried to write flash with the command: "write_file 80000000 200000 flash1.bin". The writing started and stuck after 1 minute. Repeated attempts to write stuck at the same place. When trying to read: "dumpmem 80000000 200000 flash1.bin" the reading process stuck and the read file contains all the information up to the point where the flash was changed (at address 0x1150). Please answer the questions: Is it possible to write eeprom? What am I doing wrong? What died during the flash wrighting? And how to fix it ) Maybe need to erase areas before writing? Thanks for your help ) — Reply to this email directly, view it on GitHub <#5>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTO2MVWCE4KIMNMI2WWED2A7FZPAVCNFSM6AAAAABR5I2656VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DKMBVGY2DMNA . You are receiving this because you are subscribed to this thread.Message ID: @.>

[bri3d]

Reprogramming PFlash should work split into sectors and erased before writing, yes. Refer to the source or a datasheet for the sector mapping, the sector sizes change by location. You cannot erase or write the sector at 0x14000 as it’s marked as OTP (it contains the MCU marry data like MCUID as well as the cryptography library and public keys). I have written SBOOT using this tooling before but I’m not sure I would recommend it completely, it is extremely janky development code and you are right to be worried.

…

On Sat, Nov 16, 2024 at 4:32 PM PwrMusic ***@***.***> wrote: Thanks for the answer! How can I try to roll back to stock after flash write? If I split the flash into segments and erase before writing - will it work? It's scary to erase the SBOOT segment) I never added DFlash (eeprom) write support; my recollection is that I at least need to adjust some base addresses for it. Trying to write flash starting at 0x80000000 will eventually run against OTP which can never be overwritten. I am not sure if this is your problem or if it is something else (like not erasing first) but it’s definitely not going to work completely as written. … <#m_-9042196616548827593_> On Sat, Nov 16, 2024 at 4:07 PM PwrMusic *@*.*> wrote: Hello! Thanks bri3d and contributors for the amazing work! I'm trying to transfer immodata to simos 18.1. I successfully read data from both ECUs and sent them for correction. They sent me a modified eeprom and flash. When trying to flash eeprom with the command: "write_file AF000000 018000 eeprom1.bin" the writing process starts but not a single byte is written. At the same time, the write passwords work ("erase_sector 80800000" works ok). The changes in flash surprised me. These are 6 bytes at address 0x1150. If I understand correctly, this is part of SBOOT. After unsuccessful eeprom flashing, I tried to write flash with the command: "write_file 80000000 200000 flash1.bin". The writing started and stuck after 1 minute. Repeated attempts to write stuck at the same place. When trying to read: "dumpmem 80000000 200000 flash1.bin" the reading process stuck and the read file contains all the information up to the point where the flash was changed (at address 0x1150). Please answer the questions: Is it possible to write eeprom? What am I doing wrong? What died during the flash wrighting? And how to fix it ) Maybe need to erase areas before writing? Thanks for your help ) — Reply to this email directly, view it on GitHub <#5 <#5>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTO2MVWCE4KIMNMI2WWED2A7FZPAVCNFSM6AAAAABR5I2656VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DKMBVGY2DMNA <https://github.com/notifications/unsubscribe-auth/AABTO2MVWCE4KIMNMI2WWED2A7FZPAVCNFSM6AAAAABR5I2656VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY3DKMBVGY2DMNA> . You are receiving this because you are subscribed to this thread.Message ID: @.*> — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTO2NSVURZ5EJAHFLB6KL2A7IY7AVCNFSM6AAAAABR5I2656VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQHA2TAMJQGE> . You are receiving this because you commented.Message ID: ***@***.***>