2015-10-13 1 views
2

Je travaille avec STM32F427 UASRT1 par la classe suivante:USART1 de STM32F427 met parfois 8 bit de données comme si ce serait bit de parité

void DebugUartOperator::Init() { 
    // for USART1 and USART6 
    ::RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE); 
    // USART1 via PORTA 
    ::RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE); 

    ::GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_USART1); 
    ::GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_USART1); 

    GPIO_InitTypeDef GPIO_InitStruct; 

    // fills the struct with the default vals: 
    // all pins, mode IN, 2MHz, PP, NOPULL 
    ::GPIO_StructInit(&GPIO_InitStruct); 

    // mission-specific settings: 
    GPIO_InitStruct.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_10; 
    GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF; 
    ::GPIO_Init (GPIOA, &GPIO_InitStruct); 

    USART_InitTypeDef USART_InitStruct; 

    // 9600/8/1/no parity/no HWCtrl/rx+tx 
    ::USART_StructInit(&USART_InitStruct); 

    USART_InitStruct.USART_BaudRate = 921600; 
    USART_InitStruct.USART_WordLength = USART_WordLength_9b; 
    USART_InitStruct.USART_StopBits = USART_StopBits_1; 
    USART_InitStruct.USART_Parity = USART_Parity_Odd; 
    ::USART_Init(USART1, &USART_InitStruct); 

    ::USART_Cmd(USART1, ENABLE); 
    } 

void DebugUartOperator::SendChar(char a) { 
    // wait for TX register to become empty 
    while(::USART_GetFlagStatus(USART1, USART_FLAG_TXE) != SET); 
    ::USART_SendData(USART1, static_cast<uint8_t>(a)); 
    } 

Le problème est que chaque maintenant et puis USART commence en ignorant les données 8e réelles bit et en le définissant comme un bit de parité (parité impaire, pour être spécifique). Le plus étrange de tout cela arrive parfois même après un long coup de courant, sans reprogrammation préalable ou quelque chose. Par exemple, hier soir, tout s'est bien passé, puis le lendemain matin je suis venu travailler, allumer l'appareil et commencer à travailler de la manière décrite. Mais cela ne se limite pas à cela, il peut apparaître au hasard après un prochain redémarrage.

Cet effet est clairement visible avec l'oscilloscope et avec différents convertisseurs UART-USB utilisés avec différents programmes. Il est même possible, une fois cet effet apparu, de reprogrammer un microcontrôleur pour transmettre des jeux de données de test. Par exemple, 0x00 à 0xFF en cycle sans fin. Cela n'affecte pas le problème. Le changement de vitesse (jusqu'à 9600 bps), le nombre de bits par mot, le contrôle de parité n'aide pas - l'effet reste intact même après la reprographie (résultant par exemple en 2 bits de parité vraiment anormaux par octet). Ou, au moins, pendant que UASRT est initialisé et utilisé dans l'ordre habituel en fonction du flux de travail de mon programme.

La seule façon de résoudre ce problème est de rendre la fonction principale() procédez comme suit:

int main() { 
    DebugUartOperator dua; 
    dua.Init(); 
    while(1) { 
     uint8_t i; 
     while(++i) 
      dua.SendChar(i); 
     dua.SendChar(i); 
     } 
    } 

Avec cela, après la reprogrammation et le redémarrage, les premiers octets (jusqu'à 5) sont transmis pourris, mais alors tout fonctionne plutôt bien et continue de bien fonctionner grâce à d'autres redémarrages et reprogrammations.

Cet effet est observé sur 2 différents STM32F427 s sur 2 cartes physiquement différentes de la même mise en page. Aucune régularité n'est remarquée dans son apparence. La polarité du signal et les niveaux sont conformes aux exigences USART, aucun bruit ou mauvais contact ne sont détectés pendant l'investigation. Il semble y avoir aucune affection à UASRT1 de la direction d'un autre code utilisé dans mon programme (que ce soit le mien ou celui de la bibliothèque) ou il est enterré profondément. CMSIS-OS est utilisé comme RTOS dans le projet, avec KeiluVision 5.0.5RTX OS.

Besoin d'aide.

+0

Salut Vasily, désolé, je ne vois pas votre vraie question ici. Vous dites que _USART commence à ignorer le 8ème bit de données réel et à le définir comme un bit de parité (parité impaire, pour être spécifique). Mais vous avez configuré 'USART_InitStruct.USART_Parity = USART_Parity_Odd;' Est-ce le problème? – EricPb

+0

Malheureusement pas. J'ai mentionné plus tard que «changer ... le contrôle de parité n'aide pas»: j'ai essayé les deux modes impairs et pairs, ainsi que pas de mode de parité, 8 ou 9 bits de largeur - non, l'effet reste une fois arrivé . –

+0

Intéressant cependant que, après avoir éliminé mon autre problème de fuite de ressources dans CMSIS-RTOS (http://stackoverflow.com/questions/32995099/cmsis-rtoss-osmailfree-returns-some-address-instead-of-osstatus-type -value) le problème discuté a également disparu. Ou, au moins, cet effet n'apparaît plus pendant un temps considérable. –

Répondre

0

Dans STM, vous pouvez spécifier la longueur de mot pour la transmission usart/uart mais la longueur de mot est une somme de bits de données et de parité de bits. Donc, si vous souhaitez avoir des données de 8 bits et même un bit de parité, vous devez spécifier UART_WORDLENGTH_9B et UART_PARITY_EVEN.

Vous pouvez également avoir 9 bits de données, sans parité. Dans le manuel de référence pour F427 section 30.6.4, Bit 12, nous voyons qu'il devrait être possible de définir 9 bits de données, mais le terme data bits est également applicable au bit de parité.

Bit 12M: Longueur de mot
Ce bit détermine la longueur de mot. Il est défini ou effacé par le logiciel.
0: 1 bit de départ, 8 bits de données, n Bit d'arrêt
1: 1 bit de départ, 9 bits de données, n Bit d'arrêt

La réponse finale est 30.6.4, Bit 10

Ce bit sélectionne le contrôle de parité matérielle (génération et détection ).Lorsque le contrôle de parité est activé, la parité calculée est insérée à la position MSB (9ième bit si M = 1, 8ième bit si M = 0) et la parité est vérifiée sur les données reçues. Ce bit est défini et effacé par le logiciel . Une fois le réglage effectué, PCE est actif après l'octet courant (en réception et en émission).