• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 339 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2633: The problem of serial port multiplexing into automatic baud rate detection mode (LIN)

Green Deng
Expert 4490 points
Part Number: MSP430FR2633

Dear team:

Regarding the detection of the break frame header, the break can be correctly detected when the following configuration is currently performed:

Tsynbrk = 13, Tsyndel = 1/5/10

But there are two configurations that will not detect break:

Tsynbrk = 13, Tsyndel = 14

Tsynbrk = 26, Tsyndel = 1

The following is the configuration code:

const tUARTPort g_myLINPort =
{
.pbReceiveCallback = &LINreceiveHandler,
.pbErrorCallback = &LINerrorHandler,
.peripheralParameters.selectClockSource = EUSCI_A_UART_CLOCKSOURCE_SMCLK,//EUSCI_A_UART_CLOCKSOURCE_UCLK, //EUSCI_A_UART_CLOCKSOURCE_SMCLK,
.peripheralParameters.clockPrescalar = 6, //26,
.peripheralParameters.firstModReg = 8, //0,
.peripheralParameters.secondModReg = 0x11, //0xB6,
.peripheralParameters.parity = EUSCI_A_UART_NO_PARITY,
.peripheralParameters.msborLsbFirst = EUSCI_A_UART_LSB_FIRST,
.peripheralParameters.numberofStopBits = EUSCI_A_UART_ONE_STOP_BIT,
.peripheralParameters.uartMode = EUSCI_A_UART_AUTOMATIC_BAUDRATE_DETECTION_MODE,//EUSCI_A_UART_AUTOMATIC_BAUDRATE_DETECTION_MODE
.peripheralParameters.overSampling = EUSCI_A_UART_OVERSAMPLING_BAUDRATE_GENERATION //EUSCI_A_UART_LOW_FREQUENCY_BAUDRATE_GENERATION//EUSCI_A_UART_OVERSAMPLING_BAUDRATE_GENERATION
};

void LIN_GPIO_Init(void)
{
P1OUT = (0);
P1DIR = (0);//(GPIO_PIN0 | GPIO_PIN6 | GPIO_PIN7);
P1SEL0 = (GPIO_PIN4 | GPIO_PIN5); //(GPIO_PIN2 | GPIO_PIN3 | GPIO_PIN4 | GPIO_PIN5);
P1SEL1 = (0);

LIN_EN_POUT |= LIN_EN_PIN;
LIN_EN_PDIR |= LIN_EN_PIN;
LIN_EN_ON;
}

void LIN_Init(void)
{
LIN_GPIO_Init();
UART_openPort(&g_myLINPort);
}

void UART_openPort(const tUARTPort *pPort)
{
UART_closePort();
g_pUARTPort = pPort;
UCA0CTLW0 |= UCSWRST; //reset UART0

MAP_EUSCI_A_UART_init(
UART__EUSCI_A_PERIPHERAL,
(EUSCI_A_UART_initParam*)&(g_pUARTPort->peripheralParameters)
);
UCA0CTLW0 |=UCBRKIE; //打开break 中断
UCA0CTLW0 &= ~UCDORM;//Not dormant. All received characters will set UCAxRXIFG
MAP_EUSCI_A_UART_enable(UART__EUSCI_A_PERIPHERAL);
MAP_EUSCI_A_UART_clearInterrupt(
UART__EUSCI_A_PERIPHERAL,
EUSCI_A_UART_RECEIVE_INTERRUPT_FLAG
);
MAP_EUSCI_A_UART_enableInterrupt(
UART__EUSCI_A_PERIPHERAL,
EUSCI_A_UART_RECEIVE_INTERRUPT
);
MAP_EUSCI_A_UART_enableInterrupt(
UART__EUSCI_A_PERIPHERAL,
EUSCI_A_UART_BREAKCHAR_INTERRUPT
);
g_UARTStatus = eUARTIsIdle;
}

Best regards

  • 0
    TI__Mastermind 49692 points

    Hi Green,

    I'll assume Tsynbrk is the period for the break bits, and Tsyndel is the period for the delimiter bits. These two configurations may actually violate the LIN bus timing. For the first configuration, Tsyndel is longer than Tsynbrk, which may not be allowed by the LIN bus timing. For the second configuration, Tsynbrk is more than 21 bit times, which according to the user's guide, if the length of the break exceeds 21 bit times, the break timeout error flag UCBTOE is set.

  • 0 in reply to James Evans
    Prodigy 40 points

    Hi James,

    Maybe we should express our doubts in another way. Does the instructions in the user manual mean that the Tsynbrk+Tsyndel more than 21 bits is not recognized as a valid break field at the hardware level? That is, if the customer requires us to support up to 27 bit time break fields, we cannot use fr2633 to implement?

  • 0 in reply to guoli zhong
    TI__Mastermind 49692 points

    Hello,

    The 21 bit limitation mentioned in the user's guide applies to Tsynbrk only. Tsyndel is typically 1 bit (nominal). If more than 21 bits are required for Tsynbrk, the automatic baud rate detection feature of the eUSCI module cannot be used. Otherwise, a software approach using GPIO(s) and a timer module would need to be implemented manually on the MSP430FR2633.

  • 0 in reply to James Evans
    Prodigy 40 points

    Hi James:

    So it seems that the hardware design of this chip supports Tsynbrk = 13, Tsyndel = 14?However, we actually use the Lin network diagnosis tool to test that ucbrk is not set under this parameter setting.

  • 0 in reply to guoli zhong
    TI__Mastermind 49692 points

    Hello,

    I would expect that the device can support Tsynbrk = 13 bits, but I could not find any guidance on the maximum allowable Tsyndel bits. Like I mentioned earlier, the nominal number of bits for Tsyndel is typically 1 bit. I will check internally if there is any other guidance I can share with you on this topic.

**Attention** This is a public forum