Author Topic: uart1 appearing on uart0  (Read 9381 times)

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
uart1 appearing on uart0
« on: March 20, 2009, 12:48:59 AM »
Mark,

I'm trying to setup uart1, and I've followed http://www.utasker.com/forum/index.php?topic=54.msg220#msg220 as best as I can.  But when I send data to the uart1 handle, it is still appearing on uart0.

My test code:
Code: [Select]
void fnMyFirstTask(TTASKTABLE *ptrTaskTable){
unsigned char buffer[]="test code\r\n";

        fnDebugMsg("spid1: ");
fnPrint ((unsigned char *)buffer, SerialPortID);//should appear on uart0
fnDebugMsg("spid2: ");
fnPrint ((unsigned char *)buffer, DebugHandle); //should appear on uart0
fnDebugMsg("spid3: ");
fnPrint ((unsigned char *)buffer, SerialPortID1); //should appear on uart1
}

uart defines in app_hw_m5223x.h
Code: [Select]
//#define DEMO_UART    0                                           // use UART 0
        //#define PPP_UART     1                                           // use UART 1 for PPP
        #define UART0 0
#define UART1 1 //uart1

my configuration code in application.c:
Code: [Select]
#ifdef SERIAL_INTERFACE
    QUEUE_HANDLE SerialPortID;                                          // serial port0 handle
QUEUE_HANDLE SerialPortID1;                                          // serial port1 handle
#endif

//in fnApplication
#ifdef SERIAL_INTERFACE                                                  // this serial interface is used for debug output and menu based control
        if (!fnSetNewSerialMode(FOR_I_O)) {                              // open serial port for I/O
            return;                                                      // if the serial port could not be opened we quit
        }
        DebugHandle = SerialPortID;                                      // assign our serial interface as debug port
        if (!fnSetNewSerialMode2(FOR_I_O)) {                              // open serial port for I/O
            return;                                                      // if the serial port could not be opened we quit
        }
#endif

and the serial uart configuration:
Code: [Select]
//configure uart1
extern QUEUE_HANDLE fnSetNewSerialMode2(unsigned char ucDriverMode)
{
    TTYTABLE tInterfaceParameters;                                       // table for passing information to driver
    tInterfaceParameters.Channel = UART1;                            // set UART channel for serial use
    tInterfaceParameters.ucSpeed = temp_pars->temp_parameters.ucSerialSpeed; // baud rate
    tInterfaceParameters.Rx_tx_sizes.RxQueueSize = RX_BUFFER_SIZE;       // input buffer size
    tInterfaceParameters.Rx_tx_sizes.TxQueueSize = TX_BUFFER_SIZE;       // output buffer size
    tInterfaceParameters.Task_to_wake = OWN_TASK;                        // wake self when messages have been received
    #ifdef SUPPORT_FLOW_HIGH_LOW
    tInterfaceParameters.ucFlowHighWater = temp_pars->temp_parameters.ucFlowHigh;// set the flow control high and low water levels in %
    tInterfaceParameters.ucFlowLowWater = temp_pars->temp_parameters.ucFlowLow;
    #endif
    tInterfaceParameters.usConfig = temp_pars->temp_parameters.usSerialMode;
    #ifdef TEST_MSG_MODE
    tInterfaceParameters.usConfig |= (MSG_MODE);
        #if defined (TEST_MSG_CNT_MODE) && defined (SUPPORT_MSG_CNT)
    tInterfaceParameters.usConfig |= (MSG_MODE_RX_CNT);
        #endif
    tInterfaceParameters.usConfig &= ~USE_XON_OFF;
    tInterfaceParameters.ucMessageTerminator = '\r';
    #endif
    #ifdef SERIAL_SUPPORT_DMA
    tInterfaceParameters.ucDMAConfig = UART_TX_DMA;                      // activate DMA on transmission
  //tInterfaceParameters.ucDMAConfig |= (UART_RX_DMA | UART_RX_DMA_HALF_BUFFER); // test half buffer DMA reception
    #endif
    if ((SerialPortID1 = fnOpen( TYPE_TTY, ucDriverMode, &tInterfaceParameters )) != 0) { // open or change the channel with defined configurations (initially inactive)
        fnDriver( SerialPortID1, ( TX_ON | RX_ON ), 0 );                  // enable rx and tx
        if (tInterfaceParameters.usConfig & RTS_CTS) {                   // {8}
            fnDriver( SerialPortID1, (MODIFY_INTERRUPT | ENABLE_CTS_CHANGE), 0 ); // activate CTS interrupt when working with HW flow control (this returns also the present control line states)
            fnDriver( SerialPortID1, (MODIFY_CONTROL | SET_RTS), 0 );     // activate RTS line when working with HW flow control
        }
    }
    return SerialPortID1;
}

If anyone can provide some guidance, that would be great.

Thanks,
Aaron

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uart1 appearing on uart0
« Reply #1 on: March 20, 2009, 02:02:04 AM »
Hi Aaron

I don't see any errors. If I simulate your code it is also fine.

Please check the values of SerialPortID and SerialPortID1. The only way that they could be sending to the same UART if if they have the same value or if the UART was opened twice with the same interface number.

Check carefully that the files with the changed defines are really being used for the build.

Regards

Mark

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: uart1 appearing on uart0
« Reply #2 on: March 20, 2009, 06:19:46 AM »
In the simulator:
SerialPortID = 0x0a
SerialPortID1 = 0x0b

I haven't verified the above on the target, but that's where I discovered the behavior.

When you say the UART was opened twice with the same interface number, do you mean that
Code: [Select]
tInterfaceParameters.Channel = UART1; is set with the wrong value when calling
Code: [Select]

 if ((SerialPortID1 = fnOpen( TYPE_TTY, ucDriverMode, &tInterfaceParameters )) != 0) { // open or change the channel with defined configurations (initially inactive)
??

There wouldn't be anything related to the
Code: [Select]
tInterfaceParameters.Task_to_wake = OWN_TASK; being used in both fnSetNewSerialMode2() and fnSetNewSerialMode()  causing this, could there?

Thanks,
Aaron

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uart1 appearing on uart0
« Reply #3 on: March 20, 2009, 03:37:25 PM »
Hi Aaron


I made a mistake. If the interface is opened more that once with the same interface number it receives the same handle (the interface is not actually opened a second time).

Since you are getting 2 different handles, two different UARTs must be being configured.

It won't be a problem with tInterfaceParameters.Task_to_wake = OWN_TASK; since this is only telling the driver which task to report new input data to. The same task con handle all input data from all UARTs so this is quite normal.

Since the UARTs are always very popular and used in most project, and no such problems have ever been experienced before, I think that you may need to look at the hardware. Is it possible that the UARTs are connected incorrectly? So the UART0 data is also seen at UART1?

Which board are you using?

regards

Mark



Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: uart1 appearing on uart0
« Reply #4 on: March 20, 2009, 04:17:19 PM »
I've tried the M52235evb and my board and the simulator.  I think this means it's in the code somewhere...
I have more details.

On the target everything appears on uart0.

In the simulator I haven't gotten the PC uart to work yet, and am using the telnet connection instead.  In the simulator only messages sent to the DebugHandle are displayed. 

Aaron
« Last Edit: March 20, 2009, 04:34:50 PM by alager »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uart1 appearing on uart0
« Reply #5 on: March 20, 2009, 05:03:27 PM »
Hi Aaron

This is strange but there must be an explanation for it somewhere.

I suggest that you send me your project (set up for the EVB) and I will run it on my EVB.

I'll contact you by email.

Regards

Mark


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: uart1 appearing on uart0
« Reply #6 on: March 30, 2009, 08:09:06 PM »
Hi All

To conclude this thread, the problem was due to the new UART setting not being respected when building the project. That is, the source file depending on the setting was not being compiled.

This type of problem has been experienced several times recently with Codewarrior (and also VisualStudio 2008..) projects. A clean and rebuild usually puts it right again...

Regards

Mark