[bureau 0]

STM32, но сама функциональность есть так же и в микроконтроллерах от других вендоров

В програме реальзован алгоритм обработки "SRAM2 parity check". 

Теперь стоит задача когда нужно создать условия при которых можно будет проверить данную функциональность. Идея с неинициализированной областю SRAM2 -- уже протестирована. Но это более искуственные условия, а вот возможно ли создать какие-либо реальные условия когда данная ошибка может произойти. Может у кого есть какие идеи?

[Arlleex 131]

Пользователи: "Нам нужна SRAM"
Технический прогресс: " Вот, пожалуйста, держите."
П: "Ммм... Очень редко происходят битовые ошибки! Придумайте что-то, чтоб само исправляло"
ТП: " Вот, мы сделали паритет и ECC, было довольно трудно, мы потратили много денег и времени на разработку и внедрение."
П: " етот ваш паритет мешает нам, как его отключить?"
ТП: ""

 (шутка)

P.S. Впаять чип в кривуще разведенную плату, отдать в испыталку на НИП-помехи, радиочастотное облучение полем. Ждать.
А можно еще отдать в центр, где микросхемы проверяют на живучесть ионизирующим облучением.

[jcxz 184]

2 часа назад, bureau сказал:

Может у кого есть какие идеи?

Overclocking/overheating/etc.?

А какой смысл? Как я понял - работу самого механизма и реакции программы на него вы уже проверили? Имхо - этого вполне достаточно.

Или вы каждый регистр периферии и процессора и каждую команду процессора проверяете на работоспособность?  

[bureau 0]

Изначальная причина данного топика состоит в том что приложение начало выпадать в "SRAM2 parity check"
На данном этапе как раз и пытаемся понять в чем может быть причина. Склоняемся к тому что это "корявое поведение приложения"

[Arlleex 131]

В память писали до чтения? После сброса, имею ввиду.

[jcxz 184]

4 часа назад, bureau сказал:

Изначальная причина данного топика состоит в том что приложение начало выпадать в "SRAM2 parity check"

Обычно это следствие чтения памяти до её записи. А если контролем чётности защищается не только ОЗУ CPU, но и ОЗУ каких-то периферийных блоков (FIFO, etc.), то простое включение тактирования таких блоков (без предварительной записи содержимого всего их внутреннего ОЗУ) может приводить как раз к таким fault-ам.

Если есть возможность - включайте контроль чётности по частям (по регионам ОЗУ) и ищите проблему методом исключения.

Всё ОЗУ, имеющее контроль чётности, должно быть в обязательном порядке проинициализировано записью до первого чтения. Любого чтения, кто бы это чтение не совершил (не обязательно CPU).

[bureau 0]

3 часа назад, Arlleex сказал:

В память писали до чтения? После сброса, имею ввиду.

Да. Все как по инструкции прямо в Reset_Handler, после чего переходит на системный main

Note: When enabling the RAM parity check, it is advised to initialize by software the whole RAM 
memory at the beginning of the code, to avoid getting parity errors when reading non-initialized locations

 

[Arlleex 131]

Понял. Ну, что ж. Тогда, наверное, никак. Для того оно и было придумано