[参考译文] AM2434：Tiny-USB 模块应用影响其他 IRQ 触发时序

尊敬的 champ：  

在执行 USB 连接时是否会有一些硬件握手协议或等待响应、这可能会延迟/推迟 R5F？

BR、丰富

您好、Rich：

感谢您的提问。

您能告诉我们 R5F 内核上正在运行的所有其他任务吗？

另外、请告诉我们所有外设都与 USB 一同使用？

此致、

Tushar

尊敬的 Tushar：

你是否认为OsalNoRtosQueue_enqueue()执行的 USB 模块函数HwiP_disable()会禁用所有中断并在其他高优先级中断中引起延迟？

如果您同意此视图、您可以帮助确认 USB 模块中的功能吗？

下面列出了程序中当前使用的 SDK 8.6.0函数:

• usb_wrapper.c
  • usb_irq6_isr( )
• cusbd.c
  • cusbd_dsr( )
• usbd.h
  • tud_task()  
• CDC_DEVICE.c
  • TUD_CDC_n_Available( )
  • TUD_CDC_n_READ( )
  • TUD_CDC_n_READ_FLUSH( )
  • TUD_CDC_n_WRITE_Available( )
  • TUD_CDC_n_WRITE_FLUSH( )
• cdc_device.h
  • TUD_CDC_n_WRITE_CHAR( )

在这些函数及其调用的函数中、是否有完全禁用所有中断使能的操作(例如、调用执行HwiP_disable()或Semaphore_Pend()")？

此致

螺栓

尊敬的  Tushar：

  关于 TinyUSB 应用函数中禁用中断的部分、您能否帮助验证这一点并提供宝贵的建议？

此致

螺栓

Tushar、  

新年快乐！ 我希望你能回到办公室。  

您能否提供有关此 USB 案例的建议？

BR、丰富  

您好、Rich：

我检查了 USB 代码,发现 HwiP_disable ()& HwiP_disableInt () API 只在  OsalNoRtosQueue_enqueue()、OsalNoRtosQueue_dequeue() 和 USBD_int_set() 、DCD_int_disable  () 函数内调用。

Hwip_disable () API 禁用所有中断。 您能否使用仅禁用特定中断的 HwiP_disableInt (intrNum) API 尝试一次？

将 OsalNoRtosQueue_enqueue()和 OsalNoRtosQueue_dequeue()的代码替换为以下代码、然后重新构建库。

OsalNoRtosReturn_t OsalNoRtosQueue_enqueue(
            OsalNoRtosQueue_t* queue,
            const uint8_t* dataBuff,
            uint16_t size )
{
	OsalNoRtosReturn_t status = OSAL_NO_RTOS_RETURN_FAILURE; 
    
	volatile uint32_t rdIdx ;
    volatile uint32_t wrIdx ;
	
	HwiP_disableInt(CSLR_R5FSS0_CORE0_INTR_USB0_IRQ_6);
	rdIdx = queue->rdIdx; 
    wrIdx = queue->wrIdx;
	/* redundant size check with the global message size 
	                        to protect against buffer-overflow */ 
    if((rdIdx < queue->maxDepth) && (wrIdx < queue->maxDepth) \
	                                  && (size == queue->eleSize))
    {
        if( queue->currCount < queue->maxDepth )
        {
            /* There is some space in the FIFO write data to queue*/
            memcpy((queue->fifo + (queue->eleSize*wrIdx)),\
			                               dataBuff,queue->eleSize);
			
			queue->currCount += 1 ; 

            wrIdx = (wrIdx+1)%queue->maxDepth;

            queue->wrIdx = wrIdx;
            /* read back to ensure the update has reached the memory */
            wrIdx = queue->wrIdx; 

            status = OSAL_NO_RTOS_RETURN_SUCCESS;
        }
    }
	
	HwiP_enableInt(CSLR_R5FSS0_CORE0_INTR_USB0_IRQ_6);

    return status;
}


OsalNoRtosReturn_t OsalNoRtosQueue_dequeue(
            OsalNoRtosQueue_t* queue,
			uint8_t* dataBuff,
			uint16_t size )
{

	OsalNoRtosReturn_t status = OSAL_NO_RTOS_RETURN_FAILURE; 
    

	volatile uint32_t rdIdx; 
    volatile uint32_t wrIdx;
	
	
	HwiP_disableInt(CSLR_R5FSS0_CORE0_INTR_USB0_IRQ_6);
	rdIdx = queue->rdIdx; 
    wrIdx = queue->wrIdx;

	/* redundant size check with the global element size to 
	                          protect against buffer-overflow */ 
    if((rdIdx < queue->maxDepth) && (wrIdx < queue->maxDepth) && \
	                                    (size == queue->eleSize))
	{
		/* If there is someting to read in the fifo */ 
        if(queue->currCount > 0)
        {
            /* Copy EleSize bytes from Queue memory to the buffer */
            memcpy(dataBuff, (queue->fifo + (queue->eleSize*rdIdx)), \
			                                         queue->eleSize);

			queue->currCount -= 1 ; 

            rdIdx = (rdIdx+1)%queue->maxDepth;

            queue->rdIdx = rdIdx;
            /* read back to ensure the update has reached the memory */
            rdIdx = queue->rdIdx; 
			
            status = OSAL_NO_RTOS_RETURN_SUCCESS;
        }
    }
	
	HwiP_enableInt(CSLR_R5FSS0_CORE0_INTR_USB0_IRQ_6);

    return status;
}

 完成上述更改后、请重新构建库。 使用以下命令。

cd ${MCU+SDK}/source/usb/cdn

gmake -s -f makefile.nortos.am64x.r5f.ti-arm-clang PROFILE=debug clean
gmake -s -f makefile.freertos.am64x.r5f.ti-arm-clang PROFILE=debug clean

gmake -s -f makefile.nortos.am64x.r5f.ti-arm-clang clean
gmake -s -f makefile.freertos.am64x.r5f.ti-arm-clang clean

gmake -s -f makefile.nortos.am64x.r5f.ti-arm-clang PROFILE=debug
gmake -s -f makefile.freertos.am64x.r5f.ti-arm-clang PROFILE=debug

gmake -s -f makefile.nortos.am64x.r5f.ti-arm-clang 
gmake -s -f makefile.freertos.am64x.r5f.ti-arm-clang 

构建库后、请重新编译示例。

请告知我们上述实验的结果。

此致、

Tushar

尊敬的 Tushar：

  感谢您的答复。

 对这两个功能的修改、 OsalNortosQueue_enqueue() 和 OsalNortosQueue_dequeue() 在我最初问这个问题的时候、已经完成了。 但是、如问题第一部分所述、这些改动未能解决这一问题。

  我查看了程序的映射文件和两个函数、 USBD_int_set() 和 dcd_int_disable() 、都在其中。

  如果 USB 连接不稳定、这两个功能 USBD_int_set() 和 dcd_int_disable() 、可能执行？

  如果上述问题的答案是肯定的、您能告诉我哪些函数可以调用它们吗？

此致、

螺栓

尊敬的 Tushar：

  我检查 这两个函数、  USBD_int_set()  和  dcd_int_disable()。

  这两个函数仅 禁用特定的中断。 因此、您可以忽略我的最后一个问题。

 正如丰富提到的、 在执行 USB 连接时、是否会有一些硬件握手协议或等待响应、这可能会延迟/推迟 R5F？

  回复您之前的查询:

     1.在我们的任务中、USB 应用程序的优先级设置为最低的 IRQ 优先级(13–15)、而较高的优先级(0–12)分配给其他关键任务、例如周期性的 IRQ 触发。 我们的主要应用是电机控制、因此周期性 IRQ 触发的延迟会严重影响电机控制的性能。

     在我们的应用中、与 USB 一起使用的外设包括：计时器、FSI、GPIO、I2C、MCSPI、 OSPI 和 PRU。

此致、

螺栓

HI 螺栓、

感谢您分享上述信息。 您能告诉我们您如何检查中断是否未在定期间隔发生吗？

您是否在 ISR 中使用 GPIO 切换？  

此致、

Tushar

尊敬的 Tushar：

在我们的程序中、它使用CycleCounterP_getCount32()来记录 ISR 触发时间。 周期性 GPIO 信号会触发 R5F 的全部四个内核。

我们检查了所有四个内核的记录时间。 R5F0_0的记录时间显示了延迟、但其他内核的记录时间是正确的。

HI 螺栓、

感谢您分享上述详细信息。 根据我的理解、您的代码与下面类似、如果我错了、请进行更正。

void ISR_handler()
{
    GPIO_HIGH();
    cycle = CycleCounterP_getcount();
    // interrupt processing
    GPIO_LOW();
}

int main()
{
  // System & Driver Initialization
  
  // Interrupt Setup(ISR_handler) for periodic time 62.5 us 
  
  
  // Usb processing
  usb_processing();
  
  // System & Driver De-Initialization
  return 0;
}

需要与 ISR 实现相关的信息、因为我怀疑中断发生的时间为62.5us、但 GPIO 切换需要时间、从而导致发生 ISR 时的捕获延迟。

您能否尝试从 ISR 中删除 GPIO 代码并更新结果？

此致、

Tushar

尊敬的 Tushar：

感谢您的建议、但您的计划与我们的申请不一致。

抱歉、我认为同步 GPIO 触发方式需要太多时间、因此我进一步测试的重点是 USB 通信。

我进一步用于CycleCounterP_getCount32()研究导致 ISR 延迟的函数。

HI 螺栓、

我怀疑  CUSBDMA_ChannelUpdateState ()函数在访问某些属于 USB PHY 域的寄存器时导致延迟。

您能告诉我们您在运行什么测试吗？ 是否持续连接和断开 USB 器件与主机的连接？  

Unknown 说：

如果的值channel->trbChainDescBufferSz为0、您认为此模数操作会导致 DSP 处理错误吗？

我认为 trbChainDescBufferSz 的值不能为0、因为缓冲区的大小为0是没有意义的。

此致、

Tushar

尊敬的 Tushar：

感谢 您的答复。

是的、当我在330V 电机控制环境中运行时、USB 器件在保持连接的同时经常会与主机连接中断。 这最终会导致周期性 ISR 延迟。

您能否提供一些修改CUSBDMA_ChannelUpdateState()功能的建议以改善此问题？

感谢您对的解释channel->trbChainDescBufferSz。

此致、

螺栓

尊敬的 Tushar：

感谢您的答复。

我使用了 MSYS2安装的 gmake 命令。 因此我使用了 make 命令来替换 gmake 命令。  

在我们的 SDK - 8.6.0.45中、文件名是 am243x 系列。

我将命令表 am64x 修改为 am243x。 并使用 PowerShell 输入命令

但我仍然获得错误信息。 如果我仅安装了 CCS12.5、我是否可以更改某些命令以将 CCS12.1更改为 CCS12.5？

您能否修改命令以适合 am243x 系列、并提供命令应用程序步骤的一些建议。

此致、

螺栓

尊敬的 Tushar：

我修改了文件"imports.mak"、并通过 CCS12.5成功使用了所有命令。

关于结果、我稍后会进行更新。

此致、

螺栓

尊敬的 Tushar：

我检查了库更新成功。

但是、 测试结果显示同样的现象、周期性中断仍然会延迟

您是否有任何其他修改建议？

此致、

螺栓

尊敬的 Tushar：

我仍在尝试解决此问题。

我尝试修改了一些.lib文件。

第一、
如果.lib被执行HwiP_disable(),我把它注释掉了。 我还检查了该.map文件以确认HwiP_disable()没有被中的其他函数调用.lib。

第二、
如果.lib已执行HwiP_Construct()、我将在配置 IRQ 之前设置 IRQ 优先级、以确保其优先级低于周期性 IRQ 的优先级。

然而,这两个修改都不起作用。 问题仍然存在、并且定期中断仍会延迟。

您是否有解决此问题的新策略？

此致、

螺栓

HI 螺栓、  

我需要有关上述问题的更多详细信息、以便缩小根本原因的范围。

您如何在 USB 器件上执行连接/断开测试？ 它是手动连接/断开还是以编程方式连接/断开？

在经过多少次连接/断开循环之后、问题再次出现、或者在每个连接/断开循环中是否可以发现问题？

同样、一旦 USB 器件被连接且枚举完成、就不会出现中断延迟。 这种理解是否正确？

您能否提供测试设置详细信息和示例代码以便在结束时重现问题以加快调试速度？

此致、

Tushar

尊敬的 Tushar：

这种情况并非在我们手动连接或断开连接时有意发生。

在电机控制操作期间、USB 连接环境受330V 电机控制的影响、导致 USB 连接被噪声中断、从而显著增加发生此问题的可能性。

因此、我无法指定可能触发此问题的连接和断开连接实例的数量。

关于示例代码、我们使用了 SDK-8.6.0中提供的以下应用程序函数。
我们在 NoRTOS 场景下使用了这些函数并根据下面的描述执行了操作。

当usb0_IRQ6触发由 SDK 创建的中断时、回调函数会调用以下函数：

• usb_irq6_isr()

我们为 Rx 接收器软件中断设计了一个1ms 周期性触发器、该中断按顺序执行以下功能：

• cusbd_dsr()
• tud_task()
• tud_cdc_n_available()
• tud_cdc_n_read()
• tud_cdc_n_read_flush()

对于数据传输、我们设计了一个用于 Tx 发送软件中断的触发器、该中断按顺序执行以下功能：

• tud_cdc_n_write_available()
• tud_cdc_n_write_char()
• tud_cdc_n_write_flush()

使用CycleCounterP、我们发现在执行 Rx 接收器函数时发生了记录的周期性计时延迟。 另外两个函数在此期间未被触发或执行。

希望上述信息对您有所帮助、可以提供相关的修改建议。

此致

螺栓

尊敬的 Tushar：

我已经确认,当channelUpdateState()函数被执行时CPS_UncachedRead32(&regs->traddr);,特别是在操作期间,它通常需要0.5µs。 但是、发生问题时、需要的时间明显更长、超过了20µs。 在此期间、高优先级中断被阻止、不能抢占。

该channelTrigger()函数也执行CPS_UncachedRead32(&regs->traddr);并表现出相同的行为。

为什么仅读取该特定寄存器地址会导致该问题？

关于这一问题、是否有其他办法来改善这种情况？

此致

螺栓

尊敬的 Tushar：

我已确认的物理地址regs->traddr为0xF40020。

此地址是 USB0 VBP2APB 绕线控制器 VBP 内核 ADDR 映射的一部分。

 但是、我在 TRM 的 USB 模块部分没有找到相关文档或说明。

因此、我需要您的帮助来解决此问题。

您能否提供一些修改建议？

此致

螺栓

HI 螺栓、

根据我之前的回复所述、traddr 寄存器位于 USB PHY 域中。  

如果 USB PHY UTMI 时钟被更改/禁用、则访问这些寄存器将会有延迟。  

Unknown 说：

但是、我在 TRM 的 USB 模块部分找不到相关文档或说明。

由于该寄存器的描述受 NDA 限制、因此我不能在公共 e2e 论坛上分享其详细信息。

此致、

Tushar

尊敬的 Tushar：

感谢您的答复。

我理解您的描述。

但是、我们的程序仍然使用 USB 模块、并且延迟问题继续发生。

关于延迟问题、您能提供一些解决建议吗？

此致

螺栓

尊敬的 Tushar：  

当 USB 通信不稳定时,如您所述,USB PHY UTMI 时钟可能会发生变化或禁用,这会导致内核在读取时操作延迟regs->traddr。

关于此问题、是否有方法可以在读取此寄存器之前检查状态？ 例如、在继续读取regs->traddr寄存器之前、我是否可以首先读取另一个寄存器以确认 USB PHY UTMI 时钟正常工作？ 以避免 内核运行 延迟情况。

您能否为此目的提供相关程序或寄存器的详细信息？ 或者、如果您有其他更好的建议、请与相关说明一起分享。

谢谢！

此致

螺栓

尊敬的 Tushar：

我还想知道这个问题的解决方案。

对于这个问题、您有什么解决方案或建议吗？

此致

螺栓

Tushar、  

您认为向客户提供 USB PHY 文档是否可以解决该问题？ 如果是、我们可以朝这个方向发展。  

螺栓、  

对于 USB 通信类型的接口控制、是否可以 在电机实时控制环路的 R5F 内核(而不是 R5F 内核)之一中进行处理？

是在同一个内核处理 USB、还是所有内核都需要处理 USB？  

BR、丰富  

您好、Rich：

在我们的应用中、用于电机控制的 CPU 和处理 USB 通信的 CPU 是不同的。

然而、由于内核间通信(例如 EtherCAT 通信)需要在一个62.5 µs 周期内进行同步、USB 通信内核中的延时时间仍然会影响电机控制 CPU (由于内核间同步机制中的等待时间)。

BR、螺栓

螺栓、  

我明白了你的观点。

USB 通信中的数据是否需要在每个控制周期中同步？  

辅助、使用 GPIO IRQ 可能受软件影响。  

是否可以使用硬件计时器来生成周期性 IRQ？  

BR、丰富

您好、Rich：

USB 通信所需的信息当前设计为每1ms 同步一次、而不是在每个控制周期中同步一次。 但是、当每1ms 同步一次 USB 通信时、如果更高优先级的控制周期要求同时进行内核间同步、控制周期可能会受到 USB 通信寄存器读取操作的影响、从而导致控制周期延迟。

GPIO 输入信号由 FPGA 生成并由 AM24x 接收、因此主要用于同步两个 IC 的控制周期。 因此、未使用 AM24x 的内部硬件计时器。

BR、螺栓

螺栓、  

非常感谢您的讲解。  

因此 GPIO IRQ 根本不会延迟。  但是 IRQ 服务例程将被 USB 通信的寄存器读取操作 延迟、进而导致控制周期延迟。 我的理解是否正确？  

为了实现内核间同步、是否会通过内部数据 RAM 交换数据？

您是使用 USB 通信 R5F 内核复制还是使用 DMA 复制数据？  

如果 GPIO 输入信号是由 FPGA 生成的、那么您可能可以使用中断来触发 DMA 复制、而不涉及 R5F。

能否通过 DMA 副本完成内核间同步？

BR、丰富   

两者、都很丰富

AM64系统互连包含两种类型的端点：VBUSP 与 VBUSM。 VBUSM 接口支持多个传输中事务、而 VBUSP 接口仅支持单个传输。

当多个事务发送到相同的端点时、会导致暂时停顿。 如果存在机载写入事务、总线将停止、直到写入命令和写入数据都完成。 对于读取事务、VBUSP 接口将被阻止、直到读数据返回、并且总线没有任何飞行事务。 因此、VBUSP 接口读取事务引起的暂时停止取决于读数据返回的时间。 通常一组 VBUSP 端点位于单个 VBUSP 后面。

如果您访问与 USB 共享的 ISR 中的外设、并且由于 USB 噪声读取/写入需要更长时间、则共享 VBUSP 接口中会出现时间停止、从而导致 ISR 处理停止。 请注意、ISR 触发器将不受影响、因为这将通过与共享 VBUSP 不同的路径来实现。

假定 ISR 中正在使用 GPIO、由于 USB 寄存器访问中的停止(由于噪声)、对 GPIO 的访问可能会暂停。 由于 GPIO 访问暂停、ISR 处理可能需要更多时间。 这只是一个示例、但您的系统中可能会发生类似的情况。

我将附加 AM64拓扑的一个片段、并将与 Rich 共享完整文档。 蓝色框是您感兴趣的 vbusp、红色框是 USB 寄存器。 这里向您展示了同一32b VBUSP 接口下的外设。 ISR 中使用的任何这些外设都将导致 ISR 处理、在 USB 处理因噪声而停止时、需要更多时间。

关于在高噪声环境中使用 USB 的其他注意事项。 USB 被设计成一个低成本消费类电子接口、在此类接口中不要求故障安全。 连接器和2.0电缆的设计实际上使得接口非常容易受到噪声耦合的影响。  TI SoC USB 功能的设计、实施、测试和功能/电气验证均符合 USB2.0标准的要求、但该接口的限制通常将排除在任务关键型基础设施中使用。 因此、在这些系统中、不建议在高噪声环境中使用 USB。

此致

Karan

丰富

感谢您的答复。
您的理解是正确的。
我们的内部数据同步使用 RAM、USB 通信所需的数据当前由 CPU 处理、而没有专门使用 BCDMA 进行数据传输。
GPIO ISR 主要用于对齐控制周期和同步跨核时间戳、这对于上层通信(例如 EtherCAT 通信)和机架应用至关重要。
因此、我们认为通过修改系统而将 GPIO 触发器仅用于 DMA 传输是不可行的。

Karan

感谢您的答复。
我理解您对 USB 内核 vbusp 的读取延迟将导致 vbusp SCR 上的其他外设(例如 GPIO、中断路由器)发生延迟的描述。 还建议不要在高噪声环境中使用 USB 模块。

根据多项测试、该延迟似乎只有regs->traddr (0xF40020)在 USB 内核 vbusp 读取操作期间读取其上的寄存器时才会发生。 因此、我想进一步询问以下问题：

• 是否可能读取 USB0 VBP2APB 绕回控制器 VBP CORE ADDR 映射中的任何地址会导致延迟、而在我的测试中、该延迟仅在访问时发生 regs->traddr (0xF40020)？

• 如果延迟仅在读取时发生 regs->traddr (0xF40020)、是否有另一个寄存器可以首先读取以验证 USB PHY UTMI 时钟的状态？ 这样,我可以确认 USB 时钟正常工作,然后再读取traddr。

• 如果在通过 vbusp SCR 读取所有 USB 寄存器时可能发生延迟、是否有其他非 vbusp SCR 路径可用于检查 USB PHY UTMI 时钟的状态？ 这样我们就可以在traddr通过 vbusp SCR 访问之前通过另一个通道验证 USB 时钟状态。

BR、螺栓

螺栓、  

我知道 GPIO ISR 是所有内核的主要同步并行时钟。

我假设所有内核间通信访问都依赖于通过 R5F0的 CPU 副本。  

我的建议是使用 DMA 在每个控制周期进行核间通信。  

这可以减少 R5F0的负载和处理时间、以便为其他任务提供更多空间、但 USB 访问延迟仍然存在。

 

对于 USB 访问延迟、Karan 和 Tushar 将带领大家讨论如何解决它。  

BR、丰富

Karan 和 Tushar、  

刚刚与 Bolt 讨论并确认 USB ISR (每1ms)失速原因 GPIO ISR 中的延迟(发生 FPGA 的 GPIO 中断、可在其他 R5F 内核中捕获)、但 R5F0_0正在提供 USB ISR 块(停止和停止)、中断路由器的 GPIO 中断(中断不会在 R5F0_0中发生)、即使 GPIO IRQ 具有更高的优先级、但不能进入 R5F0_0。   

因此、该情况的权变措施是在访问可能导致延迟响应的关键寄存器之前检查 USB 状态。 确保 USB 正常工作、然后保持 ISR 或停止并等待下一个控制周期(在其情况下为62.5us)。  

请与 USB IP 专家讨论、以提供寄存器进行检查或这种情况的任何替代方案。  

BR、丰富

  

大家好、Karan 和 Tushar、

与 Rich 讨论并等待了一周后、 我仍然想知道此情况的权变措施、它是在访问可能导致延迟响应的关键寄存器之前检查 USB 状态。

对于这个问题、您是否有任何解决方案或其他建议？

无论当前是否有可用的解决方案、请提供响应、以便我们可以确认处理此问题的后续步骤。 非常感谢您的反馈。

此致

螺栓

Karan  

已向您发送有关此案例的内部邮件。  

下面是添加的陈述、以防我没有清楚地描述它。  

所有其他三个 R5F 内核都可以获得此中断并毫无延迟地继续运行其任务、只有 R5F0_0会因 USB 寄存器访问而延迟、并且客户已确定寄存器地址 regs->traddr (0xF40020)、这受到的影响最大。  

BR、丰富

Tushar and Karan,  

您能否提供此案例的当前状态和评论？  

BR、丰富  

HI 螺栓、

感谢您的耐心。 请查看以下回复。

Unknown 说：

是否可能读取 USB0 VBP2APB 绕回控制器 VBP CORE ADDR 映射中的任何地址会导致延迟、而且恰好在我的测试中、延迟仅在访问时发生 regs->traddr (0xF40020)？

在 PHY 域中有六个名为的寄存器  USB_CONF、EP_SEL、EP_TRADDR、EP_CFG、EP_CMD、 EP_STS  这可能会导致延迟。

Unknown 说：

如果延迟仅在读取时发生 regs->traddr (0xF40020)、是否可以首先读取另一个寄存器来验证 USB PHY UTMI 时钟的状态？ 这样,我就可以在读取前确认 USB 时钟工作正常traddr。

遗憾的是、没有用于检查 UTMI 时钟状态的寄存器。

[报价 userid="549268" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1450623/am2434-tiny-usb-module-application-affect-the-others-irq-trig-timing/5639135 #5639135"]如果通过 vbusp SCR 读取所有 USB 寄存器时可能发生延迟、是否有替代非 vbusp SCR 路径可用于检查 USB PHY UTMI 时钟的状态？[/QUOT]

VBUSP 接口是无可替代的。 所有到 USB 寄存器的事务都只通过 VBUSP 接口。

此致、

Tushar

尊敬的 Tushar：

感谢您的答复。

令人遗憾的是、没有其他寄存器可用于确认 UTMI 时钟状态。

在这种情况下、除了 UTMI 时钟状态和您描述的影响延迟的六个寄存器之外、还有其他任何受 UTMI 时钟影响的寄存器状态吗？ 如果可以、我们可以首先读取它们的状态来确定 UTMI 时钟状态。 让 我们可以避免读取受延迟影响的寄存器。

请帮助确认这一点。 谢谢！

此致

螺栓

Tushar、  

根据今天的内部讨论、USB 在 FS 下工作不会出现延迟问题、而 HS 将出现延迟问题。

在 FS 处运行可能是此情况的权变措施。   

您能否建议如何将 USB 设置为在 FS 下运行、以便客户可以在其系统上验证它？

这可以在 SysConfig 工具上设置吗？  

BR、丰富

您好、Rich：

请注意、不建议 TI 采用将 USB 控制器限制为全速模式的权变措施、因为这样不能保证能够解决问题、但请尝试报告结果。

请查找以下更改、以限制控制器在 USB FS 模式下运行。

更改 forcedUsbMode 值为1 . forcedUsbMode 可从获取 $｛MCU+SDK｝\source\usb\cdnear\usb\am64x_am243x\usb_wrapper.c soc 初始文本文件。 您需要更新两个位置。

请参阅下图。

     

接下来、更改处提供的宏值 $｛MCU+SDK｝src \source\usb\cdn\core_driver\device\sdk\ss_dev_hw.h 初始文本文件。

有两行可进行更改。

#define USB_CONF_CFORCE_FS 0x00001000U
#define USB_CONF_sforce_fs 0x00002000U

请参阅下图。

完成上述更改后、构建库并重新编译示例。

此致、

Tushar

HI 螺栓、

Unknown 说：

但是、在执行所有步骤后、我检查了该forcedUsbMode值、它仍然等于2。

您能否确认您是否已正确重建库？

Unknown 说：

另一方面、我发现一条注释指出 SS 模式需要forcedUsbMode设置为3。 此描述是否错误？

我已经提供了上述设置来将器件配置为 FS 模式(即 全速)。 值3用于将其配置为当前 SDK 产品不支持的 SS 模式(即超速)。

此致、

Tushar

尊敬的 Tushar：

感谢您的答复和解释。  

因为usb_wrapper.c位于中/usb/cdn/、我最初只更新usbd_cdn_nortos.am243x.r5f.ti-arm-clang.release.lib。 然而,这.lib并不是指usb_wrapper.c.

因此,我更新usbd_tusb_cdc_nortos.am243x.r5f.ti-arm-clang.release.lib和usbd_tusb_dfu_nortos.am243x.r5f.ti-arm-clang.release.lib,作为这两个.lib文件引用usb_wrapper.c.

测试结果是成功的—forcedUsbMode该值现在设置为1、USB 通信更稳定、系统不再出现延迟问题。

我衷心感谢你协助解决这一问题。

您好、Rich：

感谢您对此问题的持续跟踪和支持。

此致、

螺栓

螺栓、  

 很高兴知道该权变措施适用于您的情况。  

Tushar、

非常感谢您在这个特定问题上所做的努力、并为客户用户案例提供解决方法。  

它对我的客户来说确实是一个可行的解决方案。  

BR、丰富  

高螺栓、富、

很高兴知道上述权变措施可行。

Eric Ding 说：

非常感谢您在此特定问题上所做的努力、并为客户用户案例提供了解决方案。

谢谢。 很乐意提供帮助。

此致、

Tushar