lotor

Он уже на оф. сайте доступен. :)

Улыбнуло. Терра такую наценку делает, что это должно быть подозрительно, а не адекватные цены стартеркита. Цены именно боле-менее адекватные, а не дешевые. Не бойтесь, брал у них пару плат, jlink и altera blaster - проблема была только на одной плате, поменяли без вопросов.

Эти прерывания типичны не только для атмелов, мне понравилась объяснение в этом документе от nxp - Handling of spurious interrupts in the LPC2000.

Речь шла о том, что помогло решить проблему и что дает static у локальных переменных. Другое дело, что это костыль. Так вроде мы и не из этих, которые свои косяки валят на компилятор, кристалл или фазу луны. :) Увы, воспроизвести "по заказу" не могу, поэтому добавляю тему в закладки - и как только, так сразу.

Вы заблуждаетесь, логика присутствует. :) При static локальная переменная будет жить в глобальной области памяти, а не на стеке. И именно поэтому проблемы исчезали. PS: На работе попробовал по памяти набросать код, который вызывал когда-то проблемы (чтобы осмысленно глянуть в дизассемблер) - в функции локальный массив или указатель передается дальше. Но увы, всё работает, как надо при любой оптимизации. =) Помню, когда в последний раз такое случалось, я перенес аналогичный код в iar'овский компилятор - там без static работало. И т.к. это был не первый случай, то старался больше не рисковать и ставил static у локальных указателей и массивов, если они идут дальше (реентерабельность не требовалась). Прочитав эту тему по диагонали и заметив знакомую проблему, удивился что уважаемый aaarrr очень уверенно говорит, что дело не в компиляторе. Может оно и так, но помимо меня как минимум еще двое испытывают похожие проблемы.

Я это к тому, что еще с тех пор взял за правило ставить static у локальных переменных в функциях, если они идут дальше. Я к этому мнению пришел недавно, намного позже, чем стал ставить static у локальных переменных. =) Поэтому и хочу при наличии времени поиграться именно с дизассемблером.

С Кейлом знаком еще по 51 семейству, еще тогда были проблемы с локальными переменными, если их передавать в функции (при чем в свои, а не в sprintf) и не обозвать static. Для arm аналогично, будет время покопаю этот момент.

Вы хотите именно с иксами найти? Там конкретный кристалл указывается.

Вы всё еще выбираете? Хотя да - 7 раз отмерь... Но главное успеть отрезать же. %) И что есть в вашем понимание "аппаратная поддержка ОЗУ"? Из описания платы MLPC1788: Да я думаю все Cortex M3 имеют контроллер памяти, если только не совсем малоногие.

Только 99% у pan_oleg именно слетела прошивка. У меня c j-link такое раза 3 было, пришлось восстанавливать по стандартному алгоритму.

Ставьте SDRAM, в микроконтроллере настроите модуль внешней памяти и сможете обращаться к SDRAM, например, по указателю.

Ну тогда расскажите, пожалуйста, из каких соображений вы уверены, что так должен стоять стабилитрон - в таком включении он ограничивает напряжение на входе АЦП в рамке -3,33 до +0.6 вольт. Недавно читал перевод статьи о вопросах на собеседовании по СИ для программистов микроконтроллеров, так под ней один из комментариев был в стиле "сам многое не знаю, но завтра буду собеседовать человека по этим вопросам". Похоже тут аналогичное.

Вы уверены, что правильно поставили стабилитрон в вашем тестовом задании? %)

Для меня армовская архитектура более удобна, чем пиков или авр. Не вижу доводов , чтобы начинать не с arm.

Я предлагаю вам для поиска проблемы для начала использовать только это прерывание - переводите rs485 на передачу, в самом прерывании выгребаете очередь, когда она будет пуста переводить rs485 на прием. Есть вероятность, что в такой реализации потери исчезнут.

В регистр загружается именно значение, почитайте тут например.

Настраиваете EMC для работы с ней и вперед - ничего сложного. Исходники можно увидеть в code bundle для lpc23/24.

Я могу ошибаться, но смотрите, приоритет USART1_UDRE_vect выше чем USART1_TX_vect. И т.к. последнее разрешено всегда, то оно может вклиниться в неподходящий момент. Вот и потеря данных. Вообщем, самое простое - это переписать для начала код, чтобы использовалось одно прерывание USART1_TX_vect. Если потери исчезнут - то будете знать, где копать.

Согласен, просто меня жизнь научила, что если есть пусть и маловероятная, но возможная ситуация - она случается. =) Поэтому даже с вышеуказанными вами мерами безопасности есть шанс, что у залитой (но плохо протестированной) прошивки со временем отваливаются какие-то важные функции, включая обновление ПО. И в этом я вижу единственный минус такого подхода к загрузчику.

Зачем столько эмоций, я лишь показал вам две потенциально возможных ситуации, когда назвать такую реализацию 100% надежной нельзя. А злодеи могут быть и бывшими сотрудниками вашей фирмы, которые затаили обиду. :)

Абсурдные идеи говорите? Представьте, что кто-то хочет сделать диверсию на вашем приборе и выставить фирму в неприглядном свете, он просто зальет 3 левых байта с правильной crc. И как удаленно вы почините такое при вашей "100% надежной" реализации?)

По-моему обойти это можно только, если неизменяемый загрузчик в первом секторе флеш, зашиваемый вами на заводе, будет иметь возможность "засасывать" прошивку из вне.

У вашего подхода есть минус. Представьте ситуацию - загруженная прошивка в девайс имеет правильную crc, но сама по себе так испорчена, что не позволяет загрузить новую прошивку.

Буду признателен. :)

Можно и на ftp залить... :)