Keil Ulink2 AT91SAM7S64
Всё работало, и вдруг стал выдавать ошибку при попытке прошить контроллер .

AT91SAM7_64.FLX
Cannot Load flash programming algorithm

Эта ошибка и раньше иногда возникала , но проблема решалась созданием нового проекта.
А сейчас установил новый KEIL (последний с keil.com) , новый проэкт, и всё равно не хочет работать .

Подскажите что-нибудь .

Спасибо !

Или при попытке загрузить в контроллер некоторые примеры кейла возникает похожая ошибка flash dawnload failed - ARM7TDMI

Внизу список ошибок
Contents missmatch at: 00100000H (Flash=ACH Required=18H) !
Contents missmatch at: 00100001H (Flash=10H Required=F0H) !
Contents missmatch at: 00100004H (Flash=20H Required=18H) !
Contents missmatch at: 00100005H (Flash=10H Required=F0H) !
Contents missmatch at: 00100006H (Flash=80H Required=9FH) !
........

Причём эта проблема только в проектах где есть прототип функций типа
extern void USB_EndPoint15 (DWORD event);

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

Я недавно сталкивался с подобной проблемой, но эмулятор у меня МТ-Линк и контроллер STM32.

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

Причём это не зависело от того, использовался ли алгоритм записи от кейла или от сеггера. Если они вообще чем то отличаются.
Помогло выставление в настройках эмулятора сброса с использованием сигнала RESET (для сброса не только ядра, но и всей периферии).

По вашим же словам алгоритм записи не может быть даже загружен в оперативку контроллера, то есть ошибка происходит на более раннем этапе...

Заметил что проблема возникает если старые проэкты компилировать в более новом кейле. Надо создавать новый проэкт.
И ещё при подключении ULINK к более новой версии кейла кейл стал прошивать ULINK

Cannot Load flash programming algorithm
Была аналогичная проблема. Решилась понижением частоты работы JTAG до 500КГц.
В настройках проекта в закладке "Debug" -> (ULINK ARM Debuger) кнопка "Settings" -> Max JTAG Clock

Ещё в некоторых (STR91 в частности) МК нужно после сброса не сразу включать PLL, а немного (десятки-сотни мсек) подождать. Об этом в errata упоминается. Наступал на такие грабли.

You can load the specified programming algorithm for AT91SAM7S64 by manual.

bigarmer прав, а если по русски то:
а так не пробовали?
Project->Options for target .... далее в появившемся окне
на вкладке Utilites
*Use Target Driver for Flash Programming = ULINK ARM Debugger
рядом кнопка Settings и в новом окне кнопка Add и выбираете свой проц

аналогичная проблема и ошибки
пытаюсь прошить STM32F103C6
в нем 32к байта памяти. для такого количества памяти нет метода прошивки. перепробовал разные варианты не помогло.
в чем еще может быть проблема ?
код тестировал и прошивал на STM32-P103. настройки проекта сделаны под STM32F103C6.
использую J-link