Let's make a closely MXT like detector!

[Aziz]

AI doesn’t replace thinking - and I honestly have no idea what your comments add to this discussion.

This is a fundamental issue. It fits fully to the discussion.
The AI gives you a lot of food for thinking and asking the right questions. You decide the path to go. AI helps in finding the path you want to go.

Believe me. AI is the best tool ever..

[boilcoil]

Hey Moodz,
Amazing performance.
You are an extremely smart guy, hats off to you.

[Taktyk]

So to answer your question .. .what did the AI achieve here ? ... plenty !

See the full assembly source attached ...

I reviewed your code. What you have is a completely different program architecture.

It looks like you generated an alternative assembly firmware.. That can be a valid clean-room reimplementation, but it is not the same as recovering the original firmware.

Your code does not match the disassembled MXT firmware. There are fundamental differences already at the reset vector, interrupt handling, watchdog usage, memory layout, and overall program flow.

For comparison, my own reverse-engineering work is still unfinished, but I am already building a RAM map directly from the disassembled firmware, tracking actual register usage, bank context, read/write sites, and unresolved aliases instead of assuming a clean high-level architecture.

So I would describe your project as an alternative firmware implementation that tries to emulate the original behavior, not as code that is consistent with the original disassembled firmware.

My goal is not to claim that I have recovered the original source code line-for-line. My goal is to build a semantic C reconstruction based on the actual disassembled firmware: something that documents the real control flow, RAM usage, register behavior, signal processing, UI logic, and unresolved ambiguities. Such a reconstruction can be used as a reference, as inspiration for compatible firmware, and potentially as a way to identify or fix design mistakes in the original firmware.