Find accepted commands from an firmware

[coromonadalix]

Hi  i have a board who talks in serial  115200 or 921600 bauds, the serial interface is based on a max 232 going to the atmega128

It's based on an atmega 128a plcc 64 pins, many inputs and outputs coupled by optos
I think it has at least 1 or 2 outputs used as a dac, outputting an 0-5vdc reference

I only have a firmware for this board, and i slowly reverse the board design

My problem is :
I dont have the "head control"  or any control software to make it work ... if im not mistaken, an hmi interface display board was used,  the hmi would not start ( displayed "please wait ...) until it "see" the board i'm talking about.

I'll try to find the hmi used to control this board, but i doubt it ...

With the firmware, is it possible to find the accepted commands to make it work ??   use an serial terminal like sscom32 ?

Would Ida  help ??

[jhpadjustable]

Yes, and yes. That doesn't mean it will be easy or consistently gratifying. It requires intimate familiarity with the architecture, including the core, the peripherals, the machine language, and the C library. This guy reverse-engineers a virtual machine, which bears some similarities to a command processor:

[abyrvalg]

IDA helps for sure, just follow the USART0_RX interrrupt vector and you'll get straight to packet parser.
From USART0 side it accepts this packet format (all numbers are hex, this is a binary protocol):
AA byteCmd bytearrPayload[] CC 33 C3 3C
payload len depends on cmd
byteCmd can be:

• 72 - payload is 4 bytes grouped as 2 16 bit values
• 73 - payload is 4 bytes grouped as 2 16 bit values
• 78 - payload is 2 bytes grouped as one 16 bit value
• 79 - payload is 2 bytes grouped as one 16 bit value
• 9B - payload is 5A bytearrSomething[7] - this looks like date/time (gets converted to a string of XX-XX-XX XX:XX:XX format)

The USART1 protocol is totally different (looks like it has 3A start byte, then len byte then something, didn't studied too much)

[Psi]

It might be worth looking in the firmware for odd number sequences used by the serial comms and then searching for them in google.
Maybe you will stumble across the protocol documented somewhere, or the source code.

[coromonadalix]

For the source code. i'll never get it, i've found some sparse info(s) for the head control

It was controlled by a Dwin DMT80600T080 HMI,  meaning once it receive the firmware / code, it can't be extacted from it, always replaced.
I've read on the Dwin HMI pdf,  if you have the busy pin open/high,  it work at 921600 bauds, if the pin is shorted/grounded,   it will operate at 115200 baud



My only chance is to find the Dwin head controller and sniff out the protocol used  or mimick it thru the serial port with maybe the chance to reverse the posted firmware ??

EDIT
Oh  found this on dwin.com.cn

http://www.ampdisplay.com/documents/pdf/Command%20Set%20V2.4.pdf

[abyrvalg]

So that USART0 RX handler I’ve studied a bit is a panel responses parser actually (look at sections 3.15 and 3.24.4 of DWIN pdf - the rx packets described there match my findings).

[coromonadalix]

The board has 2 serial ports as i can see.

1 section is going to the head/main controller with half of the max232, and the second port is ending on a 0.1" header and use the other 2  max232 transceivers

Maybe a debug port ??


I wanted to use this board as an i/o controller of somekind, since a lot of the atmega 128 pins are opto isolated with an floating 12vdc supply.

I'll try to make my open logic sniffer work,  last time it did not work on a x64 bit windows.

[abyrvalg]

Why do you need the protocol then? Just map the pin functions and use your own firmware (even Arduino). The original firmware is doing some tasks specific to the original purpose, it's protocol doesn't look like something low level with individual I/O access commands at all. As I understand, this board commands the Dwin HMI to display some control panel layout image on it's touch screen display, then processes touches.

[coromonadalix]

I tought it would be   easier to snif out  some infos in the firmware  and try to simulate some Dwin Hmi  commands ....   I can get an identical but used hmi for a very low price, but once again  im stuck with no hmi code source

Ths board sem to be an laser controller of some sort,  with pulse length / speed   timings  and the atmega seems to output a variable voltage to do something

Written Kds-001 on it,  but no company logos and no google fuu luck

There is somekind of an logo bitmap in the firmware ??