时钟源

最近碰到一个客户,他们在 i.MX RT500 上使能了 FlexSPI->MCR0[RXCLKSRC] = 2(即 loopbackFromSckPad),这个选项字面上的意思是设置读选通采样时钟源为 SCK 引脚,这个选项在恩智浦官方的代码包里未曾使能过。

客户在使用过程中遇到高频时 SCK 引脚被降压的问题(从正常的 1.8V 降至 1.2V),那么这个 loopbackFromSckPad 选项到底是什么作用,以及有什么使用限制呢?

注1: 参考手册里显示支持loopbackFromSckPad选项的型号有 i.MX RT1040/1050/1060/1064/1180/500

注2: 参考手册里没有提及支持loopbackFromSckPad选项的型号有 i.MX RT1010/1015/1020/1024/1160/1170/600

一、为什么存在Read Strobe?

对于串行 SPI 接口存储器,FlexSPI 外设主要支持如下两种读数据时序:一是所谓的经典 SPI 模式,IO0 (MOSI) 专用于发送命令和地址,IO1 (MISO) 专用于接收数据(图中上面的时序)。二是 Multi-I/O SPI 模式,SIO[n:0] 一起用于发送命令地址以及接收数据(图中下面的时序)。

显然经典 SPI 模式下 IO[1:0] 是单向的,而 Multi-I/O SPI 模式下,SIO[n:0] 是双向的。当 SIO 用于双向传输时,过程中必然存在引脚方向切换,而 FlexSPI 外设在处理 SIO 方向切换时,无法做到零等待周期读取数据,这就是为什么 Multi-I/O SPI 读时序中总是会存在 Dummy 周期。

1.png

因为 Dummy 周期的存在,FlexSPI 外设内部实际上有一个 Read Strobe 信号(即 DQS)来控制数据的选通性(即什么时候开始数据有效,将数据存入内部 FIFO)。更直白点说,Read Strobe 信号的存在就是由于 FlexSPI 外设无法支持如下这种情况的读时序(下图中 COMMAND 实际应为 COMMAND&ADDR)。

2.png

二、FlexSPI内部Read Strobe设计

在i.MX RT参考手册里有如下 FlexSPI 前端采样单元框图,其中 ipp_ind_dqs_fa/b_int[x] 即是 Read Strobe 信号,它控制着 FIFO 中实际数据的存储。

3.png

ipp_ind_dqs_fa/b_int[x] 信号共有四种来源,最原始的信号源由 FlexSPI->MCR0[RXCLKSRC] 选择,中间可能还会经过 DLLxCR 单元(这部分以后会另写文章单独介绍)、Phase Chain 单元做处理,然后送到采样单元里。

4.png

下图是 FlexSPI->MCR0[RXCLKSRC] = 0 的情况,此时 Read Strobe 经由 ipp_do_dqs0_fa/b 纯内部 loopback 回来,没有经过任何延迟单元。这种配置一般仅用于经典 SPI 传输模式(低速 60MHz SDR 场合),适用低容量 SPI NOR / EEPROM,这时候 FlexSPI DQS Pad 可用作其它功能或者 GPIO。

5.png

下图是 FlexSPI->MCR0[RXCLKSRC] = 1 的情况,此时 Read Strobe 经由悬空的 DQS 引脚 ipp_do_dqs1_fa/b 再 loopback 回来,此时有了 DQS 引脚绕一圈的延迟。这种配置可用于 Multi-I/O SPI 传输模式(较高速 133MHz SDR 场合),适用不含 DQS 引脚的大容量 QuadSPI NOR Flash,但是 FlexSPI DQS Pad 需要悬空。

注: 有一篇旧文 《使能串行NOR Flash的DTR模式》 跟这种配置相关,这时候 dummy cycle 数的设置很关键。

6.png

下图是 FlexSPI->MCR0[RXCLKSRC] = 3 的情况,此时 Read Strobe 完全由外部存储器的 DQS 引脚输出 ipp_ind_dqs3_fa/b 直通进来。这种配置可用于 Multi-I/O SPI 传输模式(最高速 166MHz/200MHz DDR 场合),适用于包含 DQS 引脚的 OctalSPI NOR Flash,这时 FlexSPI DQS Pad 与外部存储器相连。

注: 我有两篇旧文 《串行NOR Flash的DQS信号功能》、《启动含DQS的Octal Flash可不严格设Dummy Cycle》 跟这种配置相关。

三、loopbackFromSckPad选项意义

前面铺垫了那么多,终于来到本文的主题了,即下图 FlexSPI->MCR0[RXCLKSRC] = 2 的情况,此时 Read Strobe 经由 SCK 引脚 ipp_ind_sck_fa/b 再 loopback 回来,此时有了 SCK 引脚绕一圈的延迟。

这种配置从应用角度与 FlexSPI->MCR0[RXCLKSRC] = 1(即 loopbackFromDqsPad) 差不多,也可用于 Multi-I/O SPI 传输模式(较高速 133MHz SDR 场合),适用不含 DQS 引脚的大容量 QuadSPI NOR Flash,但是这时候 FlexSPI DQS Pad 被解放出来了,这也是它的最主要意义。

7.png

别小看只是省了一个 DQS 引脚,也许你认为 i.MX RT 有那么多I/O ,省一个引脚意义不大,但是如果某些 FlexSPI 引脚组不带 DQS 信号,你又想配置 FlexSPI 以 60MHz 以上频率去访问 Flash,这时候 FlexSPI->MCR0[RXCLKSRC] = 2 选项就会帮上大忙了,见旧文 《不支持DQS的FlexSPI引脚组连接串行NOR Flash注意事项》

四、loopbackFromSckPad使用限制

FlexSPI->MCR0[RXCLKSRC] = 2 选项虽好,但有如下两个实际使用限制:

  • 存在信号完整性问题:主要出现在 SCK 频率过高或者板级 PCB 上 SCK 信号走线过长时。

  • SCK自由运行模式下不可用:对于某些 FPGA 应用,有时需要设置 FlexSPI->MCR0[SCKFREERUNEN] = 1,即 SCK 需要持续给外部设备内部 PLL 提供参考时钟。

来源:恩智浦MCU加油站

免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 3

作者 | strongerHuang

微信公众号 | 嵌入式专栏

STM32CubeMX中Cortex系统定时器(System Timer)选择1分频和8分频,为啥生成代码一样?

“STM32的SysTick时钟源来自哪里?"

因为STM32CubeMX会启动SysTick作为延时(HAL_Delay)函数的时基,而SysTick作为Cortex内核的一部分,就会用到Cortex系统定时器。

那么,问题就来了SysTick时钟源来自哪里?

1、数据手册和STM32CubeMX时钟树

数据手册时钟树:

“STM32的SysTick时钟源来自哪里?"

STM32CubeMX时钟树:

“STM32的SysTick时钟源来自哪里?"

你会发现:数据手册中的只有『/8』分频,而STM32CubeMX除了『/8』分频,还有『/1』分频。

2、SysTick时钟初始化代码

不管是使用标准外设库,还是HAL库,你初始化SysTick,都会调用内核中的SysTick_Config函数。

标准库常用初始化:

SysTick_Config(SystemCoreClock / 1000);

HAL库初始化同样也是调用底层的初始化函数:

uint32_t HAL_SYSTICK_Config(uint32_t TicksNumb)
{
   return SysTick_Config(TicksNumb);
}

初始化调用这段代码之后,SysTick将会实现1ms中断一次。

这段代码实现1ms中断一次相信大家都能理解,但是这里SysTick初始化和上面说的时钟『/8』有关系吗?

3、SysTick时钟源是来自哪里?

这个问题只要认真看参考手册都能找到答案。

RCC通过AHB时钟(HCLK)8分频后作为Cortex系统定时器(SysTick)的外部时钟。

通过对SysTick控制与状态寄存器的设置,可选择上述时钟或Cortex(HCLK)时钟作为SysTick时钟。(--来自参考手册)

也就是说SysTick时钟源可以来自两个地方:

  • AHB时钟8分频

  • HCLK(内核)时钟

通过SysTick控制与状态寄存器的设置进行选择时钟源。

具体就是通过CLKSOURCE(时钟源)这一Bit位来选择:

“STM32的SysTick时钟源来自哪里?"

再次看SysTick_Config函数源码:

__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)
{
  if ((ticks - 1UL) > SysTick_LOAD_RELOAD_Msk)
  {
    return (1UL);                                                   /* Reload value impossible */
  }

  SysTick->LOAD  = (uint32_t)(ticks - 1UL);                         /* set reload register */
  NVIC_SetPriority (SysTick_IRQn, (1UL << __NVIC_PRIO_BITS) - 1UL); /* set Priority for Systick Interrupt */
  SysTick->VAL   = 0UL;                                             /* Load the SysTick Counter Value */
  SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk |
                   SysTick_CTRL_TICKINT_Msk   |
                   SysTick_CTRL_ENABLE_Msk;                         /* Enable SysTick IRQ and SysTick Timer */
  return (0UL);                                                     /* Function successful */
}
(在core_cm3.h,或者core_cm4.h等内核源码中)

你会发现,其实源码已经默认使用HCLK(内核)时钟。

而SysTick_Config函数属于内核(如core_cm3.h)已经写好源码,一般我们不去修改。

所以,到这里,你会明白:SysTick时钟源其实就是用的HCLK(内核)时钟。

4、最后

开篇的问题:STM32CubeMX中Cortex系统定时器(System Timer)选择1分频和8分频,为啥生成代码一样?

“STM32的SysTick时钟源来自哪里?"

难道,STM32CubeMX配置Cortex系统定时器时钟是有Bug吗?

来源:嵌入式专栏
免责声明:本文为转载文章,转载此文目的在于传递更多信息,版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题,请联系小编进行处理(联系邮箱:cathy@eetrend.com)。

围观 32
订阅 RSS - 时钟源