Hi Chris, Thanks for the good suggestion, and also for the friendly welcome -- I'm looking forward to doing some good work with this cool platform. Unfortunately however, it seems that it throws exactly the same exception at exactly the same point for COM2 as for COM1. I attach an image of the debug window in case it gives clues. Probably the driver doesn't support this feature of the AT91SAM7X USARTs. I assume the next step is writing my own unmanaged code to interact with this? Since I'm new to this environment, any tips for this (or any other approach) would be most welcome. Thanks again! Howie

Hi Howie,

COM1 is a special "debug UART" which can only handle 8 data bits if I remember correctly.

Can you try COM2? Looking at the data sheet, it can handle 9 data bits.

Welcome to the Netduino community,

Chris

I am trying to use a Netduino Plus board to replace the legacy controller for an industrial machine that uses a 9-bit serial protocol (the remote process controllers only read bytes with the 9th bit set until they see a packet addressed to them). Life is good if I specify 8 data bits, but if I set 9 it throws an unhandled System.ArgumentException at Microsoft.SPOT.Hardware.SerialPort.dll!System.IO.Port.InternalOpen() (call made at Line 156 of the 4.1 source file SerialPort.cs) Here's my code: mSerial = new SerialPort(SerialPorts.COM1, 375000, Parity.Even, 9); mSerial.DataReceived += new SerialDataReceivedEventHandler(mSerial_DataReceived); mSerial.Open(); I assume the DLL is complaining about a parameter it can't fully handle (9th bit needs a special register bit write; obviously not included in the data byte). Not sure if this is a SecretLabs or MS issue. Would changing to 4.2 firmware fix it? (I tried, but I gave up fighting the driver incompatibility of the Atmel tiny booter.) How do I fix this myself? First time trying managed code for low-level; reminds me of the old days when Windows worked great at the GUI high level before a low-level crash ;-) Howie Goodell