Так Вы когда добавляли lpc17xx к своей проге. просто забыли про это?
И сделали Go в конце загрузки? А когда просвещали меня о том, что инициализация sp в стартаре делается, вспомнили, что не делается и
внесли изменегия в свою прогу?
Вона она оказывается как!




Так Ваша версия какова?
Инициализация sp делается аппаратно - то есть добавлена соответствующая логика в железо, или все же делается программно?
То есть, путем перехода на кусок кода во флеше, в котором эта инициализация прописана?


В общем, с запуском чипа после ресета более меннее ясно.
Ответ таков - смотри исходники кривого "бангалорского" бутлоадера.
Он, в отличии от родного ( из РОМ ) прогу со стартапом в ОЗУ запускает правильно.

Следующий вопрос - озаботился я тут SPI.
Нужна простая штука - мастер посылает в слайв байт-команду. Их всего два типа - записать в регистр по указанному адресу и считать из
регистра по указанному адресу.
В первом случае через один такт ожидания мастер посылает байт-значение регистра.
Во втором случае через один такт ожидания мастер читает или байт-значение или 16бит-значение.
Оказывается, такой вариант SPI в кортексе не реализован.
Зато реализованы 5 других вариантов, среди которых есть похожий на вышеописанный, но первый вариант он исполнять не умеет,
умеет только чтение из слейва.
Или я чего то там не понял или где?

Это штатное поведение AT200 с самого рождения.

Ответ - прочитайте наконец ответы. Два действия загрузчика по запуску загруженного им образа называл. Все.

У SPI по жизни 4 варианта (не считая вариантов с количеством передаваемых бит и порядком их следования ), а не шесть. Все поддерживаются в
периферии от NXP.

Ну да, а вчера чё прыгали то отменяя штатное поведение то снова его возвращая?
Просто скучно было?




В моей проге второе слово во флеше указывает на ОЗУ, в котором после включения питания - мусор.
Что то перед тем, как туда прыгать, должно переписать из флеша в ОЗУ данные и код.
Кривой бангладерский бутлоадер это делает - прога работает, прямой ( из ПЗУ чипа ) вроде нет - прога не работает.




Тот вариант, что я описал, не по жизни?
Но он реализован в датчике давления SCP1000.
Им зачем то понадобилось не только, чтобы данные из датчика считывались, но чтобы и датчик можно было
программировать ( записывать вего регистры ).

Может и тут описание lcp17xx кривое?

Из описанных режимов частично подходит только микроканал, но для чтения из датчика.
А запись в датчик - увы...
Пропуск между последовательными записями - минимум 5 тактов.

Если не поняли, что вчера было сделано, то это меня уже не удивляет. Штатное не отменялось. Было, есть и будет.

В том и беда Ваша, что это Вы его описали. Описали кашу в своей голове и теперь собираетесь ее размазывать по форуму. Посмотрел. В документации все описано просто и понятно. На самом деле там, как и обещано, чистый как слеза SPI общающийся кратными 8битам (16/24)посылками. Нималейших проблем и непоняток c работой с ним быть не может.

Значит надо переквалифицироваться в управдомы. И побыстрее.

Не уточните, сколько там тактов после выдачи команды на запись байта в регистр и началом выдачи этого байта?
И сколько тактов минимум получается в микроканальном режиме SPI у lpc176x...
Может попробуем разобраться на конкретном примере, у кого именно в голове каша?
Или Вы только воообщем, из высоких соображений могёте...




Кому? Келу или NXP?
Компилер первого эту прогу слинковал с нулем замечаний,
Родной бутлоадер второго ее не запускает.
А вот кривой "бонгалорский", которого зачем то NXP в свои апноуты поместил - запускает.
Вы настолько эту штуку имеете длинной, что знаете, кому из них в управдомы?
Мне замечание на другом форуме сделали - мол на электрониксе ты осмелился челу с очень длинной этой самой штукой
возразить. А низзя...

На следующий такт после передачи байта (в байте 8bit) содержащего 6bit_адрес+флаг_бит_записи+space_bit, начинает передаваться байт данных. Cюрприз!

Речь до сих пор шла SPI режиме. Тоже на следующий такт. Такое удивительнейшее совпадение.
Хотите верьте, хотите нет.

Вам в управдомы, хотя начинаю сомневаться потяните-ли . В какую книгу ни посмотрите, везде без исключений видите фигу .
В общем стало совсем глупо продолжать общаться . Дальше без меня. Только на очередные глупости извлеченные из Вашей головы буду указывать, дабы, как уже писал, не плодились.

Стерли?
Тоже метод в борьбе за длину этой самой.
Вы всю ветку сострите, ведь позор Ваш на ней присутствует...

Admin:
Никто Ваш словесный понос за Вами не подтирал. Ибо дурь каждого видна должна быть. Посему еще и корчить из себя жертву модерирования совсем глупо.
А вот продолжение засорения форума подобными постами безнаказанным не останется. И отнюдь не символически - не первый раз. Лимит хамства исчерпан Вами полностью.

Предыдущий пост куда то пропал. Да и ладно, все равно там у меня была ошибка.
Про SPI.
Нашел, где я ошибся. Сбила меня с толку то, что команда на датчик требуется с нулевым байтом в конце.
То есть, после посылки комманды и записью/чтением паузы в один такт нет. так что режим мкропровода не годится.
Запись в регистр и чтение байта из регистра можно сделать по обычному SPI, заявив фрейм в 16 бит.
А вот как читать из жатчика 16 битные регистры? Фрейма в 24 бита ведь нет.
Или я что то не догоняю, или придется все таки писать программного мастера SPI?
Про USB.
Я уже про это здесь постил, но интузиазма не вызвало, напишу подробнее.
Есть аппноута AN10866 от NXP - secondary USB bootloader.
Что она делает.
Если при сбросе заземлен пин P1.20 она выставляет чип в виде USB диска, отраженного на флешь чипа размером в 500 килобайт.
То есть PC_юк может открывать файлы, читать флешь через файл, писать через файл во флешь.
Если пин не заземлен, то запускается прога по адресу 0x2000 во флеше, USB диск отключается.

Чего хотелось бы. Чтобы после запуска проги USB диск не отключался а становился диском размером в 64 килобайта, отображенным
на ОЗУ чипа. И PC_юк мог открывать на нем файлы и читать-писать ОЗУ чипа.
Это позволило бы связать чип с PC по USB без установки драйверов, добавления дополнительных чипов на довольно большой скорости и
по удобному файловому интерфейсу.
Никто с такой штукой не сталкивался?
Это штуку я запощу и в других конфах.

Бит. Один бит. Ибо байт содержит 8bit.

Согласно таблицы умножения 24 = 8 * 3, как уже было отмечено в посте №54.

А соглано описания на датчик, если в средине передачи придет высокое на выборку кристалла - то начинай все сначала.
У кортекса на всех картинках по краям фреймов выборка высокая.
Извините, не удержался. Больше не буду.

Или нет. Как сделаете. Вариантов сделать целых два. Один годится для любого количества фреймов, другой для количества не превышающих размер FIFO. Дальше самостоятельно.

Переключите сигнал CS в режим софтового управления, и дёргайте его так, как необходимо.

Вы совсем новичок в контроллерах?
Такие элементарные вещи спрашиваете...

Вы наверно вопрос не поняли.
Я не справшивал, как SPI программно сделать.
Я спрашивал - можно ли задействовать аппаратный SPI.
Если мне программно дергать выборкой кристалла, то и сдвиг битов тогда проще задействовать програмный.

Как и обещал, сообщаю - очередная дежурная глупость.
SPI, как был, так и остается аппаратным и при "софтовом управлении" CS. В этом смысле управление CS ничем не не софтовей той-же записи в регистр данных. Кроме того, лично я поминал ДВА способа.

Это Вы про slave режим контроллера?
Вроде на картинках нет мастера при котором выборка вначале выдачи выставляется а при опустошении очереди - снимается.
Там все режимы - во первых с пропуском между фреймами во вторых со снятией выборки между фреймами.
Или у нас разные описания?

Master. Описания одинаковые. Способность к пониманию написанного разная . Если чего не понятно, и мучают сомнения, то можно проделать небольшую лабораторную работу - очень помогает разобраться в нюансах поведения в конкретных условиях.

vallav, вам объясняют про использование аппаратного SPI и программного управления сигналом CS. Ну не программируйте вы пин SSELx, соответствующий сигналу CS на альтернативную функцию от SPI! Оставьте его как пин, выполняющий функцию GPIO, программно сбрасывайте перед началом фрейма и устанавливайте по окончании передачи фрейма по SPI. SCKx, MISOx, MOSIx используйте аппаратные, SSELx аппаратный не используйте, ферштейн?

Да в курсе я - что именно мне объясняют.
Меня интеоесовало - аппаратно, на собственных пуговицах без программных помочей SPI штаны от lpc17xx на данном датчике
носятся?
Ответ, как я понял такой - нет, не носятся.
И только после этого следующий вопрос - а какие именно программные помочи нужны?
Мне же почему то на первый впрос отвечают мысленно, мысленно же слышат от меня второй вопрос и начинают сразу отвечать
на него.
Я второго вопроса не задавал!
Я на него ответ знаю. Вернее, почти знаю.
Так как в железе еще не проверял.

Но мне интересней другое - почему никому не интересен предложенный способ связи контроллера с компьютером по USB?
Такой вариант - ОЗУ контроллера как стандартный диск компьютера - когда в общую область ОЗУ контроллера компьютер пишет и читает
как в обычный диск а контроллер пишет и читает как обычное ОЗУ - чем то не удобна или давно реализована и широко используется?
Но тогда зачем повсеместно применяется это уродство - эмуляция UARTа?
Это примерно то же самое, что использование JTAGа для заливки во флешь - неудобно, но работает...

Ответ, как всегда, не воспринят. Третий раз уже , да именно SSP в LPC может.
Хотя стандарный вариант для любых SPI контроллеров это именно софтовая отметка фрейма. Сюрприз для ламеров!. Режим работы с фреймом произвольного размера очень очень распространен - любое более-менее сложное или быстрое Slave устройство на SPI или поддерживает, или прямо требует такой режим работы. В этом случае отмашка SSEL совершенно естественно отмечает начало фрейма произвольного размера. Аппаратная байтовая махалка, не более, чем полезный, но один из многих, режимов работы. Лично я в своих периферийных SPI устройствах предпочитаю использовать вариант, когда SSEL может быть снят в любой момент во время передачи полного фрейма, ибо за начало фрейма принимается переход SSEL в Lo. Если протокол не содержит размер фрейма, то тогда снятие SSEL разрешается производить и в любой момент передачи последнего байта.

Утомили своей детской радостью дежурного "первооткрывателя". Ответ простой - потому, что он дебильный.

Давайте, после того, как наконец-то нашли кнопку в IDE скомпилировать некий проект, заканчивайте писать кипятком от радости, даже не поднимая RAM диск попробуете пообщаться с компьютером через имеющийся Flash диск. Узнаете еще много интересного о том, как строятся файловые системы, оптимизация обращений и кэширования. Чем и насколько серьезно отличается поддержка системами, например, сетевых дисков от поддержки флешек-свистков.

Вы вроде собирались только мои ошибочные заявления отмечать?
Или все же поучить сильно тянет?

Похоже с реализацией USB RAM диска и общения через него придется самому заниматься.
Непопулярный это вариант оказался...
По каким то причинам туда и назад по UART считается более удобным, быстрым и надежным...

Вы видимо не очень хорошо знакомы со спецификацией USB и со спецификой работы ОС с USB-устройствами класса MassStorage.

Ага. Не очень хорошо знаком.
Вот поэтому и спрашиваю.
То. как работает код из аппноты - очень понравилось.
В чем Вы видите подводные камни, в случае, если в файлы будет отображаться не флешь а
ОЗУ контроллера?
Контроллер будет писать/читать в ОЗУ напрямую, комп писать/читать туда через файлы.
Преимущества - приличная скорость, простота подключения, отсутствие специальных драйверов.
Недостаток - израсходуется аж челых 8 килобайт флеши из имеющихся 512.
Других недостатков пока не вижу.
Хотя бы пару конкретных примеров реальных заморчек, если не трудно.
Ответы общего плана, типа - ты ламер, у тебя уши холодные, я супер а ты хто - не интересны...
Варианты - а если контроллер или комп не то и не туда запишут - тоже...

Кстати, не могли бы присвести для справки - сколько времени пишется и читается файл в 400 килобайт в флешь контроллера
через столь любимый здесь JTAG?
У меня получилось - читается около секунды, пишется около 5 секунд.

Пытаюсь разобраться, почему родной бутлоадер не запускает прогу, у которой startup слинкован в ОЗУ ( второе слово в флеше указывает
на ОЗУ ) а бутлоадер из аппноты запускает.
Пока докопался до такого - это происходит похоже из за ошибки в бутлоадере из аппноты.
Там вместо *((int *)0x2000+1) стоит 0x2000+1.
И вместо вызова подпрограммы по адресу, равному содержимому в ячейке флеша по адресу 0x2004 ( то есть, уход в неинициализированное
ОЗУ ) делается вызов подпрограммы
по адресу 0x2000. Процессор продирается через таблицу прерываний и попадает в код за таблицей, который и делает то, что нужно
для запуска.
Пользовательская прога грузится в флешь начиная с адреса 0x2000 и там - начало таблицы прерываний.
Дебагер в Кейле меня уже достал. Он такой из за того, что я его пока еще не крякал или он и по жизни такой?

Вообщем разобрался. На самом деле такая история, как в предыдущем посте описано.
Так что ответ на вопрос о начальной загрузке такой - не линкуйте startup в ОЗУ - нечего ему там делать. Только ОЗУ зря занимает.
Вдруг или бутлоадер будет без ошибки или в таблице прерываний попадется значение, которое или зациклит проц или выкинет его куда
подальше и до кодов иничиализации он не дойдет.

А загрузка происходит так - бутлоадер, сделав необходимые проверки ( заливалась ли флешь в первые 8 слов из правильного
заливщика, и несколько других, передает управление по значению во втором слове флеша. Этот код ( а начинается он сразу после окончания
таблицы прерываний ) делает нужные пересылки и инициализации ( например, загружает sp значением из первого слова флеша, пересылает
код и данные в ОЗУ ) и предает
управление на main - которая, кстати может быть слинкована в ОЗУ.

Очередной вопрос по USB. Кто нибудь проверял - какой диапазон отклонения тактовой от 48 мегагерц допустим?
Не по спецификации а в реалии? Интересует - можно ли не ставить внешний генератор а работать на IRC?

Если речь идет не о неком неведомом бутлоадере, а о штатном загрузчике LPC, то все происходит не так, ибо начинается с того, что имеется аппаратная поддержка ремапа 256 байт векторов бутового загрузчика. Как работают вторичные загрузчики типа рекламируемого USB, лучше разбирать по исходным текстам, даже если они "бангалорские".

В штатном конечно не так.
Штатный честно запускает пользовательскую прогу передавая управление по значению второго слова в флеше.
И, если стартап слинкован в ОЗУ ( против чего линкер Кейла не возражает ) прога естественно вешается.
Так как идет обращение к коду в ОЗУ, который появится только после того, как будет выполнен тот кусочек кода в ОЗУ, куда идет обращение.
Кривой бангалорский загрузчик эту проблему успешно разрешает, запуская программу по адресу начала таблицы прерываний.
( вопрос только в том, это случайность или сознательный ход ).

По частоте тактового генератора USB пока ответов нет, придется похоже самому проверять.
Но это будет не скоро.

Ну ладно, ответ на вопрос о тактовой частоте USB может быть малоизвестен, но почему нет ответов на вопрос о
времени записи/чтения файла в флешь контроллера через JTAG?
Ни у кого нет такого заливщика? Или цыфры стыдно обнародовать?

Еще вопрос.
Озаботился я тут дизассемблером кода Thumb-2.
Поиск привел:
1. К заявлению "крутых перцев" - мол код там очень простой и дизассемблер пишеься за пару часов.
2. К двум дизассемблерам ( ~1 Мбайт ), которые по описанию очень крутые но у меня работать с ними не получилось, не нашел, как в них
свой бинарник загрузить.
3. К супердизассемблеру ( ~30 Мбайт ) который после скачивания радосно сообщил, что работает только с электронным ключем.
4. Ну и небезизвестная IDA, плагин которой под именем HexRays умеет работать с Thumb-2 начиная с версий, датированных июнем 2010 года,
то есть выпущенных вчера. И стоит этот плагин всего навсего 1600 евро.

Вот такая вот веселая история.
Остается дизассемблер от Кейла, с которым пока не разобрался, как в него свой бинарник загрузить и заставить симулятор
шагать по этому бинарнику.
Порка получается только - в стартапе забить нужный код в область с абсолютным адресом ( в моем случае - 0x2000 ).
Забил 4 слова, посмотрел, работает. Но забивать таким образом 500 слов как то не вдохновляет.

Сильно сомневаюсь, что в LPC1000 зачем-то сильно ускорили запись во Flash и скрыли сей факт, но для LPC2000 времена записи во Flash нормировались и в режиме посектороного, т.е. неполного стирания только записть во Flash дожна занимать ~20*400ms + 400000/256*1ms что уже много больше намерянных "5 секунд". Сначала научитесь корректно делать оценки, а потом уже спрашивайте как там с JTAG, который, кстати, тоже работает очень на разных, в том числе и мегабитных скоростях.



Хотите маяться дурью вместо соблюдений рассчетных требований спецификаций - майтесь.

Дык просто все было.
В тотал-коммандере - стер исходный файл с USB-диска.
Нашел файл размером в 400 килобайт, выбрал копи на USB-диск, нажал - поехали - и засек, сколько времени ехали.
Получилось - 5 секунд.
Вы забыли привести цифры - сколько времени пишется и сколько стирается по JTAG.
Или просто не знаете?
А тогда вся эта Ваша философия "крутого перца с горячими ушами" - зачем?
Я знаю, что Вы - крутой перец, и что уши у Вас не холодные...





Так я же пояснил = зачем.
Если USB спокойно пашет при отклонении тактовой на +-10%, то в приборах, которые для себя - использовать IRC.
В приборах, которые для Вас - естественно все строго по спецификации...

Нет, просто опять не дооценил степень Вашей некометентности . Для тех, кто не способен к самостоятельному восприятию и анализу информации, сообщаю, что любой LPC загрузчик, в том числе и JTAG, использует открытый IAP интерфес штатного загрузчика для работы с Flash и в части записи-стирания все равны. Отличия имеют место быть в тактовой частоте контроллера, качестве самого загрузчика и размерах блоков которыми он оперирует, ну и только один из факторов, который при многомегабитных (12..25Mbit частоты интерфейсов JTAG/SWD у Cortex-ов ) скоростях передачи уже далеко не самый определяющий, это скорость интерфейса передачи этой самой информации загрузчику.
При 12Mhz тактовой данные по JTAG загружаются со скоростью 720Kbytes/s

Вот я и говорю - учитесь сначала корректно делать оценки.

Да... просто привести - у меня 400 Кбайтный файл заливается в контроллер по JTAG xx секунд, читается из контроллера yy секунд -
жаба душит?

Нет, просто характер не позволяет давать глупые ответы, даже на глупейше-пустейшие вопросы. Ну а нормальные развернутые ответы, Вы воспринимать хронически не способны. В общем мне так "общаться" окончательно надоело. Ответов больше не будет.

Понятно. Значит Вы - fabless, железа у Вас нет а все - только теоретически...
Бывает...
Неужели эту ветку не читает кто либо, у кого есть lpc1768 подключенная к JTAG_у?

Ну у меня есть. На работе лежит starterkit-овская плата SK-MLPC1768 и MT-Link. Только после перечитывания ветки особого желания делать что-либо специально для вас я не испытываю. Вдруг полученные циферки не подойдут к вашим убеждениям и я же еще и виноват останусь ИМХО документации от производителя нужно можно чаще всего верить. А если вы не умеете ее читать и понимать, то нужно учится этому. "Терпение и труд все перетрут"

Плагин нужен только для декомпиляции кода в C. Для простого дизассемблирования достаточно самой иды.

То есть, если по описанию одно а в натуре другое, то сомневаться в правильности описания - не стоит?
Вот пробовал в симуляторе Кейла - по ресет CPU он ставит sp - значение первого слова из флеша, ip - значение второго слова из флеша.
Меняю значение sp на большее. Запускаю, в main приходит с sp, близким к значению из флеша.
Так где на самом деле инициализируется стек? Аппаратно при сбросе? Или все же кодом инициализации?
Я исходно верю описанию. Но когда в железе получается по другому, я начинаю верить железу.

Или вот эта ахинея с проверкой наличия пользовательской программы.
Генератор пользовательских программ - Кейл - на эту проверку откровенно забил.
А вот изготовители заливщиков этим озаботились и тупо меняют 8 слово флеша независимо от того, что во флеш заливается.
Я вначале в это просто не поверил, думал - разигрывают...
Получается, если я заливаю работающую прогу от Кейла но не правильным заливщиком - она проверку не пройдет и не запустится.
Если я заливаю любую хню, но правильным заливщиком, она проверку пройдет и запустится.
А если я в Кейле слинковал прогу так, что у меня в флеше всего 4 вектора в таблице ( что необходимо для запуска ) а вся таблица слинкована в ОЗУ,
заливщик прогу испортит ( так как в 8 слове флеша - код загрузки ) и прога запустится и повесится.
Полагаете это - нормально?

Или с тактовой USB.
Почему то UART, у которого установки фазы клока по синхроимпульсу ( старту ) должно хватать на 10 тактов - от IRC работает, точности хватает.
А USB, у которой синхроимпульсы максимум через 5 тактов и есть преамбула для настройки тактового генератора ( а не просто установка
фазы клока ) точности IRC не хватает... Все равно - должен верить описанию - USB с IRC - низзя.
Кстати, FTDI - можно а вот мне все равно - низзя...

С цифрами по скорости заливки/чтения флеши через JTAG.
Я на самом деле не знаю, какие они.
Я знаю только, что заливать 32 Килобайта настолько долго, что выгоднее перегнать прогу в ОЗУ и ставить точки остановки там, чем ставить
их перезаливкой проги в флешь. Или это делается из экономии - чтобы не использовать ненароком отведенный лимит в 100 000 заливок...
Если стыдно их приводить - то зачем эта вся философия по поводу температуры моих ушей?






Как то не хочется ставить 100 мегабайтную прогу только для того, чтобы она делала простое дизассемблирование кода.
Да и встречал в инете, что IDA старых версий не все Thumb-2 кода берет.
Но когда дизассемблер Кейла меня достанет, придется ставить IDA.

Кстати, можно ли сделать так, чтобы при запуске симулятора он не пытался добраться до main а останавливался на первом шаге.
Если он до main не добрался а вылетел по дороге ( ну проги у меня такие ) то он как то странно работает.
Ресетишь CPU, ставищь IP на начало кода инициализации - код выполняется а IP остается неизменным.
Пришлось ставить по дороге ловушку, покрутившись в которой симулятор выподает в меню. И вот тогда по коду ходит.
И с загрузкой своего бинарника в дизассемблер. Неужели низзя?

32 килобайта заливаются за несколько секунд. Откуда бредни про "настолько долго"?


Загляните наконец в настройки проекта "Options for target..." и на вкладке Debug на стороне симулятора (левая половина) уберите галку с "Run to Main()".

Контрольные вопросы для Принца Флоризеля, который, как известно, знал все заранее и любое решение находил
несколько ранее собеседников:
1. Сколько указателей стека у LPC176x (Cortex-M3)?
2. Какой из них инициализируется аппаратно?
3. Есть-ли какие либо ограничения на софтовую инициализацию указателей стека?
4. Какие действия выполняются в startup до запуска main()?
5. Функция __main() в default startup KEIL это то-же самое, что и main()?
6. Сколько записей в таблице векторов Cortex-M3 жестко отведено под нужды ядра?
7. Какие утилиты входят в классический набор утилит binutils, каковы их аналоги в пакете от KEIL?
8. Что умеет делать утилита fromelf из комплекта поставки KEIL?

Ну и вообще начинающим будет на мой взгляд небесполезно ответить для себы на вопросы в контексте последних постов.
Флоризель, само собой, все и так знает, ну а с другими форумчанами можно продолжить, если потребуются уточнения.

Дык я же объяснил.
Существует такая правктика - для отладки кусок проги переносить в ОЗУ.
Чтобы отладка шла быстрее. Вроде ограничение в скорости там одно - время перезаливки проги с новыми точками останова.
Или причина переноса отладки в ОЗУ - другая?
И почему сразу - бредни?
Может лучше использовать - заблуждения?



Спасибо.
А как по поводу заливки своего бинарника и внесение исправления в дизассемблируемый код?
inline asstmbly у меня все время серая.
И как отключить перескок полоски скроллинга на панели дизассемблера - больно хлопотно ставить адресс конкретный адресс когда шаг установки в 300 байт.



Контрольные вопросы для Принца Флоризеля, который, как известно, знал все заранее и любое решение находил
несколько ранее собеседников:
1. Сколько указателей стека у LPC176x (Cortex-M3)?

Два.

2. Какой из них инициализируется аппаратно?

Ни какой. Но один из них инициализируется в коде инициализации.
Щас гляну, как он называется - во - MSP.

3. Есть-ли какие либо ограничения на софтовую инициализацию указателей стека?

Ага. Его нелзя ставить на начало ОЗУ. И туда, где нет ОЗУ.
И выравнивать надо.

4. Какие действия выполняются в startup до запуска main()?

Ой, много. Толко вот попасть на код инициализации не всегда получается.
Вы про линкер уже прочли? Умеете модули линковать в ОЗУ?

5. Функция __main() в default startup KEIL это то-же самое, что и main()?

Не а. Это и есть начало кода инициализации.
В стартапе на нее только ссылка. Сама она от линкера.

6. Сколько записей в таблице векторов Cortex-M3 жестко отведено под нужды ядра?

Четыре первых. Реально используется два первых при запуске проги.

7. Какие утилиты входят в классический набор утилит binutils, каковы их аналоги в пакете от KEIL?

Без понятия.

8. Что умеет делать утилита fromelf из комплекта поставки KEIL?

Бинарник для заливки посторонними заливщиками.

Ну и вообще начинающим будет на мой взгляд небесполезно ответить для себы на вопросы в контексте последних постов.
Флоризель, само собой, все и так знает, ну а с другими форумчанами можно продолжить, если потребуются уточнения.

Надеюсь Вас не затруднит дать на свои вопросы правильные ответы?
Или как всегда - характер не позволяет давать глупые ответы, даже на глупейше-пустейшие вопросы...

Ответы на все вопросы, кроме первого и частично третьего, данные vallav не верные, если не считать "Ой много" и "Без понятия", которые вообще не ответы. Особенно заслуживает внимания шедевр "Сама она от линкера" . Примерно так-же объясняли множество вещей первобытные люди - "она от бога", и точка. Остальное соответственно домысливали, как умели, измышляя легенды и мифы.
Продолжаем опрос:
1. Сколько в ядре Corteх-M3 поддерживается Breakpoint и Watchpoint.
2. Что такое за Flash Patch механизм?
3. Зачем при наличии 1 и 2 пунктов нужна "перезаливка проги с новыми точками останова"

Вы забыли дать правильные ответы.
Или их не дали по причине - характер не позволяет давать глупые ответы, даже на глупейше-пустейшие вопросы...

Почему до Вас никак не дойдёт, что один из указателей SP инициализируется аппаратно?
Нажмите для просмотра прикрепленного файла

Так я разве спорю.
Конечно, core reads the start sp...

Только как?
Мое мнение, в NXP не идиоты делать это аппаратно, когда это можно с тем же успехом сделать программно в коде инициализации.
Что там и делается.
Полагаете - просто на всякий случай? Код инициализации игнорирует значение sp при входе в него и записывает в sp ( программно )
значение, равное __initial_sp.
Кстати, задумайтесь - после сброса начинает работать бутлоадер.
У него sp откуда берется? Аппаратно устанавливается на 0xffffffff, если чип не целованный?
А если прога уже загружалась, то на то, что в первом слове флеша. Так?
И что бутлоадер с этим делает? Выкидывает и ставит свое значение?
А перед запуском проги читает значение из первого слова флеша и заносит его в sp?
Иде в этом логика?
Кстати - кривой бангладорский при запуски проги про sp даже не вспоминает. Что у него было, то и оставляет.
Как с этим у родного бутлоадера - пока не знаю.
Не надо свято верить тому, что напечатоно. И в печатных текстах бывают ошибки и казусы...

Кстати надо попробовать. Засунуть в первое слово флеша что нибудь отличное от __initial_sp и посмотреть, с какмим
sp прога в main вывалится. Если со значением __initial_sp - что делать будем?

И про ip. Полагаете, после сброса он загружается значением из второго слова флеша и бутлоадер стартует с этого адреса?
Или бутлоадер умеет игнорировать значение ip и стартует со своего адреса?
Попробуйте над этим задуматься.

В связи с предыдущим постом продолжаю вопросник:
1. Как называется фирма-разработчик ядра Corteх-M3 используемого фирмой NXP в контроллерах LPC17xx?
2. Какой блок памяти отображается на адрес 0x00000000 в LPC17xx после аппаратного ресета?
3. Что находится в этом блоке памяти?
4. Может-ли в качестве вектора Reset указан адрес функции написанный на языке высокого уровня, например, 'C'?
5. Использует-ли функция написанная на языке 'C' стек и для чего?

Я сейчас другим занят - жду от Вас правильных ответов на первый опросник.
Увы, пока их не будет...

"Студент"! Вы не поняли - семестр кончился - началась сессия. . Но вопросы пока доброжелательно-наводящие, а не на засыпку.

Пока не страшно. Сдача и пересдача экзаменов до осени. Потом отчисление .

Кстати, Вы наверно будите удивлены, но в качестве адреса ресета может быть указана функция, написанная на C.
Если модуль с ней слинкован в флешь.
Не верите - а попробуйте.
Хотя - Вы же fabless...

Ответ правильный. Угадали? Но процент угадывания много ниже статистических 50% . Не везет .
Теперь ответ на вопрос номер 5. И после подробнее насчет "идиотов":

и соответственно того, когда и кем указатель стека иницализируется до момента вызова этой самой первой функции.
Кстати, на вопросы надо отвечать на все - Вы слишком много вопросов пропускаете. Незачет будет!

С чего это Вы так тешите себя этой иллюзией . Придется и с этой иллюзией Вас обломать. В На фото в приложении Cortex-M3 в двух экземпярах. Есть и третий.

Неужели проверить успели?
Вот это скорость...

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

Офигительная. Настоящая машина времени - на майские праздники пришли борды и тогда-же я портировал операционку, консольку, Ethernet, загрузчик и прочее. До этого, урывками почитывал первоисточники - ну думаю в сумме не менее 40 часов. Месяц тому назад еще сутки усиленного чтения и за 3 дня вышеупомянутое было поднято. Сейчас занимаюсь другим. Дней через 10 дней продолжу.