STM32 Прерывание UART, Странное поведение Опции

[Vladimir Prokofi...]

Простой модуль чтения данных с GPS, из проекта выкинул все, кроме uart драйвера и парсера сообщений UBX. (Ublox gps protocol), STM415 стоит, но софт везде работает с ним как с 215 ( Это не влияет, я это ловил и на настоящих 215 )

Настройка порта:

CODE

case USART6_BASE:

#ifdef USE_IN_UART6_BUFFER
UART6_InputBufWR = 0;
UART6_InputBufRD = 0;
#endif

#ifdef USE_OUT_UART6_BUFFER
UART6_OutputBufWR = 0;
UART6_OutputBufRD = 0;
#endif

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART6, ENABLE);

GPIO_PinAFConfig(GPIOC, GPIO_PinSource6, GPIO_AF_USART6);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource7, GPIO_AF_USART6);

GPIO_Init_Struct.GPIO_Pin = GPIO_Pin_6;
GPIO_Init_Struct.GPIO_Mode = GPIO_Mode_AF;
GPIO_Init_Struct.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init_Struct.GPIO_OType = GPIO_OType_PP;
GPIO_Init_Struct.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_Init_Struct);

GPIO_Init_Struct.GPIO_Pin = GPIO_Pin_7;
GPIO_Init_Struct.GPIO_OType = GPIO_OType_OD;
GPIO_Init_Struct.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_Init_Struct);

#if defined (USE_IN_UART6_BUFFER) || defined (USE_OUT_UART6_BUFFER)
NVIC_InitStructure.NVIC_IRQChannel = USART6_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = UART6_PreemptionPriority;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = UART6_SubPriority;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
#endif
#ifdef USE_IN_UART6_BUFFER
USART_ITConfig(USARTx, USART_IT_RXNE, ENABLE);
//USART_ITConfig(USARTx, USART_IT_ORE, ENABLE);
#endif

break;
}

USART_Init_Struct.USART_BaudRate = Baudrate;
USART_Init_Struct.USART_WordLength = USART_WordLength_8b;
USART_Init_Struct.USART_StopBits = USART_StopBits_1;
USART_Init_Struct.USART_Parity = USART_Parity_No;
USART_Init_Struct.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
USART_Init_Struct.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_Init(USARTx, &USART_Init_Struct);

USART_Cmd(USARTx,ENABLE);

Прерывание:

CODE

void USART6_IRQHandler(void)
{
if(USART_GetITStatus(USART6, USART_IT_TXE) != RESET)
{
#ifdef USE_OUT_UART6_BUFFER

if(UART6_out_counter != 0)
{
UART6_out_counter--;
USART_SendData(USART6,(uint16_t) UART6_OutputBuf[UART6_OutputBufRD]);

if(UART6_OutputBufRD >= (UART6_OutputBuf_size - 1))
{
UART6_OutputBufRD = 0;
}
else
{
UART6_OutputBufRD++;
}
} else {
USART_ITConfig(USART6, USART_IT_TXE, DISABLE);
isTxDone6 = 1;
#endif
}
} else if(USART_GetITStatus(USART6, USART_IT_RXNE) != RESET)
{
USART6->SR;
#ifdef USE_IN_UART6_BUFFER

uint8_t read_UART;

read_UART = USART_ReceiveData(USART6);
#ifdef FATFS_ON
GPSLOGGER_PushByte( read_UART );
#endif



if(UART6_in_counter < UART6_InputBuf_size)
{
UART6_InputBuf[UART6_InputBufWR] = read_UART;

if(UART6_InputBufWR == (UART6_InputBuf_size - 1))
{
UART6_InputBufWR = 0;
}
else
{
UART6_InputBufWR++;
}
UART6_in_counter++;
}
#endif
}else {
USART6->SR;
USART6->DR;
}

USART_ClearFlag( USART6, USART_FLAG_CTS | USART_FLAG_LBD | USART_FLAG_RXNE | USART_IT_TC );
}

Ну тык вот, есть странности (скорость 200к). Самый главный вопрос, почему мы иногда попадаем в последний else, выполняя
USART6->SR;
USART6->DR;


При этом, это должно было быть прерывание RX, НО RXNEIE = 0! Все остальные биты такие-же как и при нормальном прерывании.

Еще странность что ORE почти всегда 1.

В GPSLOGGER_PushByte есть глобальное разрешение и запрещение прерывания, но функция просто просто байт сохраняет:

CODE

inline void GPSLOGGER_PushByte( uint8_t b ){
__disable_irq();
if( sizebuf[curBuf] < LOGBUFSIZE ){
logbuf[ curBuf ][ sizebuf[curBuf] ] = b;
}
sizebuf[ curBuf ] ++;
__enable_irq();
}

Сообщение отредактировал Vladimir Prokofiev - Feb 20 2014, 10:40

[adnega]

С USART_SR_RXNE Вы правы - он у меня определен как номер бита, а не как маска.
По сложности могу усилить и другими блоками, но они будут работать параллельно и вряд ли это окажет влияния.
Можно DMA врубить для усложнения, но насколько я понял, гипотеза была в том, что флаг не успевает за периферией.
Я даже на асме хотел написать обработчик, чтоб было максимально быстрое обращение к USART->SR.
Насчет разброса частоты UART согласен, что ошибка нулевая. Но как мне кажется при допустимом уровне рассогласования все будет работать,
при превышении уровня - все перестанет работать. У меня тоже на тестовой плате USART2 тактруется от 36МГц. На второй стороне у Вас
какое устройство? С какой расчетной частотой? Могу добавить еще одну отладку с "удачным" кварцем на 11.0592МГц, который даст точные
115200. Я за то, что USART у STM32F103 не глючит, хотя в более поздних процах USART заметно поменялся, но это скорее усовершенствование
блока, чем латание дыр. Может все-таки в программе (или компиляторе) проблемы, а может железо сбоит. Заметил, что преобразователь USB-COM TTL
работает стабильнее, если подключать его через последовательные сопротивления (иначе на осциллографе вижу выбросы вверх или вниз аж под 1.5В).

[KnightIgor]

С USART_SR_RXNE Вы правы - он у меня определен как номер бита, а не как маска.

Интересно, зачем. Это же конфликт с CMSIS-согласованным файлом stm32f10x.h

На второй стороне у Вас какое устройство? С какой расчетной частотой?

WiFi-"модем" HLK-RM04. Там внутри Ralink RT5350F и кварц, по которому не видно, сколько MHz. Но еще раз: после добавления заплатки, действие которой заключается либо в задержке, либо в предварительном "тупом" чтении регистра SR, ошибка спорадической потери байтов забилась в угол до такой степени, что мы вчера в течение долгих тестов не смогли ее обнаружить.

[adnega]

Интересно, зачем. Это же конфликт с CMSIS-согласованным файлом stm32f10x.h

WiFi-"модем" HLK-RM04. Там внутри Ralink RT5350F и кварц, по которому не видно, сколько MHz. Но еще раз: после добавления заплатки, действие которой заключается либо в задержке, либо в предварительном "тупом" чтении регистра SR, ошибка спорадической потери байтов забилась в угол до такой степени, что мы вчера в течение долгих тестов не смогли ее обнаружить.

Насчет битиков ответ простой: я не пользуюсь сторонними библиотеками.

Насчет UARTа я пока уверен, что накакие заплатки не нужны, т.к. железо работает отлично. Но если у Вас есть желание переубедить меня, то
я с радостью помогу. Ибо я лучше сейчас огребу, чем в будущем. В свое время я сталкивался с потерей байт, но не придавал этому особого значения.
Старался писать код не чувствительным к таким потерям (точнее допускающим редкие потери с гарантированным восстановлением за конкретное время/
число перепосылок). Сейчас, когда начал копаться детально (где-то месяц назад), понял, что так или иначе аппаратура не виновата в потерях - виноват
исключительно софт. Если Вы считаете вопрос решенным (для своего круга задач), то, думаю, и копать дальше не стоит (меня тоже сейчас все устраивает).