I should probably title this post
W00t W00t W00t or WooooooooHoooooooooo :-)
and by that opening sentance you can probably figure out that I've cracked it.
It's taken me about 3 weeks, but I've broken in, I've figure out the protocol on the MSP430F423 and I now have dotnet code that interface that can read the digital inputs on the device, and write the digital outputs.
Essentially my hunch about the MSP430 being connected to the COM5 port inside the PC itself was correct, the bit I got wrong was that it wasn't connected up in such a way as I can activate the bootloader.
The MSP430F423 does have the standard non-erasable uart bootloader installed on the chip, but you have to do some very, very precise timing using the RST and INT pins, which on a development board are connected to the RTS & CTS lines so that the host software can use the 2 lines as control lines to enter the bootloader.
On the industrial box PC's I have, the internal COM5 RTS/CTS are not connected up. There is however an internal serial pin header (well the holes anyway) on the motherboard, and tracing the RTS/CTS etc from that back to the MCU shows that the RTS/CTS on that connector IS connected up correctly, so I'm pretty sure that if I where to solder a pin header into it then connect it up using an external uart such as one of the FTDI's I have lying around, I would be able to read and/or re-program it. That's for another day though :-)
For now, the protocol once I figured it out was quite simple.
Command packets are exactly always 32 bytes in length, as are response packets.
To get the current firmware running on the device to pay attention to you, the first 2 bytes of that packer must always be
0x7B followed by 0x23
and the last 2 bytes the opposite
0x23 followed by 0x7D
in ascii it looks something like {# #}
Once you have 32 bytes of 0x00 with those markers on either end, you then need to put what I think is a command type byte in at offset 2 and an actual command byte at offset 3
From what I've worked out so far, offset 2 = 1 means command is a read command and = 2 means it's a write command.
The actual command byte at offset 3 is always a negative number, so it's a signed byte in 2's compliment.
-126 (0x82) = Digital I/O
-124 (0x84) = Analog (ADC) 1
-125 (0x83) = Analog (ADC) 2
-127 (0x81) = Sign on/Authenticate/Init or something like that (I'll come back to this one in a moment)
So to read the digital I/O inputs for example, you send
0x7B, 0x23, 0x01, 0x82 (26 * 0x00) , 0x23, 0x7D
The MSP will then respond with a more or less mirror image of the packet, exactly 32 bytes, same beginning and end sequence, but in the 3rd byte where I put the 0x01, that will be changed to a 0x03, then the next 2 bytes following the 0x82 will be 0x01 and 0xX0
The capital X will be 1 for Input 0, 2 for input 1, 3 for input 2 and 4 for input 3, or combinations thereof so for example if I get back 0xF0 then all for inputs have a signal on them.
The inputs are active low, so 0x00 means all four are high, 0xF0 means all 4 are low
Depending on what your doing the 0x01 changing to a 0x03 can sometimes get changed to a 0x04 especially on the sign in command.
The MSP430 firmware WILL NOT respond to anything before you first send it what I'm calling an init/sign on packet.
0x7B, 0x23, 0x02, 0x81, 0x05, 0x41, 0x52, 0x42, 0x4F, 0x52 (20 * 0x00) , 0x23, 0x7D
The usual start and end bytes are there, and the bytes at 2 & 3 are 0x02/0x81 which is a write command of -127, then there is a 0x05 (I assume is length) followed by 5 bytes that spell:
ARBORThe name of the manufacturer.
The response comes back with the 0x02/0x81 changed to 0x04/0x81 and the 0x05 prior to the 5 extra bytes changed to 0x01 if it was successful, if you change any of the bytes in 'ARBOR' to anything else the 0x05 comes back changed to 0xFF and the MSP430 refuses to listen to further commands accept 2,-127
Until you send that INIT packet, with the correct passphrase of ARBOR in, the MSP will not acknowledge or listen to any other command sent to it it just stays silent, I've not tried sending the init then sending command, disconnecting and sending command again or anything like that, but I suspect that when the COM connection is severed it resets itself, I still have a little more testing to do here, I'm also going to try some other 1,-xxx combinations see if anything else pops up.
I'm going to put the code I've written in C# (Minus my clients stuff) [I have my clients permission to release the comm library] up on my Github page at
http://github.com/shawty/ so if anyone comes across these (or similar) devices in future the answers will be there, I'll also document the protocol better.
But yea, that's it. What I was essentially doing wrong was sending single bytes to it to see if it responded, but it only responds when the 32 bytes in one go are sent, and whats more any delay of longer than about 10ms between data bytes and it assumes an incomplete packet and ignores you, so you cant actually get any use out of it by sending one byte at a time, you essentially have to build the 32 byte buffer in memory, then throw the entire thing at the device in one go oh and it ONLY operates at 9600 baud 8N1 anything else and again it just goes silent.
Phew....
Shawty