Remora - ethernet NVEM / EC300 / EC500 cnc board

I'm trying to figure out what this IC is. I thought it might be an EEPROM but it is connected to GPIO pins that don't have a combined usage like I2C or SPI. Two pins do have pull down resistors though.

Any one have an idea what this could be? An I2C EEPROM would make sense but it would need to be bit banged in software.

 

The location of the power and ground on the chip does not seem match up with any I2C EEPROM that I can find. Strange one...

The pins that I have left unlabeled are not connected from what I can make out.

It could be just about anything, which is no help at all.

10K would make sense. I suppose all you can do is try.

Although the pin out seems a bit "cooky".

I cannot help with confident answer with this information but i think is i2c EEPROM too from mikrocihp atmel st..., but i will have one controller with me in a week and see what can be these IC. I will make some test and maybe will have mark on my board... will see

Pro_El wrote:

I cannot help with confident answer with this information but i think is i2c EEPROM too from mikrocihp atmel st..., but i will have one controller with me in a week and see what can be these IC. I will make some test and maybe will have mark on my board... will see

Hi, let's hope your board is the v3 version like mine. Other boards don't seem to have this chip populated.

I tried to re-flash the original firmware copy I took, but now I can't get a connection with Mach3 even though the PHY seems to be sending out requests. I did find a copy of the firmware on the web but it appears to be a very different size to the copy I thought I took. It would be great if your board is the same and we can get a good copy of the original bin / hex.

I'm not worried about it for using the board, as I will use Remora. But I did want to try and reverse engineer the protocol for the NVMPG that I got in the bundle...

A little more progress on the NVEM board over a long weekend. I still cannot get the original firmware to talk with Mach3 again. I was hoping to be able to sniff the serial connection to the MPG to try and figure out the serial payload protocol. The only other way to do this would be to decompile the firmware.

Opening up the MPG to find that it too has an STM32 chip. The MCU is a STM32F103RCT6 with a 25Mhz crystal (which is strange). The TFT display module is an XYL2221 module using a parallel ILI9225 driver.

This was my first attempt at trying to reverse engineer from a binary so a bit of a learning curve on how to use the Ghidra software.

After finding what looked like the main() function there were only two other function calls in the main loop. The first being a call to what looks like the TFT update function and the other doing something with the interrupt controller. Looks like timer interrupts are used to poll of data and read button presses etc.

In the TFT_update function there are references to array positions that contain data for the display values. Enough info to start mapping out the payload structure.

There is a header of two bytes. This was found by looking for a UART receive function. These two header bytes are used to sync the data and then to transfer a further 51 following bytes into a data array. This same function also sends a reply if a second header structure is received. No data is updated so this must be used for checking that the MPG is connected.

The button press codes were straight forward to capture using Realterm.

I built a protocol simulator in Excel to test it out. I can update the display as needed!

Next step is to write a LinuxCNC component that can encode the 51 byte payload and a Remora module to go into the NVEM board to send the data to the MPG.  

Baudrate = 115200 8N1
[protocol simulator is attached to save others from the work]

 

My hat off to you, you've really been putting in the hard yards.

Being a serial protocol would there be the chance of using the Pendant without the NVEM module via a USB to serial dongle directly attached to a computer.