STM32F4 FSMC / FMC SRAM，因为堆/堆栈会导致随机的硬故障

Question

我们目前正在评估使用STM32F439BI微控制器在平台上使用外部SRAM进行C / C ++堆存储。

问题

使用SRAM作为堆的存储空间会导致随机的硬故障，这些硬故障是由buserrors / impcice buserrors引起的。 在不将堆放在SRAM上的情况下，内存测试可以在整个SRAM上成功运行（8位/ 16位和32位访问）。 连接调试器我有时会在发生硬故障之前观察到这些错误。通常，从SRAM读取一个字，CPU寄存器填充以下格式的地址：0x-1F3-1F3（-通常为'0'，有时为'A'或'6'）。模式“ 1F3”持续存在。如果再次读取相同的地址，则再往后几行读取正确的值（其他地址在0x60000000空间中）。 如果我在程序的某个早期在某个断点处停止该程序并执行几行，那么我会更频繁地得到这些错误。

更多详细信息

• 使用FMC库1和SRAM库1上的FMC / FSMC外设连接SRAM，因此将其内存映射到地址0x60000000。
• 在执行main（）或创建静态对象之前，从启动文件中设置GPIO引脚和FMC配置的所有设置。
• SRAM如下：CY7C1041GN30
• 我们将所有16个数据引脚，所有18个地址引脚BHE，BLE，OE，WE和CE连接到我们的控制器。所有引脚均配置为推挽备用功能，上拉，AF_12（FMC），极高速度。我们为所有必需的引脚启用时钟，为FMC启用时钟。注意：最初，我们开始时没有出现相同症状的上拉/下压。
• 控制器以168 MHz的时钟速度运行
• 如上所述，内存测试成功运行
• 我们将DMA用于SPI，I2C和ADC数据传输
• 我们经常使用中断，包括外部（引脚）中断
• 我们使用以下计时设置：
  • AddressSetupTime：2
  • AddressHoldTime：4
  • DataSetupTime：4
  • BusTurnAroundDuration：1
  • CLKDivision：2
  • DataLatency：2
• 我们将FMC配置如下：
  • NSBank FMC_NORSRAM_BANK1，
  • DataAddressMux FMC_DATA_ADDRESS_MUX_DISABLE，
  • MemoryType FMC_MEMORY_TYPE_SRAM，
  • MemoryDataWidth FMC_NORSRAM_MEM_BUS_WIDTH_16，
  • BurstAccessMode FMC_BURST_ACCESS_MODE_DISABLE，
  • WaitSignalPolarity FMC_WAIT_SIGNAL_POLARITY_LOW，
  • WrapMode FMC_WRAP_MODE_DISABLE，
  • WaitSignalActive FMC_WAIT_TIMING_BEFORE_WS，
  • WriteOperation FMC_WRITE_OPERATION_ENABLE，
  • 等待信号FMC_WAIT_SIGNAL_DISABLE，
  • ExtendedMode FMC_EXTENDED_MODE_DISABLE，
  • 异步等待FMC_ASYNCHRONOUS_WAIT_DISABLE，
  • WriteBurst FMC_WRITE_BURST_DISABLE，
  • ContinuousClock FMC_CONTINUOUS_CLOCK_SYNC_ASYNC，
  • WriteFifo 0，
  • PageSize 0
• 我们花费了大量时间尝试更长的时间，并将所有设置与包括该设置的示例进行了比较：Using STM32L476/486 FSMC peripheral to drive external memories（尽管该设置适用于STM32L4，但我相当确定它也适用于该控制器）

关于类似问题的发现

• 该问题听起来与以下errata sheet条目非常相似：“ 2.3.4从FMC读取的数据损坏” ，但它也表明该错误已在我们的控制器修订版（3）中得到修复< / strong>

我希望外面的人以前已经见过这种奇怪的行为，可以为我们提供帮助。经过一个多星期的调试，我们预计当CPU访问SRAM时发生中断/ DMA访问时，控制器中会出现某种错误（当我们将其用作堆时，访问频率很高）。希望您能对此主题有所启发。

Answer 1

很抱歉，互联网无法及时回复您。

是的，我们发现了问题所在（至少在我们的情况下）。问题是，如果我们使用的J-Link调试器悬挂在PCB上的电力电子设备上方（垂直安装），则会引起问题。如果我们将带状电缆从顶部引出（仅限数字电子设备），则错误消失。因此，我们的猜测是，来自电子设备的一些噪声被电缆捕获并直接注入JTAG端口，从而导致MCU内部发生故障。

Answer 2

仅从ST确认，如果禁用了写fifo，则STM32F469 FMC中存在一个错误，该错误可能导致错误的值。解决方法是启用fifo。这与此F7处理器https://www.st.com/resource/en/errata_sheet/dm00145382.pdf

中的问题相同

---

您找到解决方案了吗？我们在STM32F469上看到了相同的内容。 我们已经看到，当读取无效值时，不会从SRAM进行任何实际的读取。

我们发现在此表中将内部闪存时序从1更改为4 internal flash timing使一切正常。我们不知道是因为时间的改变导致问题消失，还是与内部闪存有关。 此处显示了不同配置下的问题值：

1 5WS 3V3（默认值）–地址为0x002e 002e的免费通话后发生的硬故障

2 5WS NO PRE –在地址为0x4b43 4b43的免费通话后发生HardFault

3 8WS 3V3 – libc中的HardFault，R3 = 0x6013 6013此值来自/的使用是未知的，所以可能没事

4个8WS NO PRE –没有错误。

请注意，它是使用相同的软件版本进行测量的。在启动过程中使用调试器更改了时间。

我们还发现，在失败的LDR指令之前添加两个NOP指令可以解决该问题。当然，这都不是永久性的解决方案。