STAM32F4 FSMC / FMC SRAM в виде кучи / стека приводит к случайным аппаратным сбоям - PullRequest
Новая
       106

STAM32F4 FSMC / FMC SRAM в виде кучи / стека приводит к случайным аппаратным сбоям

0 голосов
/ 05 декабря 2018

в настоящее время мы оцениваем использование внешней SRAM для кучи памяти C / C ++ на нашей платформе с использованием микроконтроллера STM32F439BI.

Проблема

Использование SRAM в качествехранение кучи приводит к случайным сбоям, возникающим из-за ошибок / неточных ошибок.Без размещения кучи в памяти SRAM тесты памяти успешно выполняются на всей памяти SRAM (8-битный / 16-битный и 32-битный доступ).Подключая отладчик, я иногда наблюдаю эти ошибки до того, как произойдет сбой.Чаще всего слово читается из SRAM, а регистр ЦП заполняется адресами следующего формата: 0x-1F3-1F3 (- чаще всего это «0», иногда «A» или «6»).Паттерн «1F3» сохраняется.Если этот же адрес читается снова через несколько строк, читается правильное значение (другой адрес в 0x60000000).Если я остановлю программу на точке останова в какой-то момент в начале программы и перешагну несколько строк, я получу эти ошибки чаще.

Дополнительная информация

  • SRAM подключается с использованием периферийного устройства FMC / FSMC на FMC банке 1 и SRAM банке 1 и, следовательно, отображается в памяти по адресу 0x60000000.
  • Все настройки для выводов GPIO и конфигурации FMC задаются из файла запуска доmain () выполняется или создаются статические объекты.
  • SRAM имеет следующий вид: CY7C1041GN30
  • Мы подключаем все 16 контактов данных, все 18 контактов адреса, BHE, BLE, OE, WE и CE к нашему контроллеру.Все контакты настроены как двухтактная функция, подтягивание, AF_12 (FMC), очень высокая скорость.Мы включаем часы для всех необходимых выводов и часы для FMC.Примечание. Изначально мы начинали без подтягивания / понижения, показывая те же симптомы.
  • Контроллер работает с тактовой частотой 168 МГц
  • Как указано выше, тест памяти проходит успешно
  • Мы используем DMA для передачи данных SPI, I2C и ADC
  • Мы часто используем прерывания, включая внешние (контактные) прерывания
  • Мы используем следующие настройки синхронизации:
    • AddressSetupTime: 2
    • AddressHoldTime: 4
    • DataSetupTime: 4
    • BusTurnAroundDuration: 1
    • CLKDivision: 2
    • Латентность данных: 2
  • Мы настраиваем FMC следующим образом:
    • NSBank FMC_NORSRAM_BANK1,
    • DataAddressMux FMC_DATA_ADDRESS_MUX_DISABLE,
    • MemoryType FMC_54MEMY* MemoryDataWidth FMC_NORSRAM_MEM_BUS_WIDTH_16,
    • BurstAccessMode FMC_BURST_ACCESS_MODE_DISABLE,
    • WaitSignalPolarity FMC_WAIT_SIGNAL_POLARITY_LOW_ * * * * * * * * * * *
    • WaitSignalActive FMC_WAIT_TIMING_BEFORE_WS
  • ContinuousClock FMC_CONTINUOUS_CLOCK_SYNC_ASYNC,
  • WriteFifo 0,
  • PageSize 0
Мы тратим много времени на эксперименты с более длительными таймингамии сравнил все настройки с примерами, включая этот: Использование STM32L476 / 486 периферийного устройства FSMC для управления внешней памятью (хотя этот параметр предназначен для STM32L4, я вполне уверен, что он применим и к этому контроллеру)

Результаты по аналогичным проблемам

  • Проблема звучит очень похоже на эту ошибочную ведомость запись: «2.3.4 Повреждение данныхчитать из FMC ", но он также говорит, что ошибка исправлена ​​в нашей ревизии tконтроллер (3)

Я надеюсь, что кто-то там уже видел это странное поведение и может помочь нам.После более чем одной недели отладки мы ожидаем некоторой ошибки в контроллере, когда происходит прерывание / доступ DMA, когда процессор обращается к SRAM (когда мы используем его как кучу, к нему обращаются очень часто).Надеюсь, вы сможете пролить свет на эту тему.

...