|
本帖最后由 jjj 于 2019-1-21 17:52 编辑
最近调试LPC4357的USB接口,出现一个很棘手的问题,拷贝文件时,莫名其妙的拷贝失败,这个问题如果不解决的话,即使将来用在产品上,肯定会有问题的,早晚会暴发,于是我就好好的研究了一下这个USB协议栈,LPC4357官方例程LPCOPEN使用的是Dean Camera开发的LUFA(The Lightweight USB Framework for AVRs),应该是在这上面修改而成的,令我吃惊的LUFA的作者Dean Camera,这个家伙居然很年轻,还没有我大,因为我之前常用的比如LWIP、FATFS都是一些老家伙(老教授)开发的,没想到这么年轻开发的软件居然入了大公司NXP的法眼,于是NXP在此基础上专门给LPCXXXX系列单片机做了修改,终于2012年成了“Copyright(C) NXP Semiconductors, 2012”
膜拜也好、惊叹也好,问题还得解决,LPC4357片子用的是通用的EHCI主机,这与我熟悉的STM32单片机不一样,我本来是不打算深究的,但是我简单查了一下EHCI控制器相关的资料,发展EHCI规范是INTER制定的,这个USB主机才是主流的,通用的,好多单片机、ARM的USB外设都是兼容EHCI的,而STM32的USB控制器我也没有找到来源,估计是ST公司自己设计的吧,很显然,研究EHCI的工作原理要比STM32的USB更有前景。
于是我从网上找了很多EHCI的资料,有中文的、有准备的英文规范,《USB2.0与OTG规范及开发指南》这是一本系统介绍USB的书籍,但是我不可能有时间会去慢慢回味,我要的是速战速决。《ehci-specification-for-usb》是英文原版的EHCI规范,这对我来说只是工具书,遇到中文资料有含糊不清的地方时我才会打开英文原版资料来确认。〈Host控制器之EHCI〉这是个无名大神的类学习笔记,在我学习EHCI、解决问题的过程中起了重要作用。
EHCI与我之前熟悉的那些外设如SPI、UART等最大的不同是USB2.0是标准,EHCI直接定义了USB20的一种实现方式,定义的非常之细,不仅定义了的寄存器,而定义了的数据结构体,更甚一步这些数据结构体在一定程度上还起着寄存器的作用,但这是数据结构体是定义在用户RAM区的,大多这些结构体要求是4096对齐的,(太浪费空间了,STM32不用是不是因为RAM太小)。因为我这次要解决的是LPC4357访问U盘,因此我只是详细看了,QH(queue header)、qTD(queue transfer descriptors),因为大容量存储设备大概只用了这两个结构体,还有一个iTD这是同步传输才使用的,我只是简单看了下。QH对应 一个pipe,一个端点,下面挂了一串qTD,所谓的发送接收USB数据包,就是填充这些结构体,然后启动发送就行了,然后EHCI控制器会自动的访问这些定义的QH、qTD来传送数据,数据传输完毕后在中断程序中结束发送。
有了这些基本的知识,再调试起LPC4357的USB来就不会一头雾水了,至少我大概能弄清数据的流向,如果你不弄清这些东西,即使单步调试到错误的地方,你还是不知道哪里错了。经过好多天学习-〉调试-〉学习-〉调试-〉学习-〉调试-〉反复过程,终于慢慢定位到真正的错误地方;期间我还找来了公司的USB ANALYST 总线分析仪,这个仪器对我定位问题起到决定性作用。 NXP提供的这个USB协议栈有个很隐蔽的问题,在EHCI.c文件中QueueQTDs()函数,
static HCD_STATUS QueueQTDs (uint8_t HostID,
uint32_t* pTdIdx,
uint8_t* dataBuff,
uint32_t xferLen,
HCD_TRANSFER_DIR PIDCode,
uint8_t DataToggle)
{
uint32_t TailTdIdx=0xFFFFFFFF;
while (xferLen > 0)
{
uint32_t TdLen;
uint32_t MaxTDLen = QTD_MAX_XFER_LENGTH - Offset4k((uint32_t)dataBuff);
if(PipeStreaming[HostID].PacketSize > 0)
TdLen = MIN(xferLen, PipeStreaming[HostID].PacketSize);
else
TdLen = MIN(xferLen, MaxTDLen);
xferLen -= TdLen;
if (TailTdIdx == 0xFFFFFFFF)
{
ASSERT_STATUS_OK ( AllocQTD(HostID, pTdIdx, dataBuff, TdLen, PIDCode, DataToggle, (xferLen==0) ? 1 : 0) );
TailTdIdx = *pTdIdx;
}
else
{
uint32_t NewTdIDx;
if(HCD_STATUS_OK == AllocQTD(HostID, &NewTdIDx, dataBuff, TdLen, PIDCode, DataToggle, (xferLen==0) ? 1 : 0))
{
HcdQTD(HostID,TailTdIdx)->NextQtd = Align32((uint32_t) HcdQTD(HostID,NewTdIDx));
TailTdIdx = NewTdIDx;
}
else
{
PipeStreaming[HostID].BufferAddress = (uint32_t)dataBuff;
PipeStreaming[HostID].RemainBytes = xferLen + TdLen;
PipeStreaming[HostID].DataToggle = DataToggle;
HcdQTD(HostID,HCD_MAX_QTD - 1)->IntOnComplete = 1;
break;
}
}
if(DataToggle == 1) DataToggle = 0;
else DataToggle = 1;
dataBuff += TdLen;
}
if(xferLen == 0)
{
memset(&PipeStreaming[HostID], 0, sizeof(Pipe_Stream_Handle_T));
}
return HCD_STATUS_OK;
}
即使不懂USB协议栈,完全分析这个函数,也能看出点问题的,传输长度xferLen在循环分配的过程中,先减去了将要分配的长度xferLen -= TdLen;再去分配QTD,如果分配失败的话,xferLen已经减过了,而在函数后面if(xferLen == 0)(),却依然使用了xferLen 这个错误的值,造成最后一包数据丢失。只需在这个地方这样修改就可以了。
xferLen = xferLen + TdLen; //willow add
PipeStreaming[HostID].RemainBytes = xferLen /*+ TdLen*/;
经过测试,确实是这的问题,测试通过。
这个问题之所以隐蔽,是因为不是所有的应用都会暴露出来的,只有当传送的数据包为(8*n)+1包时,才会出现。所以有的文件可以拷贝成功,有的文件不能成功,且与文件大小关系也不大
。
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?注册
x
阿莫论坛20周年了!感谢大家的支持与爱护!!
曾经有一段真挚的爱情摆在我的面前,我没有珍惜,现在想起来,还好我没有珍惜……
|