次のクラスを介してSTM32F427
UASRT1 を使用しています。
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));
}
問題は、時々 USART が実際の 8 番目のデータ ビットを無視し始め、それをパリティ ビット (具体的には奇数パリティ) として設定し始めることです。最も奇妙なのは、事前の再プログラミングなどを行わなくても、長い電源オフの後でも時々発生することです。たとえば、昨日の夜はすべて問題ありませんでしたが、翌朝、仕事に来てデバイスの電源を入れると、説明されている方法で動作し始めます. ただし、これに限定されず、次の再起動後にランダムに表示される場合があります。
その効果は、オシロスコープや、さまざまなプログラムで使用されるさまざまな UART-USB コンバーターではっきりと確認できます。この効果が現れると、テスト データ セットを送信するようにマイクロコントローラを再プログラムすることさえ可能です。たとえば、エンドレス サイクルで 0x00 から 0xFF まで。問題には影響しません。速度の変更 (9600 bps まで)、ワードあたりのビット数、パリティ制御は役に立ちません - 再プログラミング後も効果はそのまま残ります (たとえば、1 バイトあたり 2 パリティ ビットという異常な値が発生します)。または、少なくとも、UASRT が初期化され、プログラムのワークフローに従って通常の順序で使用されている間。
これを修正する唯一の方法は、main() 関数を次のようにすることです。
int main() {
DebugUartOperator dua;
dua.Init();
while(1) {
uint8_t i;
while(++i)
dua.SendChar(i);
dua.SendChar(i);
}
}
これにより、再プログラミングと再起動の後、最初の数バイト (最大 5) が不正に送信されますが、その後はすべてがうまく機能し、さらに再起動と再プログラムを繰り返しても引き続きうまく機能します。
STM32F427
この影響は、同じレイアウトの 2 つの物理的に異なるボード上の2 つの異なる で観察されます。外観に規則性は見られません。信号の極性とレベルは USART 要件に準拠しており、調査中にノイズや接触不良は検出されません。私のプログラムで使用されている他のコード (私のプログラムまたはライブラリーのいずれか) の方向から UASRT1 への愛情がないように思われるか、深く埋もれています。CMSIS-OS
は、プロジェクトで RTOS として使用されKeil
uVision 5.0.5
ますRTX OS
。
助けが必要。