при неизменной собственно прошиваемой программе для MSP430F123.
После Unknown exception in driver (#M1) пишет Session aborted! Затем пишет
A fatal error has occured. The debugger will terminate. И выгружает соответственно debugger (использую адаптер MSP-FETP430IF1.3 от параллельного порта IBM).

Далее можно любое число раз повторно пытаться загрузить программу в MSP430F123 безуспешно. Помогало волшебство: существенное уменьшение большого массива, загрузка (успешная), снова выгрузка, вернуть размер массива и снова загрузить!
Затем все могло успешно загружаться, пока не добавишь или убавишь строчку "С". Постепенно и это перестало помогать.

Помогите, пожалуйста, новичку. В чем здесь может быть дело?

Как запитан TARGET? Версия компилятора?

2.97 V от NJM78L03UA (3-х вольтовый "КРЕН") питаю MSP (резистор питания через адаптер от порта компьютера убран с платки MSP),

IAR C/C++ Compiler for MSP430
V3.40A/W32 [Kickstart] (3.40.1.3)

Т.е. запитываете свое устройство от внешних 3В, так? 3В от питания MSP430 на 4pin коннектора JTAG подаете?

Да, от внешних 3В.
А на 4 pin JTAG резистор разомкнут. Какой туда номинал нужен?

На 4 pin JTAG замкнул питание 3В от MSP430. Результат тот же: не хочет работать...

Попробуйте программу Kurt-а MSPFET Programmer. Если будет работать нормально, то проблема в компиляторе. Если также глючить, то проблема в подключении или в железе. Только не забудьте нужный для MSPFET Prorgammer формат выходного файла в компиляторе задать.

Спасибо! Однако, странно казалось бы грешить на компилятор: ведь с помощью уговоров иногда загружается именно желаемая версия прошивки, которая до этого многократно отметалась сообщением об ошибке в драйвере (#M1), о котором в Help IAR ничего не сказано.

"Спасибо" означает что с MSPFET Programmer работает нормально?
Про ошибку драйвера ничего сказать не могу, т.к. до сих пор пользуюсь версией 3.30А по причине глюков оптимизации, обнаруженных в 3.40A. А в 3.30A с подобной ошибкой я не сталкивался.

Спасибо говорю за конкретный совет и Ваше затраченное на меня время.
Оптимизация, кстати, у меня пока выключена полностью.
MSPFET Programmer же скачал, но еще не ставил: программист я пока еще только 5 минут, поэтому задача управиться с новым программером может статься для меня не простая.
Пока обнаружил log, из которого следует, что во всех случаях IAR все исправно загружает и верифицирует, ошибка же в драйвере возникает после Target Reset (даже когда "Run to Main" отключен).

У меня подобная беда была на 122-ом он даже на версии 3.21A,
то есть очень неустойчего себя ведет, постоянно зависал при прошивке или неудачной установкой бряков. Хотя нормально себя вел другой проц 1611-ый. У них на сайте даже была какая еррата
http://supp.iar.com/Support/?note=72785&from=search+result
что помогло незнаю я уже и файлы менял там всякие HEL.dll и т.п короче тынцы с бубенцами. Щас работает более менее.

Да, спасибо. Я вот пока тоже нашел не слишком длинный танец, которым пока и пользуюсь: два раза меняю размер char массива в меньшую сторону по два байта, каждый раз безуспешно (обязательно) загружая, на третье изменение к исходному загрузка проходит нормально. И в дальнейшем нормально грузится, пока не сделаю какое-нибудь изменение в программе. Тогда приходится повторить тот же танец... Кстати, началось все, кажется, с некоторого количества расставленных, как цветные метки, бряков деактивированных!

Дык может у вас в MSP430 банально ОЗУ не хватает? Ведь в кристалле только два (или три?) аппаратных breakpoint-а, причем один из них сам C-Cpy использует. Все остальные бряки программные!

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

Что-то в компилятор MspFet.exe из MspFet_16007_devel.zip (скачаный по данной Rezident-ом ссылке Kurt-а MSPFET Programmer) не удается мне загрузить программу "C". Отвечает: "Load failed. Error: Invalid format".
Чтобы загрузить, я программу ".c" переименовал в ".txt".
Вообще, подозреваю, что никакой компилятор не возьмет программу ".c", написанную для компиллятора IAR?

Во первых, MspFet.exe - это не компилятор!
И загружать надо не файл "*.с", переименованый во что-либо, а результат работы компилятора, например ИАРовского.
Он у Вас находится в папке "Ваш проект\Release\Exe\", ну или
"..\Debug\Exe\".
Формат выходного файла компилятора устанавливается в опциях проекта. Выбираете или "Intel Hex" или "Техас тхт". Любой из этих форматов MspFet понимает.

Спички, лично я - легко зажигаю. А вот после выполнения Ваших рекомендаций MspFet.exe заявил, что не хватает ему msp430.dll, причем подсунутую из IAR таковую (в папку с MspFet.exe) отбивает словами нехорошими: "Точка входа в процедуру HIL_sbw_StepPSA не найдена в библиотеке DLL HIL.dll". И после нажатия "OK" на этом сообщении заявляет, что и вовсе опять-таки "Init failed. msp430.dll not found." (Кстати, теперь и просто при запуске MspFet.exe сразу же заявляет насчет "Точка входа в процедуру..."
Что касается собственно вроде бы выполенных мною рекомендаций, то это на вкладке LInker - Output я выбрал Format - Other - Output format - Intel-standart. Собственно расширение результирующего файла получилось ".a43". В этом пункте я правильно исполнил рекомендованное Вами?

Правильно.

Рабочие dll (с которыми у меня лично MSPFET работает) в аттаче.

a можно в свойствах MSPFET включить "FET direct access" - тогда длл-ки будут не нужны.

Для того чтобы программа MspFet работала через msp430.dll в папку с mspfet.exe надо скопировать файлы msp430.dll и hil.dll. И как прально уже заметили. если использовать режим RAW, эти файлы и вовсе не нужны.

Насчет компилятора С - это сильно

Загружает MspFet без сбоев! Пишет:
15:50:11 Initialize...
15:50:12 Device: MSP430F12x. Info(0x1000-0x10FF), Main:(0xE000-0xFFFF)
15:50:12 Programming the device memory...
15:50:15 Program complete.

Однако, отладчика С-SPY у меня при этом естественно нет, а он мне так нравится!
На вкладке Linker IAR для Debug information for C-SPY я указал Allow С-SPY-specific extra output file, да что толку.

Зато попутно я обнаружил, что сам IAR в режиме с отключенной Debug information for C-SPY прекрасно грузит без сбоев!

` С поддержкой же C-SPY - стабилизировался у меня танец с IAR где-то до 3-ей - 4-ой попытки (обязательно перекомпиллируя и перелинкуя каждый раз). Теперь же, после игр, совсем IAR просел, вовсе не грузит, видимо после перерыва восстановится, так-то его и так!

да сильно а почему бы и нет если сильно хочется то можно

FET direct access конечно KrutO но у меня при Read 1611 прожог fuse почему то хотя я туда не тыкал я один такой вЯзучий

Через LPT-порт Вы физически не сможете прожечь фуз (кроме адаптера fusee)

Нет, не один. Однако MSPFET Programmer тут ни при чем!
http://electronix.ru/forum/index.php?s=&sh...indpost&p=45812

Однако, обнаружилась "галочка", ликвидирующая вышеописанные дурацкие сбои при загрузке отладчика IAR: в Options for node в категории Fet Debugger надо поставить галочку Disable memory cache !
. А другая довольно-таки похожая программа по составу и объему при всех тех же свойствах Options for node исправно всегда без сбоев загружала и загружает отладчик и без Disable memory cache.
. Если кто может прокоментировать этот эффект, было бы любопытно услышать.