Добрый день, господа и товарищи.

По недомыслию попал в дурацкую ситуацию - программа была написана для процессора MSP430F5310 (32k), очень критичная по времени и использует DMA. Та, что есть память, использована меньше чем наполовину.
По размеру платы этот процессор не вошел, вместо него плата сделана под MSP430F5342, у которого 128к ненужной памяти, но зато корпус подходящий.

При компиляции все благополучно рассыпалось - и указатели, коих в программе море, и DMA, где только 16 бит использовалось.

Есть ли возможность сказать ИАРу плюнуть на лишнюю память и не использовать команды 430x вообще?
То ли плохо рыл - но пока ничего не нашел.

Чо, прям распалось на куски?
В чём рассыпание выражается?


Можно подредактировать скрипт линкера в плане урезания памяти.
Или выбрать msp с меньшим объёмом, но совместимый программно (если есть такой).


Как это - "не использовать команды 430x вообще"? А что ему использовать? Команды АВР или АРМ чтоли?
Не понял.

Практически на куски. Программа улетает непонятно пока (разбираюсь), продолжая выполнять некоторые из обработчиков прерываний.
Если конкретно - это наложение символов на видео. При старте пытаются мелькнуть какие-то артефакты, после чего основная программа перестает работать и, соответсвенно, подгружать видеобуфера (изображение формирует SPI c DMA).



К сожалению, по функциональности и размеру корпуса больше ничего не прошло. Нужно 48 ножек LLP, 2 SPI, I2C, UART.
Просто урезать память не пройдет - нужно запретить использование команд с расширенной памятью.


Ограничиться командами 430, не используя 430х (стр.168 SLAU208J), которые уменьшают скорость и приводят к разбуханию кода. Ну и указатели, похоже, становятся не 16 битными.
Судя по описанию процессора - нормальный путь, вот как только ИАР на этот путь наставить. Где-то должна быть галочка

дополнено - кажется, путь есть:

Under General Options, select "Generic MSP430 Device" for the target processor (not "Generic MSP430X device").
Under Linker, override the default linker configuration file and use $TOOLKIT_DIR$\CONFIG\lnk430****.xcl for your actual processor instead.
In code, #include the actual target msp430****.h file, not the generic msp430.h.

теперь компилятор ругается на

__data16_write_addr((unsigned short) &DMA1SA,(unsigned long) Vbuff1);

Error[Ta025]: Intrinsic function only available for the 430X core



Получается, MSP430F3410 все-таки использует 430х? Где же все-таки собака порылась?


Сообщение отредактировал varvar - Sep 16 2012, 05:34

А там нигде нет выбора модели памяти (tiny/small/huge)?

Есть Data model, в обоих случаях выбрана Small.

дополнено:

кажется, что-то относящееся к DMA - операции с ним во время прерываний убивают основной цикл. В эррате что-то есть про баги именно в этом процессоре, вроде как не совсем то...

Сообщение отредактировал varvar - Sep 16 2012, 07:26

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

Вы полагаете, я смотрю в окно на ворон сбившихся в стаю ? Естественно, все пытаюсь отследить - и операции с DMA сбивают стек. Причем речь не о переполнении - прерываний не много, они отслеживаются. Манипуляции с DMA приводят к тому, что программа сбивается в разных местах. Ноги проблемы растут, скорее всего, отсюда (еще заметьте, программа изначально рабочая на MSP430F5310 ):




Обойти вот только пока не получилось.

MSP430F5310 не имеет такого бага.

Опять дополнение - скомпилировал проект для Generic MSP430 device (без расширенных команд) - для того, чтобы убедиться, что все правильно для MSP430F3410 и для MSP430F5342 - та же картинка - для MSP430F3410 все пучком, а MSP430F5342 и DMA пакеты пропускает, и подвешивает основной процесс.
Похоже, надо к разработчикам процессора стучаться

Сообщение отредактировал varvar - Sep 16 2012, 18:38

А вы учитываете, что при возникновении прерывания ядро складывает на стек содержимое статусного регистра и счетчика команд? И у ядра 430X размер этих регистров другой? И если вы используете управление энергопотреблением и пытаетесть в прерывании менять сохраненное на стеке содержимое статусного регистра, то работая "как с 430" вы промахиваетесь и меняете что-то другое?

Управления энергопотреблением нет, прерываний кот наплакал. Ну и самое главное, с таким же подходом MSP430F3410 работает - а у него тоже ядро 430х. Товарищи из Германии пока молчат, как рыба об лед. Впрочем, они никогда не спешат.

С большой вероятностью проблема в том, что програма где-то расчитывает на строго определённый размер указателя - 16 бит. Может где-то для хранения значения указателя используется целочисленный тип (int/unsigned) и происходит срезка старших бит указателя или еще что подобное. Не нужно маскировать проблему - ее нужно решить. Обычно такие симптомы возникают именно при неосторожной работе с указателями.

Блин, да у них, оказывается, напряжение ядра программируется ! Хочешь больше частоту - повысь напряжение. Даже внимания на это не обратил - работало - и ладно. Роем дальше...

Все, спасибо за обсуждение, вопрос снят - нехай лишняя память остается, пусть мой пример будет другим наукой - у более свежих процессоров напряжение ядра PMMCOREV ручками устанавливать надо перед установкой частоты. Иначе они иногда работают - но в такой ситуации лучше бы не работали вообще - причина бы быстрее находилась.
Придется завтра перед немцами извиняться за дурацкие вопросы. Хотя качество примеров у них ухудшилось, и найти на сайте их стало намного сложнее.
Пример установки напряжения ядра из SLAU208J, кстати, не рабочий.

Сообщение отредактировал varvar - Sep 17 2012, 19:53

Немцы это кто, если не секрет? Texas Intruments?

Да, у тексаса много подразделений во многих странах, и в Германии как раз разработчики MSP.

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