[参考译文] AM2434：在 TMDS243EVM 定制板上同时使用 PSRAM 和闪存(OSPI0中连接了闪存和 RAM)

您好、Anand、我们将在内部讨论此问题并返回给您

谢谢您、

Paula

您好、

感谢您的耐心。

的确、不同的片选将用于寻址两个不同的从器件。 如果不是从器件、则有两个不同的器件、例如 PSRAM 和八通道/四通道 NOR/NAND 闪存。

您是否希望两者都处于同一芯片选择上？ 我认为这将是一个错误的理解。

阐明上述内容后、我们可以区分 以下各项。

Unknown 说：

但是、我们在管理诸如 Flash_open 和

此致、

Vaibhav

尊敬的 Vaibhav：

感谢您的答复。 我了解芯片选择的用例、但对于该特定的定制电路板、我们使用高速开关来控制 PSRAM 和闪存。 那么、为什么需要片选呢？ 我附上了一个屏幕截图供您参考。

(请查看此链接： business-sdk/am243x/examples/ospi/ospi_PSRAM_IO/am243x-evm/r5fss0-0_nortos/Docs··(位于主 TexasInstruments/Beyond-SDK GitHub 上)

硬件使用两个芯片选择、因此我们需要对它们以及高速开关进行控制。 您能解释一下我们如何在代码库中管理这两个设备吗？

此外、如您所知、在 SysConfig 中、我们只能配置一个芯片选择。 因此、我们需要手动配置其他芯片选择

我将与 Paula 讨论此问题、并在我有进一步的更新后告诉您。

谢谢、

Vaibhav

尊敬的 Anand：

我和 Paula 进行了简短的讨论、他对此有更多的背景。

我认为、根据原理图、当发生开关时、所有线路都会在以下位置切换：

1. OSPI1_xxx 是 OSPI 闪存
2. OSPI2_xxx 为 PSRAM - OSPI RAM

您能否验证调用 PSRAM Open 和 Flash Open 之间所执行的步骤？

我假设您至少要执行以下操作：

PSRAM 打开

开关逻辑

闪存打开

请纠正我的理解。

此致、

Vaibhav

尊敬的 Vaibhav：

我将解释测试应用的步骤：

1. 默认情况下、在中 sysconfig、我们为闪存配置 CS0。
2. 我们需要在中手动配置另一个芯片选择引脚(CS1) main.c。
3. 首先、我们调用250µs RAM 测试函数(我们使用 FreeRTOS -定义了两项任务、一项是250us RAM 测试任务、另一项是2ms 闪存测试任务)、用于为 RAM 选择所需的芯片选择(CS1)。 我们需要控制 I2C 扩展器、以将多路复用器设置为低电平(低电平= RAM)。 然后、我们关闭闪存并打开 PSRAM。
4. 接下来、我们调用2ms 闪存测试函数、该函数为闪存选择所需的片选(CS0)。 我们需要控制 I2C 扩展器、以将多路复用器设置为高电平(高电平=闪存)。 然后、关闭 PSRAM 并打开闪存。 (注意： Psram_close() 不执行任何操作；它只是返回。)
5. 步骤3和4将以类似的方式继续。

我们正在遵循上述步骤、但 Flash_open() 功能存在问题。 它始终会失败、导致代码在那里置为有效。 我怀疑问题是由于对闪存和 RAM 使用 OSPI0并尝试创建似乎不允许的实例。

您能查看一下这个问题并为我提供帮助吗？

尊敬的 Anand：

在 Flash_open 时、能否将范围缩小到错误发生的位置？

你能进入 Flash_open() API 并告诉我到底是在哪里抛出异常还是错误吗?

如果可能、请分享屏幕截图。

注意：

我还需要一个配置值片段、如下面的屏幕截图所示。

当您输入 API Flash_norOspiOpen 以及转至该行时、请拍摄此快照  

期待您的答复。

此致、

Vaibhav

尊敬的 Vaibhav：

请查看下面的屏幕截图、

配置值：

2.函数- Flash_norOspiOpen 的屏幕截图

问题在于 Flash_norOspiReadId() 函数、该函数会始终返回故障、 Flash_open() 也会导致函数出现故障。

屏幕截图：

您可以首先加载 PSRAM 示例代码(这将按预期工作)、在特定 EVM 下重现此问题。 然后、在不执行上电复位的情况下、尝试加载任何闪存示例。 我使用的 ospi_flash_io_am243x-evm_r5fss0-0_nortos_ti-arm-clang 是示例。 您会注意到示例代码无法打开闪存。

(对于这个特定测试、在 Flash_IO 示例代码中、我关闭闪存和驱动程序、执行系统取消初始化、然后重新初始化所有内容。 尽管采取了这些步骤、但仍然不起作用。)

尊敬的 Anand：

您显示的所有值看起来都完全正确。

我想问一点、您在应用程序 SysConfig 的 OSPI 部分中设置的时钟频率和时钟分频器值是多少？

Unknown 说：

(对于此特定测试、在 Flash_IO 示例代码中、我将关闭闪存和驱动程序、执行系统取消初始化、然后重新初始化所有内容。 尽管执行了这些步骤、但仍然无法正常工作。)

很高兴知道这些步骤要重现。

请允许我用一段时间来完成这个过程并进行重现。

在进行更新时、我会向您提供状态更新。

此致、

Vaibhav

尊敬的 Vaibhav：

我附上了 OSPI 接口的时钟频率和分频器值的

由于我使用的是 SDK 示例、因此没有进行任何配置更改。

我一直在探索其他一些 E2E 问题、发现了这个 链接。(点击下面的 链接)它清楚地表明不可能在 OSPI 接口中使用不同的存储器器件。 您可以查看这些链接吗？

在 OSPI 示例中、我没有调用 IO 扩展器函数进行切换、这可能是导致该问题的原因。 您还能检查一下这方面吗？ 我在加载 OSPI 示例之前从 CCS 执行 CPU 复位、假设这就足够了。 如果我错了、请纠正我。

嗨 Anand ,只是好奇,如果你做的另一个方式(第一个 Flash 示例,然后 PSRAM)它工作?

谢谢您、

Paula

是的、Paula、它是功能性的。

Unknown 说：

我能够在运行时在 PSRAM 和闪存之间切换。

如前所述,每次我需要控制 IO 扩展器时,关闭闪存( flash_close() 如果我使用 PSRAM ),关闭 OSPI ,重新打开 OSPI ,更改芯片选择,然后打开 PSRAM 或闪存(使用 Psram_open() 或 Flash_open())。 我认为、这些步骤对于在两者之间切换是必要的。 您能否检查一下是否有任何方法可以优化这些步骤？

[/报价]

我在与 Paula 通话时能够实现的同样逻辑、唯一的问题是我重新加载了另一个执行 OSPI 闪存操作的应用、以及一个用于 PSRAM 的单独应用。 我看到你们集体做了这件事。

Unknown 说：

更改芯片选择

您能告诉我们您是如何做到这一点的吗？ 我知道如何将 IO 扩展器0x13从1切换到0、但 CS1已经在从 SysConfig 生成的引脚多路复用配置文件中定义。 如何在 pinmux 配置文件中定义 CS0？

[/quote]

OK Vaibhav、

我附加了用于更改芯片选择的代码片段。 请检查 它

驱动程序 ospiClose()；
驱动程序 ospiOpen ();
//选择 CS0 -用于闪存
regVal = CSL_REG32_RD (&preg->CONFIG_REG)；
chipSelect = OSPI_CHIP_SELECT (OSPI_CS0)；
decSelect = OSPI_Decoder_SELECT4；  
regVal &=~(CSL_OSPI_FLASH_CFG_CONFIG_REG_PERIPH_SEL_DEC_FLD_MASK |\
CSL_OSPI_FLASH_CFG_CONFIG_REG_PERIPH_CS_LINES_FLD_MASK)；
regVal |=(decSelect << CSL_OSPI_FLASH_CFG_CONFIG_REG_PERIPH_SEL_DEC_FLD_SHIFT)|\
(chipSelect << CSL_OSPI_FLASH_CFG_CONFIG_REG_PERIPH_CS_LINES_FLD_SHIFT)；
CSL_REG32_WR (&preg->CONFIG_REG、regVal)；

状态= Board_driversOpen ();

对于引脚配置、我使用一个在系统初始化期间将调用的单独函数。 我创建了一个 Pinmux_PerCfg_t 仅由 CS1引脚(L18)组成的结构变量。 (我正在 SysConfig 中使用 CS0)

尊敬的 Anand：

感谢您提供更新。

当前未决问题是：

Unknown 说：

在两者之间切换。 您能否检查是否有任何方法来优化这些步骤？

是、这是必需的。

Unknown 说：

我注意到 Psram_ospiOpen() 函数中添加了一些延迟、延迟量为500ms。 您能解释一下为什么需要这么长的延迟吗？ (我已经看到在几个地方增加了这个延迟。)

我将与 Paula 核实为什么添加这些。

此致、

Vaibhav

尊敬的 Anand：

我已经在没有睡眠 API 的情况下测试了 PSRAM 的打开、关闭、写入、读取和复位 API、并且所有函数都成功了。

我已经测试了大约1000个周期。

请删除/注释睡眠 API 并告诉我您看到的行为。

此致、

Vaibhav

是的、Vaibhav、我们已经删除了这些延迟。