Nevo C2 Remote Control - Reverse Engineering - Part 3 (Making)

Nevo C2 Remote Control - Reverse Engineering - Part 3

2016-05-08 16:39 - Making

After quite a delay I'm continuing this series of posts.

I've learned that Samsung's SAM8 line of microcontrollers is based on the Zilog Z8:

Historically, the SAM8 and SAM88 CPUs that are the core of the S3 Family were based on Zilog’s efficient Z8 architecture. For Zilog to introduce the S3 Family is simply a natural evolution culminating in a cooperative agreement between IXYS and Samsung.

And that Zilog has purchased this line from Samsung to bring the product full circle:

IXYS Corporation, parent company of legacy and legendary microcontroller manufacturer Zilog, has entered into an agreement to purchase 4-bit and 8-bit Flash microcontroller product lines from South Korean semiconductor manufacturer Samsung Electronics for $50 Million.

This nugget of info helped me find the S3 Embedded Flash Serial Programming document (mirrored at archive.org and locally), which at first seemed very promising. The best I could find from the datasheet was vague references to "tool mode" which the TEST pin could set, but not whether it's active high or low, and also a NRESET pin with no polarity/value indication, and SDAT/SCLK which sounds like I2C. (The N in NRESET implies active low, and some vague wording implies active high for TEST, but that's not enough to go on by itself.) And no data about the protocol. But this S3 document from Zilog mentions pins with nearly identical names, has much more clear wording about the Reset and Test pins, and specifies the protocol to talk over the data line!

Unfortunately all my attempts to whip up something to talk to this chip with that protocol have failed. The Arduino is terribly easy to work with, but I've only got 5V modules, so I tried working with the 3V STM32 board I have instead. I might have been tripped up by the dual-direction data line (output at first to specify the operation, then input). Either way, I can't get the chip to respond.

Next up is the J6 header which just has two power pins and two UART interfaces. It took a little digging, but I found that UART1 spits out some data at power up, at 38400 N81; here's several repetitions:

00000000  00 00 55 49 42 30 01 0b  00 00 55 49 42 30 01 18  |..UIB0....UIB0..|
00000010  00 00 00 55 49 42 30 01  0b 00 00 55 49 42 30 01  |...UIB0....UIB0.|
00000020  18 00 00 00 55 49 42 30  01 0b 00 00 55 49 42 30  |....UIB0....UIB0|

By watching in my logic analyzer, I can see an 0x00, followed by an 8ms delay, then the 0x00 UIB0 0x01 0x0b, a 10ms delay, an 0x00, another 8ms delay, then the 0x00 UIB0 0x01 0x18. There's a clear pattern here, but I can't interpret the data. With the guts of the remote tacked down to the breadboard I can hardly interact with it. When I move it the backlight lights up, but I see no serial traffic. I can get to a few of the hard buttons beside the display, and they also have no effect.

The JTAG interface remains. But it will remain a topic for another day, as I've got learning to do before I have a chance of making progress.

Comments:

Good Luck
2016-05-12 05:56 - impeeza

Hi, from Colombia we send you lot of good energy on the current task, regards and cudos.

Advances
2016-08-27 20:41 - impeeza

Hi. Do you has making any advance on this project? Regards from Colombia

Nope
2016-08-28 19:09 - arantius

Sorry, this project has stalled! I took one brief stab at JTAG interfacing and made no progress.

Some hints
2018-10-23 07:06 - yaworski

I don’t know if you still have the remote, but I’ve got some tips for you:

The ARM is responsible for UI and reading key presses
The S3F80 is responsible for IR blaster
The UART1 on ARM is used for communicating with S3F80 and the traffic you’ve seen are commands for the Samsung’s chip. You should use another logic analyser input to connect to the RX pin - that way you’d see responses.

The first 0x00 before each command is probably some kind of wake up signal, that’s why there’s a delay after it. Then there’s a command frame, which starts with 0x00 followed by a magic word “UIB0” (ascii). Next is a 1 byte indicating the length of following data (at least 1). Data consist of 1 byte command and optional arguments (arguments depend on the command).
The response frame starts with 1 byte indicating length of following data (at least 1). Next is 1 byte error code (I only know that 0x00 means no error), followed by optional response data (depends on the command).

I’ve identified 4 commands. You’ve captured two of them, which are sent after power up:

0x0b - response is 0x00 followed by ascii string “32013201”
0x18 - response is 0x00 followed by a byte 0x07.

Other two are 0x10 (sends IR signal until 0x00 is received) and 0x24 (adds new IR protocol). These two are specific to how UEI remotes work and it’s not something that can be easily described in a commend under an article. The best is to learn about these remotes on hifi-remote.com forum.

Username
Password
	If you do not have an account to log in to yet, register your own account. You will not enter any personal info and need not supply an email address.
Subject:
Comment:	You may use Markdown syntax in the comment, but no HTML. Hints: If you are attempting to contact me, ask me a question, etc, please send me a message through the contact form rather than posting a comment here. Thank you. (If you post a comment anyway when it should be a message to me, I'll probably just delete your comment. I don't like clutter.)

arantius.com