SB70LC I2C2Serial example not working

[maxwellsmuse]

Hello everyone.

Before I ask my question, yes I did search the forums and I couldn't find an answer.

Preliminaries :

Running an SB70LC development board with a static ip address.
Connected via Ethernet and USB for the serial debugging output.
I can see bootup and printf/cout work on the serial output through MTTTY.
OS is Windows 8.1.

I am running the I2C2Serial example code and it is not working for the Multi-master I2C (I didn't try the single, but if it doesn't work in Multi we can't use this board).

The problem is that I cannot get stdin to work to input the I2C slave address. gets, fgets, and cin all do not work when I type into MTTTY. This is probably something stupid that I'm overlooking.

Troubleshooting steps that I've already taken :

Use fgets and cin.
Debug and Release builds both show the same behavior.
cout, printf all work and I can see the output.
When in Debug, stepping over gets or fgets just hangs.
Changing the flow control in MTTTY to software and trying the above.
I've read any and all Netburner documentation that I can find about how stdin is mapped.

My suspicion is that stdin is being mapped somewhere else, incorrectly.

Does anyone have any suggestions or solutions?

If I cannot get stdin working for this board for debugging, then this is a no-go condition on using this board for our system.

Thanks

[sulliwk06]

You could try mapping stdin yourself.

ReplaceStdio( 0, fd ); // stdin
ReplaceStdio( 1, fd ); // stdout
ReplaceStdio( 2, fd ); // stderr

[rnixon]

Stdin definitely works, so it something unique to your setup or code. Are your jumper settings correct on the dev board to route the serial rx signal to the usb vs the db9? TX will always go to both the usb and db9 because its an output. But you can't have two output driving one uart rx signal, so you need to jumper it one way or the other.

[maxwellsmuse]

sulliwk06, I tried your suggestion and it didn't change anything.

rnixon, I'll double check, I thought I had them all set correctly but you know how these things go when initially learning a new board.

Thanks for confirming that stdin should work through the serial debug port. Most of the forum and troubleshooting posts are about stdout or display issues, which made it unclear if anyone has confirmed that stdin works...

rnixon, it must be the setup, I'm using the I2C2Serial example provided by Netburner with no modifications...

[Ridgeglider]

Ops slight cleanup:
Try this. I think this has been fixed, but you used to have to explicitly close the default (at boot) polled serial ports before reopening them in IRQ mode. Once reopened, you assign them to stdio...:

Code: Select all

		#define STDIN  (0)
		#define STDOUT (1)
		#define STDERR (2)
		#define Com0Port (0)
		#define Com1Port (1)
		#define Com2Port (2)
		#define HalfDuplexEnable (1)
		#define OneStopBit  (1)
		#define TwoStopBits (2)
		#define EightDataBits (8)

        const unsigned int StdIOBaudRate = 115200; 
        typedef enum { eParityNone, eParityOdd, eParityEven, eParityMulti } parity_mode;
		int fdCOM0;			//debug
		int StdIOCom0_fd;	//basically an alias for com0 after we get things set up... 

		SerialClose( 0 );	// close down the default polled Com0 routines


		fdCOM0 = OpenSerial( Com0Port,		// reopen Com0 in IRQ mode
							StdIOBaudRate,
							TwoStopBits,
							EightDataBits,
							eParityNone );

		// Now that the fdCOM0 is ready for use, make sure stdio uses the
		// same fd IRQ based routines and does not try to use the old default polled
		// routines at the same time.
		ReplaceStdio( STDIN,  fdCom0 );
		ReplaceStdio( STDOUT, fdCom0 );
		ReplaceStdio( STDERR, fdCom0 );

		StdIOCom0_fd = fdCOM0;   //make name reflect stdio assignment