oleghmt

Упс. Что-то от жары наверное, я соображать стал плохо. :-) Всё правильно: скопировал в память, сделал перезапуск, проверил в обработчике был ли перезапуск, если был - установил смещение, перешёл на вектор. Спасибо

В своё время писалась прошивка устройства с использованием FreeRTOS для AT91SAM7X. Сейчас перехожу на SAM3S и заканчиваю переносить код. Возникла описаная в заголовке проблема. В предыдущем процесоре, я просто скопировал основной проект, выбросил всё лишнее оставив лишь взаимодействие по USB и несколько команд своего интерфейса чтобы принять новую прошивку и записать её. После этого компилировал код в SRAM, превращал в масив и вставлял в основную прошивку. Когда устройство получало команду изменить прошивку, этот масив банально копировался в ОЗУ и выполнялся переход на начало кода в SRAM, что автоматически запускало процесор в режиме загрузчика прошивки. В новом процесоре возникает проблема с векторами прерываний - нужно изменить VTOR регистр, но это можно делать только в privileged режиме, куда можно попасть только вызвав обработчик exception, если я правильно понимаю. Сначала у меня была идея, после копирования кода в память, выполнять програмный reset и в resetHandler'е анализировать - если перезапуск вызван програмно, тогда изменять VTOR и переходить на код в ОЗУ опять вызывая reset. Но, похоже, это неправильный путь, так как во время перезапуска регистр смещения векторов обнуляется. SVC использовать не хочу, так как, этот вектор уже задействован FreeRTOS и ставить в обработчик какие-то проверки и условные переходы не очень хочется. Пока есть только идея использовать Usage Fault Handler - при старте основной прошивки разрешить его, а после копирования в память загрузчика прошивки, обратиться по невыравненному адресу (или вызвать деление на ноль). А в обработчике установить регистр смещения векторов и в асемблерной вставке выполнить команду перехода на ResetHandler в ОЗУ. Правильны ли мои намерения? Может есть какой-то другой путь? Хочется сделать, с одной стороны, попроще, а с другой - красиво и "правильно". :-) Ещё добавлю, что код для SAM3S пишу используя последнюю Аtmel Studio

увы, не доглядели. Теперь будем знать. Спасибо за помощь

Решили проблему кардинально :-) Связались с поставщиками процесора или с представительством Atmel (точно не знаю). Они порекомендовали поставить вместо 18.432, кварц на 12 МГц. самба 2.10 увидела процесор. Позже ещё попробую 2.11

понятно, попробую сегодня вечером на другой машине. Возможно всё потому, что на Win7 ставлю

А как в 2.10 выбирать не CDC? Установил, при установке вроде-бы не было никакой возможности выбора, в папке только один sam-ba_cdc.exe, в папке drv - inf для cdc. Тыкните, пожалуйста, носом :-)

И у меня вопрос по тому же поводу. Сколько смог перерыл интернет и форум, пока ничего решающего мою проблему не нашёл. Ближе к делу: 1. Разрабатывалось устройство на базе AT91SAM7X256. Для общих сведений - код писался с помощью CrossWorks 1.6 - 1.7, кварц 18.432, первая запись прошивки с помощью Sam-ba 1.11 через USB, обновления опять же через USB но уже своими програмами, своим прошивальщиком. 2. В процесе развития проекта решили перейти на AT91SAM3S4. Сделали железо, изменил програму в CrossWorks (пришлось поставить 2.1), скачал новую самбу 2.11, установил всё по инструкции (драйвера, подключение), пробую подсоединится - та же ситуация: при выборе no board самба подключается, даже можно посмотреть что твориться в памяти по различным адресам, а вот закладки записать во флеш нету, при выборе же в списке устройств at91sam3s4-ek - нажимаешь connect, исчезает окно, но GUI не появляется, samba висит в процесах. 3. Нашёл самбу 2.10 - ничего не изменилось. В самбе 2.9 - нет 3s процесора, только 3u. Пробовал на двух нотбуках с intel чипсетами и процесорами WinXP Win7, на стационарном компе AMD - ситуация одинаковая. Пробовал на самбе 2.11 подключиться к предыдущей версии устройства с SAM7X - всё работает нормально, отображается, прошивается. Соответсвенно вопрос - куда можно копать? 1. Не разбирался пока - если GUI не работает, можно ли работать через командную строку, сложно ли? Может можно где-то в скриптах что-то посмотреть-поправить, передачу данных по USB помониторить? 2. Возможно (хотя не верится), проблема в том, что изменилось подключение USB - убрали линию контроля наличия питания от хоста, на другую ножку перенесли ручное управление USB_PUP. 3. В принципе, возможны проблемы в железе - может и оно изначально не запускаться, хотя, если в режиме no board самба подключается и можно полазить по памяти, то напрашивается вывод, что тут всё нормально. Куда ещё можно посмотреть?

Здравствуйте Посоветуйте, пожалуйста, как можно исправить такую ситуацию. В своё время, разрабатывалось устройство на базе AT91SAM7X, которое, помимо всего прочего, управлялось с компьютера через USB с использованием виртуального COM-порта на базе драйвера usbser.sys. В качестве основы при этом был использован пример из FreeRTOS. Устройство нормально заработало, в связи с выходом SP3 появились проблемы - неработоспособность даной конфигурации. Более-менее просмотрев интернет в поиске решения проблемы минимальными средствами, увидел предложения отказываться от использования usbser.sys или заменять его файлом из дистрибутива WinXPSP2. С первым вариантом не очень хочется связываться, так как времени для написания собственного драйвера (а, в основом, для изучения как это делать) особенно нету. В другом варианте недостаток - виндовс, по словам пользователей устройства, иногда не даёт заменить драйвер возвращая старый на место. Да и непонятно, как отобъётся замена файла более старым на работоспособность других частей виндовс. Я попробовал переименовать старый usbser.sys, подправить inf всюду где встречается его название и скормить его через update drivers. На моей системе (WinXPSP2) - этот вариант прошёл без проблем, но на некоторых системах (и SP2, и SP3) Windows не хочет производить замену выдавая при установке "нового" переименованного драйвера - "The name is already in use as either a service name or a service display name". Есть ли какие-то другие решения проблемы? Спасибо

Ну и темку же я поднял :) Поделюсь результатами которые я успел получить. Разбирался, немного, с IwIP по примеру из FreeRTOS, тут пока, что грустно - стек хочет больше килобайт на 10-15 чем в примере с uIP, а я могу максимум 2кБ выделить. Сильно глубоко в дебри стека я пока не забрался, так что возможно в будущем что-то и выплывет. Зато в моём коде начал играться с компиляцией отдельных файлов в ARM или Thumb. Так вот, когда-то я поставил весь стек (uIP) в ARM, а теперь, когда изменил на Thumb, у меня скорость передачи моих данных по сети возросла на треть. Ещё сегодня попробую забрать копирование с буферов EMAC в буфер стека, а поставлю просто обмен указателями, тоже что-то подростёт, а дальше буду пробовать в стеке выбрасывать лишние вещи. На счёт обмена указателями, я думаю сделать так: как только пришёл пакет в EMAC буфера, все их пометить как использованые, поменять местами указатели и тогда обрабатывать данные, что-бы не нужно было делать менеджер памяти с переходом между отдельными 128 байтными кусками. Посмотрим, что выйдет В данном проекте изменить процесор уже нельзя, да и без оси писать будет тяжело - много дополнительных задач, которые работают паралельно

Насколько я смог разобраться когда-то и вспомнить сейчас, во FreeRTOS, работа с очередями организована через усыпление всех активных задач, что, соответственно, сказывалось на быстродействии системы. Поэтому пришлось переделывать. Сейчас посмотрю что изменилось в новой версии операционки и как это всё сделано в интересующем меня примере.

Понятно, тогда вопрос со стороны lwIP - можно ли использовать для моей задачи пример использования стека из FreeRTOS? Первоначальное знакомство с примером показало, что в нём используются очереди, а в предыдущей версии ОС, когда я разбирался с обменом данными по USB, используя пример из FreeRTOS, то как раз очереди очень сильно тормозили обмен. И только когда я заменил их на обычные масивы - тогда смог выйти на расчётные скорости обмена данными.

Писать свой менеджер памяти, пока для меня будет сложно, поэтому разбираюсь с lwIP. Правда ещё попробую копировать по 4 байта. А пока такой вопрос - прошивка у меня компилируется в Thumb виде, согласно документации - использование ARM команд повышает быстродействие по сравнению с Thumb режимом. Пока что, при компиляции в ARM у меня система перестаёт работать - запускается нормально, но при попытке объявить (или запустить, ещё не разобрался) какую-либо задачу (использую FreeRTOS) - виснет. Соответсвенно вопрос - стоит ли этим баловаться (в смысле компиляцией в ARM) и в чём может быть проблема, что у меня подвисает система (может я не учёл что-либо общеизвестное)?

думаю раза в 2 подойдёт (5-6Мбит/с). Попробую выбросить копирование данных и сделаю всё на обмене указателями, а дальше будет видно по результатам

Очень хороша идея. Главное, что сам похожие вещи делал, при чём в этом же проекте, а тут использовать не догадался. Попробую :)

TCP У меня там и моргание, и паралельные задачи, и обработка прерываний по таймеру где-то под 30кГц