LPC2478 на плате от стартеркита http://www.starterkit.ru/html/index.php?na...p=view&id=5
Пытаюсь прошить hex. Для LPC17xx использовал lps21isp, но не заработало тут.
Flash Magic тоже не работает. Если не указывать тактовую частоту (для LPC17 никогда этого не делал в нём), то выдаётся ошибка:

Если нажать "да", то потупит ещё немного и снова вывалится с ошибкой.
Если указать частоту (14.748 МГц), то получаю:

Тип проца естественно выбран верный. Скорость пробовал разную указывать - никаких изменений.

Если придавить P[2]10 на землю, подать питание и отправить через терминал запрос автосинхронизации ('?'), то в ответ получаю как положено Syncronized на любых скоростях. Дальше команды ISP не проверял (и судя по беглому взгляду в даташиты они не отличаются от LPC17). А Flash Magic ни на какой скорости не работает. Одинаково не работает если вручную перевести проц в ISP перед попыткой прошивки, ни автоматически по RTS/DTR. С LPC17xx таких проблем никогда не было.
Подскажите в чём может быть проблема?

А каая температура ?!

4.1 IRC.1: Accuracy of the Internal RC oscillator (IRC) frequency may be
outside of the 4 MHz +/ 1 % specification only at extreme
temperatures

Introduction:
The device has a 4 MHz internal RC oscillator (IRC) which can be optionally used as the
clock source for the Watch Dog Timer (WDT), and/or as the clock that drives the PLL and
subsequently the CPU. The IRC frequency spec is 4 MHz +/ 1 % accuracy over the
entire voltage and temperature range. During In-System Programming (ISP), the
auto-baud routine is expecting the IRC frequency to be 4 MHz +/ 1 % and is used to
synchronize with the host via serial port 0.

Problem:
On the LPC2478 Rev D device (only with date codes 0949 and before), the accuracy of
internal RC oscillator (IRC) frequency does not meet the 4 MHz +/ 1 % specification for
temperatures between 20 C and 40 C and the accuracy of internal RC oscillator (IRC)
frequency is 4 MHz +/ 5 % instead. As a result, only at these temperatures, this may
affect the auto-baud routine's ability to synchronize with the host via serial port 0 during
In-System Programming (ISP) at higher baud rates. For temperatures above 20 C, the
accuracy of internal RC oscillator (IRC) frequency meets the 4 MHz +/ 1 % specification.

Work-around:
None

ERRATA

Прикольно
Температура 24 гр.Ц. Попробовал слегка подогреть феном - без изменений.

зашейте через JTAG софтину. которая выводит наружу IRC на CLKOUT и померяйте частотомером. Чисто ради эксперимента.

Да какая разница, если при посылке тех же байтов через терминал все синхронизируется?

Остается только посоветовать соединить выход COM-порта с каким-нибудь другим портом и терминалкой проверить - а в этот ли порт посылает FlashMagic и еще посмотреть - не мешает ли плате шевеление FlashMagic-ом сигналов DTR и RTS. Ну не бывает же чудес. В каком состоянии держит эти сигналы ваша терминалка и в каком они во время работы FlashMagic-а?

P.S. Конечно мы надеемся что на компе у вас винда а не линух, позволяющий повесить на один порт несколько программ и раздающий пришедшие байты всем им по очереди в случайном порядке. В последнем случае надо действительно убедиться, что никакая другая программа (забытая терминалка) не висит на этом порту.

Работаете через USB-COM?
Попробуйте найти железный RS232 (на материнках часто бывает внутри на штырьках не выведенным на заднюю панель).
Если нету - хотя-бы попробуйте найти другой USB-COM (другого типа).
У меня у самого несколько разных USB-COM (на разных чипах). С одними flashmagic работает, с другими - нет. С одним и тем-же устройством.
Так же (как вам уже советовали) проверьте как у вас используются DTR, RTS на плате? Не подцеплен-ли к ним сброс или P2.10?
Ещё иногда помогает изменение опции "High Speed Communications" в меню flashmagic-а.

Ещё бывает, что определённые CPU у NXP работают только на определённых скоростях - не выше и не ниже.
Например сейчас у нас такая проблема с LPC1778 - стабильно работает на 38400, некоторые экземпляры - на 57600. На других скоростях - никак.
Раньше похожая проблема была с LPC2378. Но в более поздних партиях что-то видно поправили и проблема пропала - стали работать все CPU на всех скоростях до 230400.
LPC1758, LPC1768 работают без проблем до 230400.

да вообще не будет работать выше 57600. ISP.1 Maximum UART ISP baud rate limited to 57,600

Линукс и винда дают одинаковые результаты. Под линуксом lpc21isp программка всегда работала с LPC17, а сейчас с LPC24 - нет. Винда на другом компе и там FlashMagic с теми же результатами. Перетыкаю кабель в плату с LPC17, меняю тип процессора и тут же всё начинает работать, т.е. не с компьютерами дело.
На обоих компах нормальный RS232, никаких USB-конверторов. Скорость разную пробовал от 2400 до 57600 (раньше всегда на 57600 работал). RTS/DTR перемычками можно отключить от ресета. Отключал мычками, подключал кабелем у которого физически только 3 провода распаяно, без RTS/DTR.
Хардварным снифером вижу что после ответа "Syncronized" начинается белиберда:



Прошить через JTAG не имею возможности по причине временного отсутствия рабочего отладчика. Отдельная история с невезением на китайские и NXP-шные отладчики. При большом желании для проверки можно достать на недельку, но нет гарантии что это поможет решить проблему.

Попробуйте подтянуть к высокому уровню выход Tx процессора. Сталкивался с подобным поведением как раз на каком-то из LPC. Он в паузах выключал передатчик и нога болталась в воздухе.

Не помогло

Хм. А что осциллограф показывает на ногах Tx, Rx?

Осциллограф красивые прямоугольные импульсы показывает. Не докопаться. Отдельно битики вручную не считал. Длительность бита 17.2 мкс что верно соответствует скорости 57600. Это МК так отвечает, т.е. вряд ли проблема с тактовым генератором или определением скорости.

Кстати заметил что если отправить вручную '?' без \r\n, то ответ "Synchronized" приходит верный. А если отправить "?\r\n", то скорость определится не правильно (в 2 раза меньше судя по ширине бита на осцциле). У LPC1788 без разницы - и так и так работает. Затем отправляю обратно ему "Synchronized" и в ответ получаю рандомную лабуду. Лабуда приходит на верной скорости если верить осциллографу и не зависит от наличия \r\n или выбранной скорости.

Хм... странно конечно...
Т.е. - после получения правильного "Synchronized" от CPU, переключиться на в 2 раза меньшую скорость и продолжить на ней?
Под терминалкой.
У вас одна плата? Может проблема в данном конкретном экземпляре? Например - выводы TX, RX как-то хитро подгорели. Или по какой-то причине проц периодически пересбрасывается (проблема с питанием)?

Не, скорость верная остаётся если не добавлять \r\n к запросу '?' (вообще-то после ? и не должно быть новых строк, это просто случайно забыл отключить в терминале), только вот на этой скорости единственный раз верно приходит Synchronized, а всё что после него коверкается, т.е. проц отвечает какой-то лабудой на верной скорости.
Другого экземпляра нет. Написал в стартеркит чтобы у себя проверили.

в соседней ветке
http://electronix.ru/forum/index.php?showtopic=115861

кратко автору попалась серия процов для внутреннего использования NXP с измененной процедурой программирования, он ее купил официально у поставщика. Может у вашей проблемы оттуда же ноги растут?