Find accepted commands from an firmware - Page 1
Forum section: electronics / general

author: coromonadalix
author_rank: Super Contributor
timestamp: October 16, 2019, 01:14:19 am
content: 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 atmega128It's based on an atmega 128a plcc 64 pins, many inputs and outputs coupled by optosI think it has at least 1 or 2 outputs used as a dac, outputting an 0-5vdc referenceI only have a firmware for this board, and i slowly reverse the board designMy 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 ??

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: October 16, 2019, 01:30:26 am
content: 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:

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 16, 2019, 11:26:23 am
content: 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 3Cpayload len depends on cmdbyteCmd can be:72 - payload is 4 bytes grouped as 2 16 bit values73 - payload is 4 bytes grouped as 2 16 bit values78 - payload is 2 bytes grouped as one 16 bit value79 - payload is 2 bytes grouped as one 16 bit value9B - payload is 5A bytearrSomething - 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)

author: Psi
author_rank: Super Contributor
timestamp: October 16, 2019, 11:29:41 am
content: 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.

author: coromonadalix
author_rank: Super Contributor
timestamp: October 16, 2019, 02:29:05 pm
content: For the source code. i'll never get it, i've found some sparse info(s) for the head controlIt 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 baudMy 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 ??EDITOh found this on dwin.com.cnhttp://www.ampdisplay.com/documents/pdf/Command%20Set%20V2.4.pdf

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 16, 2019, 05:54:04 pm
content: 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).

author: coromonadalix
author_rank: Super Contributor
timestamp: October 16, 2019, 07:18:23 pm
content: 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 transceiversMaybe 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 19, 2019, 10:00:57 pm
content: 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.

author: coromonadalix
author_rank: Super Contributor
timestamp: October 20, 2019, 03:49:31 am
content: 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 sourceThs 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 somethingWritten Kds-001 on it, but no company logos and no google fuu luckThere is somekind of an logo bitmap in the firmware ??