GreyM

Начал осваивать DSP на примере TS201. Один коллега (в данный момент вне зоны доступа) выдал пример на С. При попытке компиляции (использую Visual DSP++ 4.0) выдает ошибку "Silicon anomaly", связанную с эрратой кристалла, что нельзя читать регистр INTCTL. Номер ошибки в эррате ea3047, silicon anomaly number: 03-00-0213. А пример сначала считывает его, а потом инвертирует один бит. В эррате написано использовать _Save_INTCTL, которую я нашел объявленной как переменную в одном из асмовских файлов, используемых в моем проекте. .var _Save_INTCTL=0; .global _Save_INTCTL; Я попытался обращаться к этой переменной из кода, используя extern, но у меня не получилось. После этого я попробовал добавить ассемблерную вставку и в ней объявить эту переменную как extern. Примерно так (цитировал приведенное в эррате решение): asm(".extern _Save_INTCTL; / R0 = 0x111;; / INTCTL=xR0; [J31 + _Save_INTCTL]=yR0;;"); Вроде бы, компилятор пропускает такую вставку и делает успешный билд, но после этого возникает следующий вопрос: как получить считанное значение? Т.е. как теперь передать это значение основной программе на Си? Может кто-то сталкивался с использованием этого регистра? Или с передачей значений в ассемблерные вставки и получении их обратно? Наставьте на путь истинный.

Спасибо за доходчивые ответы :) Мне это как то не пришло в голову, ведь код инициализации совсем небольшой, а контроллер достаточно мощный. Но на будущее буду иметь в виду.

Здравствуйте, уважаемые форумчане. Хочу поделиться с вами историей, которая лично меня привела в ступор. С недавних пор я занялся тем, что решил запустить FreeFTOS 7.1.0 на STM32F103. Ситуация осложнялась тем, что я использовал IAR 6.1, в то время как примеры для этой платы были сделаны для IAR 6.3, и мой 6.1 уже не мог корректно открыть такой проект - при попытке открытия сбрасывались все настройки. Но я не расстроился, и выставил все настройки и зависимости вручную. После чего мой код успешно стал уходить в HardFault на инструкции смены стека при попытке запустить первую задачу: vPortStartFirstTask /* Use the NVIC offset register to locate the stack. */ ldr r0, =0xE000ED08 ldr r0, [r0] ldr r0, [r0] /* Set the msp back to the start of the stack. */ msr msp, r0 /* Call SVC to start the first task. */ cpsie i svc 0 Я долго бился головой об стену, искал по разным форумам и вообще делал все, что только мог, но проект так и не заработал. Дело осложнялось тем, что я хотел использовать С++ для пользовательской части кода. В конце концов мне улыбнулась удача: на просторах интернета я нашел сайт, на котором его владелец предлагал готовый шаблон проекта для STM32F103 + FreeRTOS 7.1.0 + StdPeriph с использованием С++ - (Ссылка на шаблон. Автор писал, что всё оттестировано на IAR 6.3. В комментах было множество благодарных отзывов и подтверждений корректности работы. Моя версия ИАРа попрежнему не могла корректно открыть проект, поэтому я вручную настроил ссылки на все библиотеки и... Получил hardfault. После такой неудачи я был окончательно демотивирован и нашел таки установщик иара 6.3. После этого я опять разархивировал проект, открыл его, запустил и был вознагражден мигающей лампочкой. Моему счастью не было предела. Однако, каково же было моё удивление, когда первая версия шаблона, которую я настраивал руками, скомпилированная обновленным ИАРом опять ушла в hardfault. После этого я стал методично сравнивать настройки проекта. Во второй вкладке я дошел до закладки "Оптимизация", которая в шаблоне была выставлена в medium, а в моём проекте была отключена для упрощения отладки. В новом шаблоне я попробовал отключить оптимизацию и - бинго! Он тоже упал. После этого я пытался играться с параметрами, но любые вариации, при которых оптимизация была ниже средней, приводили контроллер в hardfault. Мне пришлось смириться, ведь, в конце концов, задача была решена. Однако, мой внутренний мир находится в сметении. Я могу понять, что криво написанный код может переставать работать при включении оптимизации. Но как код может переставать работать при её отключении? Заранее благодарен за ваши варианты ответов на этот вопрос.

Заработало! Спасибо всем откликнувшимся! Обстояло всё следующим образом: при проверке осциллографом выяснилось, что импульсы по RX от PHY не идут. Как оказалось, это было связано с маломощным источником питания (предположительно, во время приема потребление подскакивало и PHY отваливался). При замене на хороший источник импульсы пошли. После этого был повторно проверен исходник и выяснилось, что для платы STM32F10С-EVAL, которая по сути является прообразом TE-STM32F107 по умолчанию используется PHY DP83848, для которого адрес PHY равен 1, в отличие от PHY rtl8201, используемого в TE, где адрес равен 0x1F. Плюс к этому лично мне помогла замена инициализации пинов из примера IAR на инициализацию из примера терры. Однако тут есть подводный камень - в основной программе происходит ремэп пинов, который можно не заметить, просто изменив GPIO_Configuration. Так же в одном из примеров IAR напрямую проверялась версия PHY путем чтения 2 и 3 регистра и сравнения с контрольным значением для DP83848. Отдельно хотелось бы упомянуть то, что в примере от терры в main осталась строчка "#define DP83848_PHY", которая лично меня поначалу сбивала с толку. Еще раз благодарю всех, кто помогал мне с этой проблемой, особенно ув. EugenyAM.

Итак, вот результаты: проверил PHY - действительно в некоторых примерах оно инициализировалось не верно (в примере адрес 0x01, а у терры PHY по адресу 0x1F). Однако замена адреса PHY на нужный радикально ничего не поменяла. Всё остальное проверил - подходит. В итоге результат тот же. Осциллографом пока проверить не было возможности, но, видимо, скоро это будет единственным методом. При этом как раз пример из ИАРа рассчитан на PHY по адресу 0x01. На мою проблему вышеуказанный топик не похож, так как у меня до уровня МАС ни один пакет ни разу не поднялся. Если бы были только битые CRC, было бы пол беды. Да и PHY у меня - rtl8201cp. При этом чтение всех регистров PHY проходит успешно, однако, как бы я не старался, счетчик принятых пакетов оставался нулевым.

В программе поочередно ставил точки останова где только можно - ни одна ни разу не сработала. Поэтому и есть подозрение на нерабочий PHY. Остальное буду пробовать

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

Использую TE-stm32f107. Пытался запустить тестовый пример из IAR'а - WebServer_Demo_uIP. Контроллер на все попытки общения по сети не отзывается. Тогда я нашел на сайте терры аналогичный пример (правда под gcc), взял из него инициализацию пинов (подумал, вдруг различается). Результата нет. Тогда я убрал инициализацию веб-сервера и попробовал на уровне MAC передавать сообщения от контроллера на хост и обратно. Соединил проводом - пробую. Контроллер напрямую отправляет пакеты, хост ловит. Обратно - пакеты отправляются, контроллер - ноль эмоций. Предположил, что может не вызываться обработка приходящих сообщений (хотя до этого брейки ставил везде где можно) - попробовал настроить прерывания по Ethernet - не реагируют ни на прием, ни на отправку. При этом другие прерывания работают. Пока больше идей нет. В чем может быть дело? Помогите, пожалуйста!

Это не совсем так. CANopenNode предоставляет 8 шт. по умолчанию (т.е. для них прописано отображение и тому подобное). Однако, в самом стеке (в мануале и в файлах CO_OD .c и .h) оговаривается, что нет никаких принципиальных проблем руками дописать необходимое количество PDO. То же самое относится и к heartbeat'у.