Софтовый сброс atxmega128a1u, где хранить данные об этом

[imhoteb]

Начальный сброс atxmega128a1u. Помогите в одном моменте разобраться, при старте (при сбросе МК) все значения устанавливаются в первоначальные значения в тех или иных регистрах. Но вот явно про SRAM и регистры R0-R31 не сказано. Хотя беру отладчик ATMEL-ice и девайс с ATMEL studio и четко видно что бы я не поставил, при сбросе МК все это обнуляется в значение 0. Где правда то. Нашел только в тексте к МК в описании, что при сбросе МК SRAM сохраняется... Но отладчик содержимое МК показывает получается иначе, SRAM явно очищается. Тогда где сохранить перед программным сбросом МК какие то параметры.

[imhoteb]

Софтовый сброс atxmega128a1u, где хранить данные об этом. Хочется сделать сброс, но перед этим где то сохранить какую то переменную, чтобы потом программу перевести в нужную ветку после сброса. Но вот не задача, что регистры R0-R31, что GPIO регистры, что SRAM судя по отладчику через ATMEL -iсe, все обнуляется... Хотя в тексте я нашел что при сбросе МК SRAM сохраняется... Но отладчик содержимое МК показывает получается иначе, SRAM явно очищается.

[mike-y-k]

imhoteb
1. Повесить на I2C/SPI flash/fram/sram модуль памяти и писать туда.
2. Писать через UART на ПК.
3. Сделать свой внешний логгер на I2C/SPI/UART (можно даже универсальный) в нужном количестве экземпляров и пользоваться им в удовольствие. Запись вести на карту памяти с возможностью замены. Решение будет на все случаи жизни.

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

[ForcePoint]

Софтовый сброс atxmega128a1u, где хранить данные об этом.

На Сахаре всё ответили. Если действительно пишешь на асме - такого быть не должно. Если Си - делай переменную в _no_init секции ОЗУ и в прологе Си-программы она не будет сбрасываться в 0.

1.
2.
3.

Overkill.

[mike-y-k]

ForcePoint, для конкретной архитектуры правильное решение, но таки лучше выбирать для реализации что-то, работающее всегда и везде или пользовать только одно семейство до окончания производства/пенсии…

[ForcePoint]

для конкретной архитектуры

Да ладно! Разве есть какие-то МК, где есть аппаратный сброс ОЗУ? Так-что проблема не в МК, а в Си (пролог).

[mike-y-k]

ForcePoint Вопрос правильного размещения и инициализации переменных конечно же имеет место быть .
Но завтра ещё и с восстановлением после вариантов hw_reset возникнет желание продолжить с прерванного места или даже на другой плате просто повторить для тестирование именно с нужного места, или… и опять пойдут вопросы.
Таки нечто внешнее и для отладки, и для работы в изделии сильно предпочтительнее.
Заодно кругозор расширится.
А ТС таки стоит почитать ещё раз описание языка, работу памяти и с памятью во всех ее ипостасях.
Вектор направления есть, осталось прочитать и систематизировать полное описание.

[МВА]

А какой смысл? При старте МК программа начинается с начала и любая программа при работе с нуля должна инициализировать свои переменные. А при этом, даже если в SRAM что-то осталось, все-равно перепишется. Если это какие-то изменяющиеся настройки, то лучше всего их сохранять или во внешней памяти, или во флеш, а при старте производить инициализацию переменных из этой памяти.

[STM32F0]

А какой смысл?

Не мешай. "Народ для изврата собрался!"(с). Щас эти дядьки любую здравую мысль влёгкую до работы гинеколога сведут.

Два варианта развития разговора "ни о чём" от этих светил уже в наличии.
1. Виноват МК.
2. Виноват Си.

Будем посмотреть.

[makakus]

При старте МК программа начинается с начала и любая программа при работе с нуля

... даже знает, с какого нуля - включение питания / аппаратный сброс / воч-дог...
ОЗУ точно никто не сбрасывает: пиши в нужное место с CRC для уверенности... есть же и внешняя память. А есть память NVRAM/ Это такой кодавр, который пишет себе в RAM, а когда питание выклюяается, успевает переписать свою RAM в свой же PROM. Окак!