2019-02-19 07:44 PM
New to STM8, I can create and upload new firmware, but I'd like to understand the reverse process in the event I need to use SWIM for root cause analysis of bad or damaged parts with multiple firmware versions. Imagine a drone with AI able to self-modify and update firmware of its components in real time eventually hitting a wall at high speed and you get the idea why this can be important. Suggestions to shorten the learning process? (I'm using a STM8VLDISCOVERY so I have ST-LINK with SWIM configured and hardwired to start).
Solved! Go to Solution.
2019-02-21 11:58 PM
> Expecting there are known tools for STM8 to decompile firmware, can anyone point me to them?
No decompiler, but there are disassemblers available. It shouldn't be a problem, STM8 is a simple architecture.
2019-02-19 10:15 PM
Most end products store their SW version in flash, for traceability and upgradeability purpose.
Otherwise, read the flash content and compare it with the reference bin file versions.
As most of the code is precompiled in laptops by C toolchains then programmed in Flash (Read-only memory), the leftover RAM wouldn't be enough to store the AI models (which is not code, it's tenserflow format usually).
If you'd like to explore self modify code, take an STM32 which supports JS (javascript) interpreter engine. With the eval() function, you'll achieve the self-modify and do the risks assesment after trial runs.
2019-02-21 12:27 PM
There is no AI in the STM8 devices, they are dedicated processors that take on a very specific task - all that is not important here, what I need to do is create a toolchain to decompile the binary firmware in the event of a catastrophic failure. Expecting there are known tools for STM8 to decompile firmware, can anyone point me to them? Thx!
2019-02-21 11:58 PM
> Expecting there are known tools for STM8 to decompile firmware, can anyone point me to them?
No decompiler, but there are disassemblers available. It shouldn't be a problem, STM8 is a simple architecture.