Ситуация такая:Имеется устройство, на базе SAM7S64. Оно работает с дискретными входами и выходами. Плюс общение по протоколу ModBus на RS-485. У устройства есть 16-ти битные и дискретные регистры (массивы просто) в которых хранятся настройки этого устройства (адрес, скорость и тпх). Так как никакой внешней флэшки не сделали, пришлось использовать для хранения внутреннию флэш. Для работы с которой я взял функцию, описанную в этой ветке http://electronix.ru/forum/index.php?showt...Sxx+flash+write . Получилось следующее: приходит команда по ModBus (05h или 10h) я делаю изменения в массивах-регистрах. отвечаю мастеру и ухожу на запись этих настроек во внутреннею флэш. Количество записей понимаю что ограничено, заказчик тоже это знает и его это вполне устраивает. Для него главное конечный размер устройства - как можно меньше чтобы был. После любой записи во флэш, я перегружаю контроллер, чтобы инициализировать новые настройки. И при включении (перезагрузки) читаю эти настройки из флэш, используя ту же функцию.Привезли устройства заказчику. Он объеденил это в сеть и стал тестировать. Получилось следующее: допустим он сконфигурировал (командами 10h и 05h) устройство с адресом 9 и перешел на следующее. После записей он проверял. верные ли настройки записаны - во всех случаях оказалось что верные. Тогда он переходил на следующее. Когда все устройства были сконфигурированы. он попытался еще раз прочитать настройки у каждого. и оказалось что одного все эти данные были сброшены в FFh ... такое ощущение, что при записи страница была стерта, а массив записан не был. Вобщем из 50 устройств 3 штуки выдали вот такую вот фигню. В разное время. Самое главное, что при не понятных обстоятелствах настройки сбрасывались. Я сегодня приехал к ним и мы пытались вызвать такую ситуацию еще раз, но нас ничего не вышло .... Работают как часы.На что грешить? куда смотреть? Меня тут уже пугали и плохой партией контроллеров (якобы контроллер памяти глючный), и корявыми руками программиста (увы, признаю, что они не слишком прямые), и даже солнечным затмением (вся эта фигня произошла именно в понедельник. когда утром было замение) .... Я брал устройства себе домой, делал все также. как и они там, и ни разу не выпадало такого, чтобы вместо нужных байтов, он мне записал FFh. Что ж это такое? Программа? Или аппаратная проблема?

Я бы смотрел в сторону программы. В реальной сети постоянно бегают какие-то пакеты, на столе обмен поменьше.

Это то понятно, что их там до фига бегает. Но для этого и нужно проверить адрес (свой ли?), затем проверить CRC (совпадает ли?). Ведь если CRC не совпало - посылку откидываем. Опять же я беру CRC не последние два байта в посылке, а зная какая команда пришла у меня. я вычисляю какой длины должна быть посылка и потом только беру байты CRC. Помоему совпадение (трижды!) на трех устройствах за один день - это что-то многовато. Опять же теже пресловутые 3,5 байта жду ... ну вроде бы куча защит, чтобы не словить случайную посылку, которую мастер вовсе не отправлял.

Сталкивался с подобным цирком на мегах. В принципе может проскочить программный косяк. Советую немножко переиграть запись параметров и писать их в несколько последовательных страниц. Тогда можно будет отследить историю.
Как вариант прицепить 24-ю память и писать в нее лог полученных команд. Сверить потом с поданными.

Понятно. Спасибо, попробую. Только все осложняется тем, что этот косяк выскочил по одному разу на трех устройствах, и было это не при мне. Я же у них уже второй день пытаюсь добится того же, но не выходит. Запись происходит идеально. То есть я даже не знаю какие пакеты в тот момент гуляли в сети. Хотя они говорят что был косяк один с их стороны: два устройства сделали с одним адресом. Может дело и в этом. но тоже сильно сомневаюсь.

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

Все прерывания отключаются. Настройка PLL взята из стандартного проекта.

А в том же треде есть такое:


Мож тут грабли? Не дожидаять реального конца записи уход на ресет.

Возможно. Но перед ресетом я сделал задержку в 30 мс (думаю достаточно?). Записываю всего одну страницу.

Фигли тут сомневатся. просто повтори косяк и понаблюдай. Веди лог пакетов.
Синхронизацию по началу пакета жесткую сделай, то есть при приеме маркера начала пакета начинай принимать пачку заново.

Да как я только не повторял косяк. И с теми же адресами, и с другими. Да, вижу что посылка уходит, а возвращается ну полная белеберда, так как они оба начинают отвечать. Да только, ошибки такой и не повторилось. Согласен, что когда они начинали отвечать одновременно, то у меня было такое, что первый байт пакета (адрес) изменялся на адрес еще одного устройства, и то устройство считало что посылка для него, но! CRC то не совпало, поэтому устройство считает что пакет принят с ошибкой и откидывает его. Вот и все. Не совсем понял идею, извините. Я пользуюсь DMA, у меня стоит прерывание на таймаут, то есть если у меня таймаут превышает 1,5 байта, то я считаю что посылка принята и начниаю её обработку. Согласно указаниям ModBus. Проверяю адрес, CRC и если все совпадает, обрабатываю посылку и посылаю ответ. Или вы что-то другое имели ввиду?

Ааа rtu modbus... идея снимается.