STM8: SWIM not working at all

[Arisotura]

Hello there!

I might not be posting this in the right place -- if so, sorry about it.

I am working on a personal project that involves the Wii U gamepad -- basically, making custom firmware and homebrew for it.

The Wii U gamepad employs a microcontroller called UIC, which is a STM8. According to the information I have gathered about it, it would be a STM8L151R8 -- 64KB of FLASH, 4KB of RAM, 2KB of EEPROM, LQFP64 package. The UIC chip on the gamepad motherboard has custom markings ("UIC-WUP") but the pinout matches that of a 'stock' STM8L151R8.

Anyway, I have a gamepad motherboard where the UIC was accidentally bricked.

The UIC has a small bootloader at 0x8000, and the actual firmware (which handles input, power management, and other misc. stuff) is installed at 0x9000. The bootloader simply checks a couple bytes in EEPROM for specific values: if these are set, it jumps to the firmware entry point, otherwise it enters firmware upload mode and waits for a firmware binary to be uploaded. The firmware also has a command that triggers firmware upload mode, to allow for updates.

That's the skinny. What happened to me is that corrupted firmware code was uploaded to the UIC, making it impossible to upload new code the normal way. Thus, the UIC is bricked.


This is where I had the idea of using the SWIM interface to unbrick the UIC. In theory, I would just have to clear the 'firmware installed' marker bytes in EEPROM so I could upload new firmware code. Or maybe I would have to reflash the entire thing, but I have dumps of all the data.

Thing is, I can't get the SWIM interface to respond at all.

From the understanding I have gathered, the memories inside the chip might be locked, but the SWIM interface should atleast respond to activation.

But not even.

My last attempt involved programming a FPGA to send the SWIM entry pulses, and seeing what I get on the scope. In theory, after I send the entry pulses, I should receive a sync pulse after a given amount of time, but I don't receive anything. The STM8 is just not responding at all.

I tried with a pull-up resistor on the SWIM pin, but that made no difference.

I ordered a proper STLink so we'll see if that works, but I don't have a lot of faith there.


So, this has me wondering: can the STM8 (in particular the STM8L151R8) have SWIM completely disabled, to the point it doesn't respond at all? From my understanding of the documentation, that isn't the case, but at this point, I'm doubting... what else could the problem be?

[Postal2]

.... So, this has me wondering: can the STM8 (in particular the STM8L151R8) have SWIM completely disabled, to the point it doesn't respond at all? ....

Yes.

..... From my understanding of the documentation, that isn't the case, ....

This is described in the documentation, I am currently reading it. I can clarify and give an exact quote if necessary.

[Arisotura]

From my understanding, SWIM is disabled by writing to a specific register -- and by pulling NRST low, you can enter SWIM before such a register write happens.

Maybe I'm missing something? I'd like a clarification.

[Postal2]

... Maybe I'm missing something? I'd like a clarification.

Single wire interface module (SWIM) and debug module (DM) RM0016
58/467 DocID14587 Rev 14
There are two important considerations to highlight for the devices where the NRST pin is
not present:
• If the SWIM pin should be used with the I/O pin functionality, it is recommended to add
a ~5 seconds delay in the firmware before changing the functionality on the pin with
SWIM functions. This action allows the user to set the device into SWIM mode after the
device power on and to be able to reprogram the device. If the pin with SWIM
functionality is set to I/O mode immediately after the device reset, the device is unable
to connect through the SWIM interface and it will be locked forever (if the NRST pin is
not available on the package). This initial delay can be removed in the final (locked)
code.
• Their program memory must contain a valid program loop. If the device's memory is
empty, the program continues into non-existing memory space and executes invalid
opcode; this causes the device to reset (reading of non-existing memory is random
content). This behavior might lead to periodic device resets and to a difficulty to
connect to the device through the SWIM interface.

https://www.st.com/resource/en/reference_manual/cd00190271-stm8s-series-and-stm8af-series-8bit-microcontrollers-stmicroelectronics.pdf

[Arisotura]

That's the thing though, my device does have a NRST pin.

NRST can be disabled, but that's done from STM8 code afaik -- and I'm not seeing any code for that here...

[mikerj]

It is possible the (corrupted) firmware is switching the NRST pin to an output immediately after it starts running?  Could you try holding NRST low as you power it up?

[Postal2]

... my device does have a NRST pin. ...

Yes, I see. But the wrong instruction opcode causes reset. It can be the first one after reset.

It turns out that you just need to short reset to ground and SWIM should still connect.

Note:Please note that the SWIM can be set as ACTIVE and communicate while the device is in RESET state (NRST pin forced low).

The SWIM protocol description says that you can connect without releasing reset, but then you will have to release reset to load option bytes. However, you can check "SWIM sends a synchronization frame to the host" with an oscilloscope at the SWIM activation stage. Did you do this?

........ My last attempt involved programming a FPGA to send the SWIM entry pulses, and seeing what I get on the scope. In theory, after I send the entry pulses, I should receive a sync pulse after a given amount of time, but I don't receive anything. The STM8 is just not responding at all. ...........

I see you did. Then it is a custom version of STM8, in which the manufacturer has disabled SWIM, because the customer asked for it.

[Arisotura]

The SWIM protocol description says that you can connect without releasing reset, but then you will have to release reset to load option bytes. However, you can check "SWIM sends a synchronization frame to the host" with an oscilloscope at the SWIM activation stage. Did you do this?

I did, and the STM8 isn't sending anything. Unless it somehow takes way longer than the oscilloscope can display.

In my attempts I've had an extra output to drive NRST low. I haven't tried having it forced low when applying power, though. I guess I could give that a try.

[Postal2]

... I haven't tried having it forced low when applying power, though. I guess I could give that a try.

Try it, but I think SWIM is disabled at the request of the customer of a large batch. I have examples of such behavior.

[Arisotura]

That's another possibility of course, but they do have to flash the UIC with the bootloader. Unless they can have it made pre-flashed.

Also, the board has a test point for pin 1 of the UIC (the SWIM pin), and that pin isn't connected to anything else. There's another test pad for pin 2 (NRST), and that pin seems to just be connected to a capacitor-based reset circuit -- it is possible to pull it low externally. This implies that there's the ability to use SWIM atleast from factory. No idea if I'm being clear here...

[Postal2]

...  Unless they can have it made pre-flashed.

Most likely so, but it doesn't matter. We'll never know. The manufacturer has the ability to configure the chip. And record the serial number of the chip.

.... This implies that there's the ability to use SWIM atleast from factory. ....

I get your point. No, the manufacturer won't change the SWIM entry sequence, it's extra work, they'll just disable it.

[Arisotura]

I gave it a quick try with NRST permanently pulled low. Still no response whatsoever.

I think it's clear at this point...

I ordered some blank STM8's, so I can replace the UIC as a last ditch attempt -- provided I can solder that sort of chip properly.

[Postal2]

...I think it's clear at this point...

Yes.

... I ordered some blank STM8's, so I can replace the UIC as a last ditch attempt -- provided I can solder that sort of chip properly.

This is good for an experiment, but if the manufacturer did one nasty thing, he will do the second one. These chips have unique numbers, something may be connected with this. However, I am currently studying STM8, I need to write a couple of simple programs for it in assembler. So, perhaps, if you reverse everything well, it will be possible to make your own firmware for your device. It is at the level of ATmega8 in complexity.

[rhodges]

However, I am currently studying STM8, I need to write a couple of simple programs for it in assembler.

I have STM8 library and test code on github. You might find something helpful.
https://github.com/unfrozen

[Postal2]

I have STM8 library and test code on github. You might find something helpful.
https://github.com/unfrozen

Thank you very much. I wouldn't have been able to find it myself, because I was looking for examples in assembler. Your assembler inserts are great.

[rhodges]

Please know that the assembler convention changed between SDCC 4.1 and 4.2
I have made changes to help correct this, but if you have any trouble using 4.2, I will be glad to help.

[Postal2]

I somehow missed SDCC, and I didn't like COSMIC because of licensing. I installed "ST Visual Develop" and chose assembler. Most likely I will copy-paste your code, but I will definitely post the result.

[Arisotura]

This is good for an experiment, but if the manufacturer did one nasty thing, he will do the second one. These chips have unique numbers, something may be connected with this. However, I am currently studying STM8, I need to write a couple of simple programs for it in assembler. So, perhaps, if you reverse everything well, it will be possible to make your own firmware for your device. It is at the level of ATmega8 in complexity.

As far as I've seen in all my reverse-engineering, nothing seems tied to a specific UIC chip.

However, what I'm concerned about would be the UIC having subtle differences from a stock chip, possibly requiring a patched firmware. But this is still something I want to try out. Science!

[Postal2]

By "reverse" I mean copying a part of the circuit that is relevant to the matter. The picture shows the HC-12 module, I don't like its firmware, so I'll write my own.

[Arisotura]

As far as I've seen in all my reverse-engineering, nothing seems tied to a specific UIC chip.

To confirm this: I removed the bricked UIC from my board, and transplanted an UIC from another board (that was damaged, but did have a good UIC). It works. All I would need to do would be transferring the correct EEPROM settings for stuff like calibration data, etc.

[Postal2]

I meant something else. Let's say you can imitate the original bootloader and you can update it normally with your chip. And although the chip will be exactly the same, some hidden feature may be checked, and the firmware will not work.