Chuck(G)
25k Member
So what's in the firmware for this thing? I can guess, based on the operation--and having done one myself, but it'd be nice to get the firmware from the unit itself.
So, there's that header near the power pins that I was talking about. I've identified the connections to the MCU USART and noted from that there's a serial boot utility that's present in the chip. All that's needed is a level converter for 3.3V logic to RS232C and a terminal emulator running on a PC (I really like Realterm).
Jumper the pins that connect the BOOT0 pin to 3.3V, hook up the serial interface, and then short the RESET pins. Setting the terminal to 1200 bps, 8E1 and sending out an 7Fh character, we get a 79h back, which is the "ACK" response from the debugger, telling us that it's identified the bit rate and is ready.
So, the next thing to send is is the "Get" command, which is 00h, followed by a check byte, FFh. We get the following string back:
Which means:
.
Which says that we're version 2.2 (but we knew that); read protection was disabled 00 times and enabled 04 times.
Uh oh--The flash ROM is protected. Indeed, if we issue the bytes 11h EEh, we promptly get a 1FH back right away--that's a "NAK" and it says that the flash is indeed protected.
It's possible to disable the protection, but only after erasing the flash. Fat lot of good that does.
So that's a dead end. The next job is working up a circuit diagram and perhaps cutting our own code after observing some of the operational characteristics of the thing.
But we now know that it's possible to program the chip using a simple serial interface. That may come in handy later... I wonder if a dump program could be written to internal SRAM and used to get the flash contents that way...Nope--access to flash isn't allowed if read protection is enabled...
And the beat goes on...
So, there's that header near the power pins that I was talking about. I've identified the connections to the MCU USART and noted from that there's a serial boot utility that's present in the chip. All that's needed is a level converter for 3.3V logic to RS232C and a terminal emulator running on a PC (I really like Realterm).
Jumper the pins that connect the BOOT0 pin to 3.3V, hook up the serial interface, and then short the RESET pins. Setting the terminal to 1200 bps, 8E1 and sending out an 7Fh character, we get a 79h back, which is the "ACK" response from the debugger, telling us that it's identified the bit rate and is ready.
So, the next thing to send is is the "Get" command, which is 00h, followed by a check byte, FFh. We get the following string back:
Code:
790B22000102112131436373829279
- An "ACK" followed by the message length; in this case it's 11 bytes (0Bh).
- The version of the bootloader (2.2)
- The commands supported by this bootloader:
00 01 02 11 21 31 43 63 73 82 92 - And an "ACK".
Code:
220004
Which says that we're version 2.2 (but we knew that); read protection was disabled 00 times and enabled 04 times.
Uh oh--The flash ROM is protected. Indeed, if we issue the bytes 11h EEh, we promptly get a 1FH back right away--that's a "NAK" and it says that the flash is indeed protected.
It's possible to disable the protection, but only after erasing the flash. Fat lot of good that does.
So that's a dead end. The next job is working up a circuit diagram and perhaps cutting our own code after observing some of the operational characteristics of the thing.
But we now know that it's possible to program the chip using a simple serial interface. That may come in handy later... I wonder if a dump program could be written to internal SRAM and used to get the flash contents that way...Nope--access to flash isn't allowed if read protection is enabled...
And the beat goes on...