Я тебя понял. Тогда моя гипотеза не верна. Тогда перейдем на более
генеральные вещи. Тут вот что. Твоя мысль о том что ядро исполняет инструкции строго последовательно и для того
чтобы попасть на участок кода пишущий во FLASH должны выполниться
определенные условия.... не верна. В очень редкие моменты времени переходных процессов
питания ядро начинает хаотически блуждать и заходит в код
работающий с FLASH. Припоминаю аппноту (скорее всего от Microchip).
У них оч
. хорошие аппноты по поводу safety, reliability итд. Вообще, по компетенции в электрической-сигнальной части, по качеству документации ST н сравнятся с Microchip . Если ты помнишь, Microchip в своей либе даже регистры dsPIC'а проверяют. Так вот там и было сказано, мол никогда не рассчитывайте что код выполняется последовательно и даже с учетом проверок (имея "ключ"). Блуждающий проц мол все равно рано или поздно статистически попадает на код работы с FLASH/EEPROM. А вот как они защищались - не помню. Найти этот документ если постараться можно, в сознании всплывает еще что-то связанное с заполнением памяти (это было в этом документе). Я лично достаточно много наблюдал вопросов о порче флэша, поэтому принял радикальное решение: вообще никогда ничего не писать в FLASH, вообще не иметь программного кода который даже потенциально может запороть код/программу во FLASH, писать только во внешний EEPROM. Именно поэтому начиная с определенной ревизии мы поставили внешний копеечный I2C EEPROM (I2C мне не нравится, по мне так лучше SPI). Ещё, в промежуточных ревизиях плат наше производство не смущаясь спокойно клеит микрухи, подводит проводки и заливает всё компаундом/соплеклеем.
RxTx (12.07.2023 10:14, просмотров: 151) ответил my504 на Увы, но я уже написал - запись во флеш в составе этого стенда
принципиально невозможна. Выход в эту функцию связан с обменом. А
обмен отсутствует. Кроме того, в этой версии запись во флеш сделана
без скольжения и при рандомном нештатном обращении к этой функции я
бы давно испортил флеш.