完成1个工程项目设计，使用STM32F407VGT6芯片，USART1选用了PA9,PA10，板子完成后串口调试总是过不了。不得已使用STM32F4-DISCOVERY通过RS232电平转换连接到PC机串口进行RS232通讯验证。
    首先使用GPIOA-PA9,PA10映射USART1，初始化代码如下：
        RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE);
        RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1,ENABLE);
        GPIO_PinAFConfig(GPIOA,GPIO_PinSource9,GPIO_AF_USART1);
        GPIO_PinAFConfig(GPIOA,GPIO_PinSource10,GPIO_AF_USART1);
         GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9|GPIO_Pin_10;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
        GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
        GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
        GPIO_Init(GPIOA,&GPIO_InitStructure);

        USART_InitStructure.USART_BaudRate = bound;
        USART_InitStructure.USART_WordLength = USART_WordLength_8b;
        USART_InitStructure.USART_StopBits = USART_StopBits_1;
        USART_InitStructure.USART_Parity = USART_Parity_No;
        USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
        USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
       USART_Init(USART1, &USART_InitStructure);
       USART_Cmd(USART1, ENABLE);

     PC机方使用SSCOM,通讯结果是一片乱码。
   后改用PB6,PB7映射USART1,修改相关语句：        RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1,ENABLE); //对不起12楼，我粘贴错了
       RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB,ENABLE);

        GPIO_PinAFConfig(GPIOB,GPIO_PinSource6,GPIO_AF_USART1);
        GPIO_PinAFConfig(GPIOB,GPIO_PinSource7,GPIO_AF_USART1);
         GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6|GPIO_Pin_7;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
        GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
        GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
        GPIO_Init(GPIOB,&GPIO_InitStructure);

       USART初始化相同，不重复了。

从PB口进行，通讯结果一切正常，
查看手册：USART1可以映射到PA9,PA10或PB6,PB7，手册并未特别说明两者使用在USART1有何区别或初始化时需要做何特殊处理。百思不得其解。由于PCB版图已经制作完成，使用PA了口，现在如果从软件方面无法纠正将造成不少的浪费。由于工程板与STM32F4-DISCOVERY板的PA口在USART1工作时出现同样故障，2片板的PA口同时损坏的机率很小，并且2片板的PA9,PA10配置为非USART1模式时工作均正常。
希望得到专家的解答。

watershade 发表于 2015-7-10 22:36
楼主我不明白，那为什么你说PB可以PA不可以。难道你说的是你之前板子的晶振有问题？
又及，你换的是同一 ...

回复楼上，故障经过大概是这样的：我的工程板绘制时USART1是接PA口，无法改接PB口进行验证。8M晶振频率偏高导致通讯失败后，用一片STM32F407DISCOVERY板来对比调试，恰好这片板的PA9连接了一部分外设，其中就有那只C49的电解电容，由于这只电容的滤波作用让PA口输出波形严重失真，得到这片板上的PA口接USART1也是失败的结论，而PB口由于没有那只滤波电容所以通讯成功。
      因为找到STM32F407DISCOVERY板PA口通讯错误的原因，才回过头来查找到工程板是晶振不良引起通讯失败的原因。同样是PA口通讯失败，原因却是不同的。

安 发表于 2015-7-4 16:09
现在用排除法来判断，先通过短接A9 A10，自测收发数据是否正常。
通过代码配置，没有4XX的板子帮忙测试。只 ...

感谢版主的关注。
按照您的建议先短接PA9-PA10做一次PA口的USART1实验，再短接PB6-PB7做一次PB口的USART1实验。分别从发送缓冲区送出22(0x0d,0x0a是结束符）个数据，然后观察接收缓冲区的数据。结果如下：
1、PA口实验
发送缓冲区数据
0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43,0x0d,0x0a

接收缓冲区数据

0x98,0xcc,0xee,0x77,0xf7,0xf7,0xff,0xb8,0xef,0xbd,0xbe,0xff,0x80,0xc0,0xe0,0xf0,0x00,0x00,0x00,0x00,0x00


2、PB口实验
发送缓冲区数据

0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43,0x0d,0x0a

接收缓冲区数据

0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43

//#define P_A_EN 1            //使用PA口或PB口
#define USART_REC_LEN                          22
uint8_t USART_TX_BUF[ USART_REC_LEN]， USART_RX_BUF[ USART_REC_LEN];
uint16_t  USART_RX_STA=0;  
//主函数
int main(void)
{uint8_t i;
        NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);
        uart_init(9600);        
        for(i=0;i<20;i++)USART_TX_BUF=i+0x30;
        USART_TX_BUF[20]=0x0d;
        USART_TX_BUF[21]=0x0a;// 0D0A是给接收中断判断结束的标志
        for(i=0;i<20;i++)
        {
        USART_SendData(USART1,USART_TX_BUF);
        while(USART_GetFlagStatus(USART1,USART_FLAG_TC)!=SET);
        }
        __nop();
        while(1){;};

}

//usart初始化函数
void uart_init(uint32_t  bound)
{  GPIO_InitTypeDef GPIO_InitStructure;
   USART_InitTypeDef USART_InitStructure;
   NVIC_InitTypeDef NVIC_InitStructure;
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1,ENABLE);
#ifdef  P_A _EN
        {
        RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA,ENABLE);
        GPIO_PinAFConfig(GPIOA,GPIO_PinSource9,GPIO_AF_USART1);
        GPIO_PinAFConfig(GPIOA,GPIO_PinSource10,GPIO_AF_USART1);
        GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9|GPIO_Pin_10;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;        
        GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
        GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
        GPIO_Init(GPIOA,&GPIO_InitStructure);
        }
#else
        {
        RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB,ENABLE);
        GPIO_PinAFConfig(GPIOB,GPIO_PinSource6,GPIO_AF_USART1);
        GPIO_PinAFConfig(GPIOB,GPIO_PinSource7,GPIO_AF_USART1);
        GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6|GPIO_Pin_7;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;        
        GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
        GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
        GPIO_Init(GPIOB,&GPIO_InitStructure);
        }
#endif
        USART_InitStructure.USART_BaudRate = bound;
        USART_InitStructure.USART_WordLength = USART_WordLength_8b;
        USART_InitStructure.USART_StopBits = USART_StopBits_1;
        USART_InitStructure.USART_Parity = USART_Parity_No;
        USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
        USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
        USART_Init(USART1, &USART_InitStructure);
        USART_Cmd(USART1, ENABLE);
        USART_ClearFlag(USART1, USART_FLAG_TC);
        USART_ITConfig(USART1, USART_IT_RXNE, ENABLE);
        NVIC_InitStructure.NVIC_IRQChannel = USART1_IRQn;
        NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority=3;
        NVIC_InitStructure.NVIC_IRQChannelSubPriority =3;
        NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
        NVIC_Init(&NVIC_InitStructure);        
}
//接收中断函数
void USART1_IRQHandler(void)
{
        uint8_t  Dat;
        if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)
        {
                 Dat =USART_ReceiveData(USART1);
                if((USART_RX_STA&0x8000)==0)
                {
                        if(USART_RX_STA&0x4000)
                        {
                                if(Dat!=0x0a)USART_RX_STA=0;
                                else USART_RX_STA|=0x8000;
                        }
                        else
                        {        
                                if( Dat==0x0d)USART_RX_STA|=0x4000;
                                else
                                {
                                        USART_RX_BUF[USART_RX_STA&0X3FFF]= Dat ;
                                        USART_RX_STA++;
                                        if(USART_RX_STA>(USART_REC_LEN-1))USART_RX_STA=0;
                                }                 
                        }
                }                    
  }


从上面接收数据判断，有可能是使用库函数对PA口进行波特率设置未能达到预设波特率值，而对PB口设置则能得到正确波特率。

发现STM32F4-DISCOVERY的PA口数据出错后，认为还是用数据来说话。临时编写一段代码，每隔0.1秒从发送端发送一次0x55,然后用示波器来观察数据发送状况。
    先在正常的PB口测试，结果见图1。

            图1  STM32F4-DISCOVERY PB口正常的发送波形
    而从非正常的PA口发送，结果见图2.

  图2  STM32F4-DISCOVERY PA口非正常的发送波形
    可以看到从PA口发送的数据严重变形，当然出现错码。查STM32F4-DISCOVERY手册，PA9,PA10是可以映射到USART1的，见图3。但是查看原理图，发现PA9在STM32F4-DISCOVERY板上已经外挂了不少外设，让它工作在USART1，不把这些外设断开肯定不行的。

       图3  STM32F4-DISCOVERY PA口说明         



                图4  STM32F4-DISCOVERY PA9
    从以上实验可以得出第一个结论：
    关于在STM32F4-DISCOVERY上使用PA口工作在USARU1不成功的原因是由于PA9上已经外挂了其他外设，发送端发送的数据在低电平时被这些外设拉高，从而出现图2所示非正常波形而导致通讯失败。
    教训：花点时间读读手册是很有用的，如果先读了手册再来调试，就不会走那么多弯路，时间反而会节省不少。
    接下来还要解决工程板的故障，才是最终目的。
同样对工程板的USART1发送端进行测试，发送0X55时的波形见图5，从图5中我们可以看出，发送的波形基本是正常的，但周期确比图2（3.8格）的要短(3.4格）。

  图5 工程板的波形
   可见工程板工作不正常的原因是波特率偏高了。本例中波特率设定为9600，于是试将工程板的波特率降低看看，当降到9000时，USART的工作竟然正常了。天哪：竟然误差16%。先看看晶振再说。
图6  STM32F4-DISCOVERY上的晶振频率8.00063 MHZ

图7 工程板上的晶振频率 8.00065 MHZ
    晶振误差很小呀！这16%的波特率误差从何而来一时无法理解，如果找到原因一定再贴上来与大家分享。哪位网友有高招也欢迎赐教。
结论2：工程板上的通讯乱码是由于波特率误差太大所引起的，但同样的配置，误差达到16%确实从来没遇到过。而当在用 STM32F4-DISCOVERY验证时，恰好也是PA口的外挂引起工作不正常，让我误认为STM32F407的PA口用在USART1上会有问题，才有本帖的主题出现，按理应该改成《STM32F407 串行通讯USART1故障排除一例》，算了，就保持原来的也无妨。

刚学没用过标准库，试试cubeMX产生的工程如何?

不可能，是没配置好

stary666 发表于 2015-7-4 00:36
不可能，是没配置好

回复楼上：都是同样的配置，只是更改PA或PB,结果确实不一样。应该不是你说的没配置好。帖子中修改PB6,PB7的配置，与PA9,PA10相同的语句就没有列出了。只把有变动的用红色标记列出而已。

可能是代码没有配置好吧        

你有用到TIMER吗?

momososo 发表于 2015-7-4 10:59
你有用到TIMER吗?

评估时就只用USART,任何中断都不用（包括USART接收中断），使用的是同一台硬件，在PB口发送正常，也可以正常使用接收中断，使用PA口就是不行。

今天把通讯代码移植到F1系列评估板上，使用PA9,PA10通讯也很正常。
在这里把硬件连接图也贴上来：

可能是你其它代码冲突,你去掉所有代码只留下串口1的代码调试下是否能通过

mark0668 发表于 2015-7-4 13:58
可能是你其它代码冲突,你去掉所有代码只留下串口1的代码调试下是否能通过 ...

谢谢楼上，我就是只用USART，其他都不用，而且是在同一台开发板的不同GPIO口得到不同结果。

随便问一下，你的PA9和PA10确定是只连接到了max3232，有没有可能是硬件上PA9和PA10有问题。或者和附近的走线有没有关联。

一种好的办法是你找块F4的经得起验证的板子试一下。乱码问题一般是硬件的问题。比如直接用ttl当作rs232输入输出都会造成乱码（又是不是烧掉）。

wenyangzeng 发表于 2015-7-4 14:01
谢谢楼上，我就是只用USART，其他都不用，而且是在同一台开发板的不同GPIO口得到不同结果。 ...

看到你两个时钟有什么不同了吗? 第二个改错地方,串口1时钟没使能,

mark0668 发表于 2015-7-4 14:09
看到你两个时钟有什么不同了吗? 第二个改错地方,串口1时钟没使能,
...

谢谢楼上，我粘贴错了：
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1,ENABLE); //对不起，粘贴错了
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB,ENABLE);

watershade 发表于 2015-7-4 14:06
随便问一下，你的PA9和PA10确定是只连接到了max3232，有没有可能是硬件上PA9和PA10有问题。或者和附近的走 ...

我就是在工程板无法正常的情况下换用一片STM32F4-DISCOVERY来评估的。

现在用排除法来判断，先通过短接A9 A10，自测收发数据是否正常。
通过代码配置，没有4XX的板子帮忙测试。只能通过代码分析，也可以参考网友用STM32CubeMX测试一下。