stm32f103 USB读卡器实验移植到UCOSIII中出现问题

susan01 · 发表于 2018-12-28 13:52:55

使用正点原子的mini板例程，SD卡使用SPI连接，USB读卡器是一个单独的任务，按照原子的例程改的，USB库只把hw_config.c文件中断优先级修改了一下，bDeviceState的值变化正常。
void  AppTaskUsb (void *p_arg)
{
u8 offline_cnt=0;
u8 tct=0;
u8 USB_STA;
u8 Divece_STA;
OS_ERR       err;
int i=0;
(void)p_arg; /* 避免编译器告警 */
USB_Interrupts_Config();
Set_USBClock();
USB_Init();
bsp_DelayMS(1800);
  while(1)
{
//OSSchedLock(&err);

bsp_DelayMS(1);

if(bDeviceState==CONFIGURED)
OSSchedLock(&err);
if(USB_STA!=USB_STATUS_REG)//状态改变了
{
if(USB_STATUS_REG&0x01)//正在写
{
USB_STATUS_REG&=0xFD;//清除读标记
}
if(USB_STATUS_REG&0x02)//正在读
{
USB_STATUS_REG&=0xFE;//清除写标记
}
USB_STA=USB_STATUS_REG;//记录最后的状态
}
if(Divece_STA!=bDeviceState)
{
Divece_STA=bDeviceState;
}
i++;
if(i==200)//200ms时间到了
{
i=0;
if(USB_STATUS_REG&0x10)
{
offline_cnt=0;//USB连接了,则清除offline计数器
bDeviceState=CONFIGURED;
}else//没有得到轮询
{
offline_cnt++;
if(offline_cnt>10)bDeviceState=UNCONNECTED;//2s内没收到在线标记,代表USB被拔出了
OSSchedUnlock(&err);
}
USB_STATUS_REG=0;
}
LED2_TOGGLE;
OSTimeDlyHMSM(0, 0, 0, 5, OS_OPT_TIME_HMSM_STRICT,&err);
}

}

请问原子有没有遇见这种问题？有人说是使用USB和UCOSIII冲突，但是我看原子的综合实验在用USB时没有关闭UCOS任务调度@正点原子

susan01 · 发表于 2018-12-28 13:58:00

不上UCOSIII是测试过的，PC端正常显示盘符，可以正常操作

susan01 · 发表于 2018-12-28 16:00:57

已解决

susan01 · 发表于 2019-1-3 21:33:14

已解决

思维逆逝 · 发表于 2019-9-17 19:33:50

怎么解决的？谢谢

洪宇 · 发表于 2019-9-26 14:54:37

我也将USB读卡器的程序移植到UCOS-iii上也出现了跟楼主一样的问题，由于USB的库函数一直没时间看所以不知道问题出在哪了。
但是USB读取FLash时没有对Flash进行保护，出现其它程序同时读FLash也是会出错的，不知道楼主是不是这个问题。

社会如此多娇 · 发表于 2019-11-19 10:04:06

本帖最后由社会如此多娇于 2019-11-19 10:06 编辑

在实时操作系统下使用原子的USB读卡器实验首先需要修改USB_OTG_BSP_uDelay 和USB_OTG_BSP_mDelay 函数，将其换成软件延时，软件延时如下所示（系统时钟168hz）
void s_delay_us(u32 us)
{
            u8 i = 0;
            while(us--)
            {
                     i = 42;
                     while(i--);
            };
}

void s_delay_ms(u32 ms)
{
            u16 i = 0;
            while(ms--)
            {
                     i = 41750;
                     while(i--);
            };
      }

void USB_OTG_BSP_uDelay (const uint32_t usec)
{
         s_delay_us(usec);
}

void USB_OTG_BSP_mDelay (const uint32_t msec)
{
      s_delay_ms(msec);
}

但是修改之后还是不能正常运行，找了很长时间的原因，发现会进入hardfult异常，原因是“试图切入ARM状态”。
先说原因吧，是因为ftl.c文件里的NAND_EraseBlock(source_block)函数调用了delay_ms(NAND_TBERS_DELAY)函数造成的，下面分析原因。
在实时操作系统下使用原子的USB读卡器例程，接上串口会出打印Error:..\FreeRTOS\portable\RVDS\ARM_CM4F\port.c,441，看port.c文件的441行，提示在中断中调用了API函数要以FromISR结尾。分析441行程序，void vPortEnterCritical( void )
{
portDISABLE_INTERRUPTS();
uxCriticalNesting++; /*临界区嵌套*/
if( uxCriticalNesting == 1 )
{
   configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 ); /*判断有没有中断发生*/
}
}

#define portNVIC_INT_CTRL_REG             ( * ( ( volatile uint32_t * ) 0xe000ed04 ) )  中断控制状态寄存器，低8位数据减16为当前发生的终端编号
configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 ); 该语句表示进入临界区，有中断发生就报错。
以上分析可知，之所以报错，程序运行错误，是因为进入临界区发生了中断，反过来也可以为正在执行中断函数，运行了包含进入临界区的函数的程序。
分析USB读卡器程序可以看出，所有USB相关的程序都是在OTG_FS_IRQHandler(void)中断函数中执行的，仿真只有在写文件时会出现上述错误。USB读卡器
底层使用的时ftl.c文件里的读写，该文件里的FTL_WriteSectors()写函数会调用FTL_CopyAndWriteToBlock()；
FTL_CopyAndWriteToBlock()会调用NAND_EraseBlock(source_block);
而NAND_EraseBlock(source_block)调用了delay_ms(NAND_TBERS_DELAY)函数，
delay_ms(NAND_TBERS_DELAY)会执行xAlreadyYielded = xTaskResumeAll();语句，
xTaskResumeAll()里包含taskENTER_CRITICAL();也就是进入临界区函数，也就是在这里报错的，将NAND_EraseBlock(source_block)调用了delay_ms(NAND_TBERS_DELAY)改为软件延时则可以正常运行.