Это верно, ограничение на размер у линкера (xlink), и ему пофигу, на чем исходники был написан и в каких комбинациях.

А вот SFRx - они не для переменных придуманы. Это аббревиатура от Special Function Register - для описания регистров, к которым по железным причинам недопустимы какие-то виды операций с какими-то размерами данных. Хотя, конечно, как костыль использовать можно, особенно если размещение переменных по адресам памяти охота вручную делать.

Бывают случаи, что не просто охота, а надо!

Я тут добавил кое-что...

В моей нынешней программе около 1кБ кода, для эксперимента еще 4096 байт тупо замостил байтами директивой DB, ничего не ругается, при запуске отладки смотрю содержание FLASH - все вроде ок. Я не могу наверняка сказать, что не использую линкер (потому как не знаю когда он там нужен, вернее догадываюсь, но проверять чо-то не хочется), но походу если не использовать его, то можно и больше 4кБ компилировать. Так? Или я чего-то недопонял опять? Или директива DB для читоты эксперимента не катит, нужно именно командами замостить типа NOP?

Честно говоря, именно в контексте MSP430, у которого нет внешней шины, куда может быть что-то снаружи подключено по фиксированным адресам, и в котором нет DMA доступа для кого-то, расположенного снаружи, не верится, что это бывает надо. Все красиво решается средствами ассемблера - RSEG, ASEG, COMMON, и получается при этом максимально перемещаемым.



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

Замостил NOP (эквивалент 0x4303, смотрю через отладчик), начиная от 0xEF3C до 0xFF3C (4096 байт), плюс как и говорил около 1кБ своего кода. Также все ок. Э... хм... я что-то не так делаю? Или всеже PUBLIC/EXTERN в данном случае помогают линкеру понять сколько программного кода написано? Или может фирменный FET как-то влияет? Я уже начал "привыкать" к иару, а пиратить ничего не хочется. Варианты подскажите как еще его проверить на ограничение?

У меня вот такие сообщения пишет (после чего успешно запускается отладчик):



Может у кого после слова Linking что-то пишется вообще? Я имею в виду даже при компиляции программы размером менее 4кБ.

Ну, возможно, у Вас 8 кбайт ограничение (такое тоже бывает для каких-то семейств), или действительно, вообще при работе с FET ограничений нету. Линкеру никаких не надо дополнительных директив, чтобы знать размер кода - он тупо суммирует размеры всех сегментов, в которых код.


И Вы до сих пор утверждаете, что не пользуетесь линкером? :D

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

А поповоду 8кБ - проверю и сей момент сейчас. Замощу JMP $ 24кБ, они у меня все равно пустуют, потому как ПО пишу, исходя не из богаства 5137, а из будущей 5133, она вроде подешевле.

Смотрите как я получил ограничение. Я создал шаблон проекта на ASM. В качестве отладчика у меня симулятор. Ставлю режим Release, делаю Project - Rebuild All. После этого иду в папку проекта и ищу там скомпилированный файл .a43 (это файл в формате intel hex). Вместо этого файла вставляю другой файл с таким же именем, который содержит скомпилированную большую программу. В проекте делаю Project - Download and Debug и получаю от системы сюрприз:


Кроме того потом еще вижу в Debug Log:


Однако дальше становится еще интереснее. После всех выше описанных действий я делаю Project - Rebuild All и Project - Download and Debug. Все загружается на отладку, однако в окне кода я вижу, что загрузился не только скомпилированный код, но и тот, который был в большом файле. Однако если закрыть симулятор и снова запустить на отладку, то код из большого файла пропадает. Вот так.

Это они что-то поднамутили более свежего... Раньше оно еще на этапе компиляции ругалось, что не слинкую Вам ничего, так как кода много. А теперь, смотрю, симулятор ругается... Да и пусть ругается, кому он нужен то, если вся отладка всегда "вживую" на чипе.

Замостил связкой:



Пространство с 0x8000 до 0xDFFF (24'576 Байт). Ничего не ругается.

То ли лыжи, то ли пол третьего ночи... Часовой кварц припаян, биты P5SEL[0/1] установлены, в регистре UCS включаю XT1 в режиме LF, выбираю емкость 12пФ при DRIVE=0, нифига не запускается... читаю дальше и вижу, что мне говорят: "мол, по-умолчанию, XT1 изначально настроен и сигнал подается на FLL с тактированием ACLK, только XT1 не включен. А если его включить, то, мол, он сразу отрубится и ACLK будет тактироваться от REFO, потому как наша умная система заметит нестабильность в работе XT1 и поднимет флаг XT1LFOFFG." Как я понял надо периодически пробовать сбрасывать этот флаг, и когда он перестанет автоматически подниматься из-за нестабильности генерации - тогда можно считать, что XT1 запустился и каким-то образом после этого переключить тактирование обратно с REFO на XT1. И по поводу внутренней емкости - на моих кварцах требо 12,5пФ, как я понял пины МК имеют собственнуюпаразитную емкость около 2пФ, т.е. нужна внутренняя емкость около 10пФ, или должно при 12 запуститься? Поможите люди добрые, а то голова реально разболелась, аж тРррРРРрррРРещит

Начинаю художественное цитирование User's Guide

can be совсем не то же самое, что must be, не так ли? Стартовать нужно при максимальном усилении (XT1DRIVE = 2) и только после старта, когда генератор уже "раскочегарился", можно пробовать уменьшить его. Кстати, XTS нужно не забыть сбросить, а то в LFXT mode генератор XT1 не переключится. А биты P5SEL, относящиеся к XT1, тоже не лишне будет установить. Я в очередной раз настоятельно рекомендую инициализировать все перифейрийные регистры явными значениями, не надеясь на их default state.

Можно тупо ждать, сбрасывая XT1LFOFFG, а можно и не ждать, выполняя программу инициализации дальше. Через 1 сек проверить, стартовал ли LFXT? А до тех пор REFO вполне заменяет часовой кварц.

Чтобы не быть плохим пересказчиком и не объяснять "на пальцах", рекомендую прочитать MSP430 32-kHz Crystal Oscillators и MSP430 LFXT1 Oscillator Accuracy. Лично я всегда закладываю два внешних конденсатора "на всякий случай". Ибо по законам физики последовательное соединение конденсаторов с одинаковой емкостью уменьшает их суммарную емкость ровно вдвое. Поэтому для кварца с нагрузочной емокстью 12,5пФ по теории требуется два конденсатора по 25пФ, включенных впараллель выводам генератора (относительно общей точки - земли), но последовательно относительно выводов кварцедержателя.

Короче все запускается, оказывается помимо PxSEL нужно и PxDIR правильно настроить, а у меня вход XIN гены был настроен как вход, а надо как выход, во какая хрень (очень "логично" надо заметить).

Еще вопрос, но уже касательно сброса:

Периодически замечаю, что в SYSRST регистр записывается, к примеру 0x08, хотя согласно Datasheet этот вектор зарезервирован (т.е. не относится к какому-либо конкретному источнику сброса). У меня то на этом векторе заглушка стоит изначально типа "нет прерывания" (аналогично значению 0x00). Просто интерсено - это глюк или как? А еще сейчас видел разок как сброс произошел от SVSL, т.е. от супервизора питания ядра, нехорошо это..

Согласно Table 54. Port P5 (P5.0 and P5.1) Pin Functions, приведенной в datasheet, для включения пинов XT1 достаточно установить P5SEL.0. При этом значение P5SEL.1 и P5DIR.0/P5DIR.1 рояли не играет. Оказывает влияние еще и бит XT1BYPASS, который относится к системе тактирования, а не к портам.

Вы имеете в виду SYSRSTIV? Дык он расписан в User's Guide. Если значение меняется после подачи питания, то я бы начхал. После всей инициализации периферии значение SYSRSTIV можно сбросить любой записью в него, несмотря на то, что он описан как Read-only.

А вот если что-то появляется SYSRSTIV уже после инициализации (в процессе выполнения основной программы), тогда можно и повыяснять причины.

Играет играет! я изменил PxDIR отвечающий за XT1IN со входа на выход и программа перестала мертво висеть в цикле ожидания очистки бита XT1LFOFFG. При комнатной температуре XT1DRIVE не особо важен при запуске, в мороз наверное лучше начинать с XT1DRIVE=3 (хотя наверное и от качества кварца зависит).

Опытным путем получены достоверные результаты, позволяющие сделать определенный вывод: если хотя бы один из битов P5DIR.0 или P5DIR.1 установлен (в т.ч. если установлены оба) генератор XT1 не запустится. Оба бита должны быть сброшены. Как ни удивительно, но то же самое касается и регистра P5REN.

А вообще чего удивляться то? Схема пинов P5.0/XIN и P5.1/XOUT представлена на стр. 100, 101 Datasheet. На схеме четко показано, что пины МК напрямую подключены к входу и выходу генератора XT1 (напрямую - это значит в обход всей логики порта). Поэтому можно сделать вывод и без опытных экспериментов о том, что и PxREN и PxOUT естественно будут шунтировать вх/вых. генератора, тем самым нарушая его нормальную работу (а при некоторых вариациях порта - полностью исключающих запуск генератора XT1).

Ну что ребятки, кто будет маляву bug report к их ti employee отправлять? оказывается don't care - это ввод в заблуждение, статья КОАП как минимум, однако

Не будут. Там присутствует еще и логика, отключающая выход и подтяжку при PxSEL != 0.

Прежде, чем "кидать предъявы" вы бы припаяли в схему конденсаторы по 12пФ и показали вашу процедуру инициализации LFXT.

Уверен, дело не в этом. Потому как генератор отлично запускается, а сбой в его работе наблюдается только в случаях описанных мной выше (сугубо из-за инициализации линий ввода вывода).



Инициализация порта:



Запуск XT1 (LF), XDRIVE=3:





Очевидно, что шунтируют. У меня две платы с CC430 на борту и обе ведут себя одинаково. Можно было бы еще погрешить на порт маппинг контроллер, но его работа описана только для P1-P3, P5 функционирует без него.

Уверенность это хорошо. Но плоха излишняя самоуверенность Еще раз предлагаю вам припаять по конденсатору 12пФ ко входам XIN и XOUT так, чтобы суммарная емкость на каждом входе получалась около 24пФ. Нагрузочная емкость CL=24пФ/2=12пФ будет близка (с учетом 5% разброса керамики NP0) к номинальной 12,5пФ. У вас же сейчас кварц работает на CL всего лишь 6пФ=12пФ/2. При этом любой "чих" может приводить к проблемам с генерацией.
Тут еще можно вспомнить про баг XOSC8. Правда он характерен для других кристаллов MSP430. Но вы ведь наверняка про ESR кварцев пока вообще даже не задумывались, не так ли?
P.S. пользуйтесь, пожалуйста, стандартными хедерами TI со стандартными обозначениями битов. В противном случае я не гарантирую, что у меня будет желание разбираться с "магическими" числами, которыми вы инициализируете регистры.

Честно говоря я уже погрузился в Unified Clock System, и чем глубже в лес, тем толще партизаны.. Думаю, типичное рабочее место TI Engineer's Departament выглядит примерно так:



Черт ногу сломит в этом МК, кишащем RC-генераторами да еще и со всякими примочками и приблудами... Эх.. Ладно..



Ок, только у меня по-моему нет сейчас в распоряжении NP0 на 12пФ, но помоему есть 24пФ. Поэтому XCAP выставлю на 2пФ (как я подозреваю в этом случае емкость вообще не подключается, а используется собственная емкость пина) и подключу их. А еще, если не ошибаюсь есть 10пФ NP0/COG. Вобщем сейчас попробую... Эээээээ... только вспомнил, там на плате 0402, а у меня 0805 минимум, ради этого в офис не поеду.

Нарыл 4000шт COG 22пФ 5% 0805, сейчас припаяюсь и отпишусь.

Докладываю

Начальные условия:
XCAP = 2 пФ, внеш.C = 22 пФ COG 5% 0805 (корпус кварца припаян к общему, одна ножка внеш.конденсаторов припаяна XIN/XOUT, другая ножка припаяна в точку соединения корпуса кварца с общим). XT1DRIVE = 3. Температура окр.среды комнатная.

Результат:
По поводу влияния PxDIR, PxREN - все ровно также, как и при отсутвии внеш.конденсаторов. Единственное изменение - это увеличение времени запуска XT1, что не есть гуд.

Оффтоп: Надо мне побольше почитать про опыт применения внутренних емкостей, хочется верить, что "любой чих" не сбивает генерацию, т.к. время запуска значительно меньше, чем с конденсаторами суммарной емкостью 24пФ.

Еще немного результатов, не так важных, но мало ли может кому пригодиться.

Время запуска при комнатной температуре:

При внутр.C = 12 пФ + внеш. 22 пФ:

XT1DRIVE=0 - около 3 секунд
XT1DRIVE=3 - около 1,5 секунд

При внутр.C = 2 пФ + внеш. 22 пФ:

XT1DRIVE=0 - около 1 секунды
XT1DRIVE=3 - около 0,7...0,8 секунды

А можно мне совет?

Я что-то зря с этим XT1 походу заморачиваюсь, он мне по сути не нужен. Стабильность временных интервалов для меня важна только при работе модуля CC1101. Но он как я понимаю из описания полностью самостоятелен в плане тактирования (baudrate и т.д.) и тактируется от своего кварца. А мне по сути необходимо периодически просыпаться (примерно раз в 4 часа), мерить сигнал с записью его в ОЗУ + 10 секунд ожидать запрос хоста и засыпать снова (а если во время бодрствования пойман сигнал запроса данных, то передать эти данные хосту, после чего опять же уснуть). В 4 часах 14400 секунд, если предположить что погрешность DCO составит не более 5% в температурном диапазоне -40...+60 гр., то за 4 часа я получу ошибку отсчета времени в 12 минут, что в принципе не очень критично для моей задачи и вполне подойдет.

Так вот исходя из моей задачи мне можно оставить DCO (для тактирования ядра во время пробуждения и для периферии) и XT2 (для работы трасивера + тактирования ядра если возникла необходимость в быстром выполнении большого кол-ва операций). FLL мне тоже надо оставить для стабилизации DCO (чтобы ошибка 5% не стала больше). XT1, REFO и VLO я могу отключить и забыть про них (возможно вспомнив о них в других проектах). Правильно я мыслю? Как бы Вы сконфигурировали UCS? В том же составе или по другому?

Ну если вам на потребление начхать и 60мкА DCO vs 0,5мкА LFXT ничего не значат (не говоря уже о дестяке мА потребления генератора RF), то можно вообще ничего не отключать.