文章目录[隐藏]
最近使用NXP9080MCU的串口，使用921600波特率通信，发现几个大坑，记录之~。
坑1:波特率不准
调试过程中发现，115200可正常通信，修改波特率为921600后出现各种问题。抓取波形后确定为MCU问题。遂查看datesheet：
908x的串口时钟来源：外部或内部晶振->systemcore时钟->AHB->Flexcomm接口->USART 。
这里较于其他MCU比较特殊的是有一个Flex接口，多通信方式接口（SPI I2C)。可通过配置FRG寄存器来获取更精确的波特率。计算方式：Flexcomm interface clock: (FRG input clock) / (1+ (MULT / DIV))，DIV为0XFF，MULT可配置，这样分频系数变成了一个1~2之间的小数，再通过USART的波特率分频寄存器便可获得更精确的波特率： baud rate: [FCLK / (OSRVAL+ 1)] / (BRGVAL + 1)。
配置FRG:
CLOCK_SetFRGClock(kCLOCK_DivFrg0,
FLEXCOMM_CLK((CLOCK_GetFreq(kCLOCK_BusClk)),
gUARTBaudRate921600_c));
坑2：丢数据
调试BLE的SDK时发现，串口在921600时，一次接收100个字节以上会丢包。查看SDK串口底层实现方式：有一个专门的串口任务，套了两层回调接收函数，触发事件的方式来接收（原厂的代码确实美观）。最底层还是通过接收中断来触发的，即一个字节触发一次中断（什么？原厂居然用这么LOW的方法）。应该就是速率变高，一次接收数据较大时，中断过于频繁导致。只能说Fuck中断，开始调DMA接收。
坑3 DMA的DEMO的错误
波特率分频不准：
调DMA的DEMO时发现，速率高时有无法通信，可是已经配置了小数分频了啊。最终发现波特率寄存器配置不准，查看波特率配置函数，对比计算准确的代码。
计算错误：
brgval = (((srcClock_Hz * 10) / ((osrval + 1) * baudrate_Bps)) - 5) / 10;
计算正确：
brgval = (srcClock_Hz / ((osrval + 1) * baudrate_Bps)) - 1;
DMA获取当前接收数据错误：
uint32_t DMA_GetRemainingBytes(DMA_Type *base, uint32_t channel)
{
assert(channel < FSL_FEATURE_DMA_NUMBER_OF_CHANNELS);
/* NOTE: when descriptors are chained, ACTIVE bit is set for whole chain. It makes
* impossible to distinguish between:
* - transfer finishes (represented by value '0x3FF')
* - and remaining 1024 bytes to transfer (value 0x3FF)
* for all descriptor in chain, except the last one.
* If you decide to use this function, please use 1023 transfers as maximal value */
/* Channel not active (transfer finished) and value is 0x3FF - nothing to transfer */
if (
(!(base->COMMON[DMA_CHANNEL_GROUP(channel)].ACTIVE & (1U << (DMA_CHANNEL_INDEX(channel))))) &&
(0x3FF == ((base->CHANNEL[channel].XFERCFG & DMA_CHANNEL_XFERCFG_XFERCOUNT_MASK) >> DMA_CHANNEL_XFERCFG_XFERCOUNT_SHIFT))
)
{
return 0;
}
return base->CHANNEL[channel].XFERCFG + 1;
}
要改为
uint32_t k = base->CHANNEL[channel].XFERCFG>>16;
k = k+1;
return k;
总结
一个串口出现这么多问题，基本都是波特率调到最高发生的，一般115200就好。
版权声明：本文为CSDN博主「占毛毛」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_40570010/article/details/122250153
最近使用NXP9080MCU的串口，使用921600波特率通信，发现几个大坑，记录之~。
坑1:波特率不准
调试过程中发现，115200可正常通信，修改波特率为921600后出现各种问题。抓取波形后确定为MCU问题。遂查看datesheet：
908x的串口时钟来源：外部或内部晶振->systemcore时钟->AHB->Flexcomm接口->USART 。
这里较于其他MCU比较特殊的是有一个Flex接口，多通信方式接口（SPI I2C)。可通过配置FRG寄存器来获取更精确的波特率。计算方式：Flexcomm interface clock: (FRG input clock) / (1+ (MULT / DIV))，DIV为0XFF，MULT可配置，这样分频系数变成了一个1~2之间的小数，再通过USART的波特率分频寄存器便可获得更精确的波特率： baud rate: [FCLK / (OSRVAL+ 1)] / (BRGVAL + 1)。
配置FRG:
CLOCK_SetFRGClock(kCLOCK_DivFrg0,
FLEXCOMM_CLK((CLOCK_GetFreq(kCLOCK_BusClk)),
gUARTBaudRate921600_c));
坑2：丢数据
调试BLE的SDK时发现，串口在921600时，一次接收100个字节以上会丢包。查看SDK串口底层实现方式：有一个专门的串口任务，套了两层回调接收函数，触发事件的方式来接收（原厂的代码确实美观）。最底层还是通过接收中断来触发的，即一个字节触发一次中断（什么？原厂居然用这么LOW的方法）。应该就是速率变高，一次接收数据较大时，中断过于频繁导致。只能说Fuck中断，开始调DMA接收。
坑3 DMA的DEMO的错误
波特率分频不准：
调DMA的DEMO时发现，速率高时有无法通信，可是已经配置了小数分频了啊。最终发现波特率寄存器配置不准，查看波特率配置函数，对比计算准确的代码。
计算错误：
brgval = (((srcClock_Hz * 10) / ((osrval + 1) * baudrate_Bps)) - 5) / 10;
计算正确：
brgval = (srcClock_Hz / ((osrval + 1) * baudrate_Bps)) - 1;
DMA获取当前接收数据错误：
uint32_t DMA_GetRemainingBytes(DMA_Type *base, uint32_t channel)
{
assert(channel < FSL_FEATURE_DMA_NUMBER_OF_CHANNELS);
/* NOTE: when descriptors are chained, ACTIVE bit is set for whole chain. It makes
* impossible to distinguish between:
* - transfer finishes (represented by value '0x3FF')
* - and remaining 1024 bytes to transfer (value 0x3FF)
* for all descriptor in chain, except the last one.
* If you decide to use this function, please use 1023 transfers as maximal value */
/* Channel not active (transfer finished) and value is 0x3FF - nothing to transfer */
if (
(!(base->COMMON[DMA_CHANNEL_GROUP(channel)].ACTIVE & (1U << (DMA_CHANNEL_INDEX(channel))))) &&
(0x3FF == ((base->CHANNEL[channel].XFERCFG & DMA_CHANNEL_XFERCFG_XFERCOUNT_MASK) >> DMA_CHANNEL_XFERCFG_XFERCOUNT_SHIFT))
)
{
return 0;
}
return base->CHANNEL[channel].XFERCFG + 1;
}
要改为
uint32_t k = base->CHANNEL[channel].XFERCFG>>16;
k = k+1;
return k;
总结
一个串口出现这么多问题，基本都是波特率调到最高发生的，一般115200就好。
版权声明：本文为CSDN博主「占毛毛」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_40570010/article/details/122250153
暂无评论