Постараюсь по мере возможностей. Сначала сделаю отступление: эти функции я в своей работе пока не использую, поскольку в части проектов у меня загрузчик написан на асме а в части я использую AES Loader из аппликашки Атмела. С этими функциями я баловался еще в версии 2.28 (сейчас нашел тот исходник, там судя по исходнику их прототипы были описаны в pgmspace.h. Вот тот исходник:

Сообщение отредактировал Сергей Борщ - Jul 13 2006, 08:21

Спасибо. Просто я не понял как ими воспользоваться. Т.е. какие функции вызывать с какими параметрами. попробую еще в help поискать на IAR

Люди, подскажите - есть ли в IAR функции для самопрограмирования? Очистить буфер, занести слово в буфер, записать буфер, биты защиты выстывить....

Вот выдержка из проекта AVR109 - Self-programming с сайта Atmel:

Как видите, всё есть.

ой мама... "На колу мочало...". В intrinsics.h есть макросы
>Очистить буфер, занести слово в буфер,
_SPM_FILLTEMP(Addr,Data)
> записать буфер,
_SPM_PAGEWRITE(Addr)
>биты защиты выстывить
_SPM_LOCKBITS(Data)

Там же полезные
_SPM_ERASE(Addr)
_SPM_GET_LOCKBITS()
_SPM_GET_FUSEBITS()
Они вызывают "в IAR функции для самопрограмирования":
Или я опять вопроса не понял?

или я чего туплю или как....
не понимаю как ими воспользоваться.
__AddrToZByteToSPMCR_SPM((void __flash*)(Addr), 0x03)
сдесь понятно: номер страници и вперед
А я ковырялся с
/* SPM */

/*
__DataToR0ByteToSPMCR_SPM, pseudo code.
MOV R0,data
OUT SPMCR,byte
SPM
*/
__intrinsic void __DataToR0ByteToSPMCR_SPM(unsigned char data,
unsigned char byte);

и не всегда мог понять для чего они.
Получается надо смотреть, то что начинается с #define:

_SPM_LOCKBITS(Data) // где data 1 байт. установить биты защиты
_SPM_ERASE(Addr) // Addr 2 Байта 11-5 биты. стереть страницу
_SPM_FILLTEMP(Addr,Word) //Addr 2 Байта (4-0 биты), word 2 Байта. слово в буфер
_SPM_PAGEWRITE(Addr) //Addr 2 Байта 11-5 биты. запись страници
unsigned char t = _SPM_GET_LOCKBITS() //чтение байта защиты
unsigned char t =_SPM_GET_FUSEBITS() // чтение байта конфигурации

А вот что за эти команды:
#define _SPM_24_ERASE(Addr) и т.д. с цифрой 24?
Нехватает команды очиски буфера и макроса ожидания выпоkytybz операции.
Ладно, носом ткнули, буду еще смотреть аплек109. Спасибо

Бывае говоришь о чем то со спецом, все он говорить правильно, кратко, по существу, а потом вдруг понимаешь, - а здесь он погнал....
Причины по выше сказаному бывают разные: невнимательность например.
Посмотрел я внимательно аплекуху 910 и узрел:
1. В flash.h * Compiler : IAR C 3.10C Kickstart. И нетребо было 4.12 ставить.
2. В main #include "flash.h".
Библиотеку flash.h найти в папках IAR не удалось. Буду разбираться как появившимися в моем распоряжении функциями пользоваться.
Спасибо за помощь - самостоятельно я бы больше времени потратил. Если что ещё поспрашаю. Уж какие нибудь нюансы да появяться.

а... Я-то думал вы сначала даташит про bootloader прочитали...
Setting the Boot Loader Lock Bits by SPM To set the Boot Loader Lock Bits, write the desired data to R0, write “X0001001” to SPMCR and execute SPM within four clock cycles after writing SPMCR.
Интересно, что же может делать функция с загадочным названием __DataToR0ByteToSPMCR_SPM?
Не пользовался, но могу предположить что для процессоров с более 64К памяти, т.е. с адресом в 24 бита?
Ну нет в функциях команды SPM очистки буфера The temporary buffer will auto-erase after a page write operation or by writing the RWWSRE bit in SPMCR. А макрос может выглядеть так: while(SPMCR & (1<<SPMEN));



Согласно правилам языка высокого уровня С если имя файла в директиве #include указано в двойных кавычках то компилятор ищет его в текущей директории, т.е. в папке проекта. Если же в угловых - то в папках указанных компилятору в опциях как include path. Поэтому flash.h искать в папках IAR не имело смысла - он должен быть в исходниках от "аплекухи 910".

Это я знаю. Но до меня не доходило такое
#define _GET_LOCK_BITS() __AddrToZByteToSPMCR_LPM( (void __flash *) 0x0001, 0x09 )
т.е. функции самопрограмирования в IAR есть, но для удобства их использования делаются присвоение и вызов с параметрами. А я в хелпе IAR искал и не мог найти таких команд.
Эх Си- 280 строчек- 914 Байт. Лень на асеме писать

Новая проблема: пытаюсь сгенерить hex а IAR ругается
Fatal Error[e72]: Segment TINY_Z must be defined in a segment definition option (-Z, -b or -P)
В дебагере все легло ровно, а здесь проблемы. В какой должен быть выходной формат или в экстра опциях линкера прописать чего надо?

Видимо в настройках проекта стоит настройка memory model: Tiny а файл .xcl взят с "s" на конце, т.е. для модели памяти Small. Измените настройку на Small и все должно заработать. Кстати, интересно как "В дебагере все легло ровно", ведь файл для дебаггера тоже генерит линкер и с теми же самыми параметрами... Или это после переключения target с debug на release? Тогда понятно - надо сравнить модель памяти и выбранный .xcl в обоих targets.

Сообщение отредактировал Сергей Борщ - Jul 17 2006, 10:27

Рекомендую посмотреть на мой проект Crypto-Boot (только как reference, а не образец для подражания - см. его README) на сайте разработчика USB драйвера для AVR. Возможно, часть вопросов снимется.

Там реализован USB boot loader для меги32, использующий программную реализацию USB. Загрузчик позволяет, в частности, перешивать код приложения по тому же USB интерфейсу, что и само приложение может использовать.

Загрузчик использует перемещение вектора прерывания в область бута для работы бута независимо от приложения (вопросы BOOTRST, и управления переключением вектора).

Загрузчик поддерживает работу с серийными номерами и версиями бута и приложения, в т.ч. чтение последних бутом из области приложения для передачи утилите на PC. Очевидно, такой же подход можно использовать и в обратном направлении - используя вызовы каких-то функций, размещенных в области загрузчика, из области приложения. Я бы для такой цели (если иного варианта не видится) использовал таблицу переходов типа rjmp на начало нужных функций в буте, размещенную по фиксированному адресу в области бута. Тогда на них можно будет ссылаться из независимо собранного приложения, прописав только их адреса (которые фиксированы и известны независимо от сборки бута. Как прописать - см. там же, как вызывается приложение по адресу 0 из бута. Тут будет обратная картина.

Я бы не совмещал вектора прерываний в буте и использующее их приложение в области application, так как возможности менять таблицу векторов бута нет, а меняя IVSEL, мы автоматом теряем возможность работы функций обработки прерываний в области бута (если не продублируем вектора во второй таблице). В общем, при таком подходе проблем будет намного больше, чем при раздельной сборке того и другого. Но если очень прижмет - то можно попробовать.

Проект, как там написано, без комментариев, только как reference (хотя у меня работает). На конкретный вопрос ответить смогу. На вопрос "как все это собрать, чтобы заработало" - нет. Проект искать тут, называется Crypto-Boot (с парапланом в качестве иллюстрации). Собирался под IAR 4.12.

Нашел разницу в дебугере и релайсе: general options / system configurations снял галку и все пошло. Модель памяти оставил tiny.
файл .xcl взят с "s" на конце. Попробую запустить.
Спасибо. Пример посмотрю.

Зачем такая несовместимость?
Установите модель памяти small. Если работает с моделью tiny, это не значит, что это правильно.

Лучше конечносделать как надо, но для small 1040 байт, а tiny 970. Где то может и сыграть размер кода.