Author Topic: BRTRO-420 Reflow Oven Reverse Engineering  (Read 400 times)

0 Members and 1 Guest are viewing this topic.

Offline bleckers

  • Contributor
  • Posts: 29
  • Country: au
  • Country: au
BRTRO-420 Reflow Oven Reverse Engineering
« on: June 18, 2019, 03:17:46 pm »
From this topic TassiloH mentioned that there might be a possible serial interface for the BRTRO-420, since it doesn't come with one as standard.

There is no RS232 connector on the oven, although the controller board seems to have an unused connector with two optocouplers that looks suspiciously like an isolated serial communication interface.

Having recently received one of these myself, I decided to go straight for the COM port to see what's going on, as it would be nice to at least have some temperature readouts.  :-/O



The board itself uses a CY96610 Series CY96F613 microcontroller - The datasheet for this is here - https://www.cypress.com/file/232341/download, technical reference manual here - https://www.cypress.com/file/241411/download, more documents here - https://www.cypress.com/products/16fx

To get the ball rolling, I have reverse engineered the "COM" port connection. See attached for the schematic of this.

Unfortunately connecting to either the TX output or R25 to a scope doesn't output any data when the unit is switched on, or when sitting on the main page. The next step is to build a USB/UART adapter to power up the RX optocoupler and try sending commands to it.

If I cannot get anywhere with this, I might consider decoding the LCD outputs and interfacing with the buttons to control it. The LCD is a standard 128x64 dot matrix LCD with model number 12864D1 V3.0 (could be the same as this with a KS0108, KS0107 chipset - http://www.vishay.com/docs/37329/37329.pdf) and the buttons wired to a separate board. There's no markings on the other side of the LCD PCB.
Stay tuned!

Edit:

Looking at the Cypress datasheet, header W1 is connected to DEBUG I/F with a pullup which is the one wire debug interface. When the DEBUG I/F and MD pins are held low on reset (MD is tied to ground and the other side of W1 is ground), it enables serial programming on USART2 (and USART7,USART8). According to the datasheet, USART2 uses SIN2-Pin7 SOT2-Pin8 and SCK2-Pin9 for programming, however on this board the SCK2 pin is used elsewhere, so I'm pretty sure the COM header isn't used for serial programming, as you'd expect SCK2 to also be connected through (this alleviates some doubt I had about it possibly being just a programming interface).

Edit 2:

I connected this up to a USB->UART adapter and cycled through all possible serial speeds and settings. Unfortunately there is no response even though the signal gets through the optocoupler (although it's inverted on the output compared to the TX pin, so it might need something else). Considering this board has a 420 label on the speaker sticker, I'm guessing this board is a generic controller, with custom firmware depending on the board.

Edit 3:

Reading further into the technical reference manual, the third USART connection for SCLK is actually not required for serial programming (see page 892, Figure 31-4). So it could very well be that this COM port is in fact a flash programming connector...  :--

Edit 4:

I'm not really willing to mess with the DEBUG I/F and put this into serial programming mode, in case I brick the firmware. Instead I'm going to create an adapter to interface with the LCD and decode the menu from that information.

Edit 5:

After hooking up a logic analyser to the display, I can confirm that it is infact a KS0108 with the same interface/pinout as the vishay display linked above (it seems most of these LCDs follow the same pinout order at least for the data pins).
« Last Edit: June 22, 2019, 05:46:57 am by bleckers »
 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 497
  • Country: ca
  • Country: ca
Re: BRTRO-420 Reflow Oven Reverse Engineering
« Reply #1 on: June 20, 2019, 01:47:36 pm »
Fairly inefficient use of time. Why do you want to reverse the trivial function, when it is much easier to rewrite the s/w from scratch. Let alone doing for a very bad oven...
 

Offline bleckers

  • Contributor
  • Posts: 29
  • Country: au
  • Country: au
Re: BRTRO-420 Reflow Oven Reverse Engineering
« Reply #2 on: June 21, 2019, 05:33:58 am »
Fairly inefficient use of time. Why do you want to reverse the trivial function, when it is much easier to rewrite the s/w from scratch. Let alone doing for a very bad oven...

If I had a spare controller or a cypress dev kit lying around, I'd totally give this a crack. The main reason I don't want to do this is that I have to effectively brick it (I'd of course remove the original micro to keep it from being completely bricked) and go all in with the software rewrite path, whereas decoding the LCD allows me to still use the machine while debugging. I also have to still figure out what the LCD is anyway to be able to talk to it.

The machine itself is decent enough in terms of temperature management (compared to the other cheapies out there), so there's nothing to really gain from a reprogram, apart from a native com port. Decoding the LCD on the other hand can be useful for other machinery that uses the same LCD and it's a passive modification.
« Last Edit: June 21, 2019, 06:17:38 am by bleckers »
 

Offline bleckers

  • Contributor
  • Posts: 29
  • Country: au
  • Country: au
Re: BRTRO-420 Reflow Oven Reverse Engineering
« Reply #3 on: June 22, 2019, 01:25:35 pm »
So I created a quick KS0108 parser that decodes the output from a logic analyser CSV file.





The logic analyser is connected to an additional 10x2 header that I attached to the LCD cable (see attached). The pinout is the same as the Vishay datasheet on this machine.

I was going to make a passthrough adapter so it didn't require any modification, but that would require etching a board up to connect to all the double row traces. Doing it this way, I can now just put a connector in the center of a bit of veroboard and connect up a small controller board to all the required pins.

I have a small NRF52 board laying around, so the next step is to wire this up, port the decoder code to it and send it over Bluetooth  :)

Edit: Attached is the current version of the decoder software (.NET 4.0) with an example CSV file to display. The CSV file is exported from the Saleae Logic software, but any similar format will work fine.

Edit 2: I'm continuing the project here on another page - https://hackaday.io/project/166220-domsnif-dot-matrix-lcd-sniffer-bluetooth-adapter
« Last Edit: June 24, 2019, 11:29:28 pm by bleckers »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf