bseyur
Участник-
Постов
65 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о bseyur
-
Звание
Участник
Контакты
-
Сайт
Array
-
ICQ
Array
Информация
-
Город
Array
Посетители профиля
1 384 просмотра профиля
-
IAR ARM 8.40 IDE "падает" при запуске
bseyur ответил SimpleSoft тема в IAR
Добрый день! Решил не создавать отдельную тему. Ни у кого среда не зависает при запуске сборки проекта? Не в каждом случае, но бывает. Можно даже сказать, регулярно. Версия 8.40.1 для ARM. -
Вопросы начинающих 2017 г.
bseyur ответил Uladzimir тема в Altium Designer, DXP, Protel
Благодарю за наводку! Мне приходило это в голову, но я думал, есть более изящное решение) PS. Я бы добавил этот вопрос в FAQ :) -
Вопросы начинающих 2017 г.
bseyur ответил Uladzimir тема в Altium Designer, DXP, Protel
Добрый день! Вопрос по автонумерации компонентов. К примеру, есть сложный компонент (некий ОУ, логика и т.п.), состоящий из двух или более одинаковых частей. По умолчанию Part ID у них не залочен. В схеме используется много таких компонентов, и они логически сгруппированы мною. Я хочу, чтобы компоненты с совпадающими Designators после автоматической перенумерации по-прежнему оставались под одинаковыми Designators. Как это можно сделать? Сейчас AD упорно "раскидывает" такие элементы по разным корпусам. Спасибо! -
Ну практика показала, при каждой сборке не обязательно проверять, достаточно раз написать стабильно работающую конфигурацию :-)
-
place at end of RAM_region { block CSTACK }; Попробуйте так. Кроме того, есть директива fixed order, которая позволяет задать порядок следования секций именно в том порядке, как они объявлены в фигурных скобках. Например: define block STARTCODE_block with fixed order { readonly section .intvec , readonly section .startcode }; place at start of ROM_region { block STARTCODE_block }; Но в любом случае правильность работы скрипта нужно контролировать по map-файлу.
-
Спасибо, посмотрю! Вообще пробовал на разных частотах, сейчас стоит кварц на 8 МГц без PLL.
-
Доброе время суток, уважаемые коллеги! Возможно, ранее поднималась похожая тема, но я пока не нашел. Есть миландровский МК 1986ВЕ4 с ядром Cortex-M0, у которого под отладкой наблюдаются проблемы. В общем-то не критичные, с такими можно жить, но поведение весьма интересное... Суть в том, что во время выполнения программы среда отладки не должна обращаться к ячейкам flash, иначе следует сбой. К примеру, в ЯРе запускаем режим отладки. Среда нормально подключается к камню по SWD. Далее открываем окна Disassembly и Memory, где показывается содержимое flash-памяти. Выполнение программы НЕ останавливаем. В итоге получаем следующее: 1) При пролистывании содержимого окна Memory в некоторых ячейках Flash отображается "мусор". Но если остановить программу на брейкпоинте, то все нормально. 2) Сразу после сброса МК программа должна делать проверку контрольной суммы содержимого flash. При запуске в таком режиме проверка не проходит. Надо полагать, ядро тоже не может нормально прочесть содержимое Flash. 3) Иногда ядро падает в HardFault на инструкции доступа к flash (в самом коде ничего криминального) 4) Попытки доступа к RAM из среды отладки не приводят к вышеописанным проблемам. Техподдержка Миландра открестилась от этой проблемы и ссылается на некие настройки среды отладки. И действительно, j-link ничего не знает об этом МК, кроме того, что это Cortex-M0, но в дебаггер IAR конфигурация МК загружена! Из доступных настроек есть только уставка скорости обмена, и ее занижение не дало результата. В связи с этим возникают вопросы: 1) Можно ли "прописать" отечественные МК в базу j-link, и вообще, насколько это важно для отладки? 2) Как в теории чтение памяти МК из среды отладки может помешать нормальному выполнению кода (применительно к Cortex-M0)?
-
I2C в STM32F37, ошибка в железе?
bseyur ответил fatlortroll тема в ARM
Полностью согласен. Разбираться с периферией на STM32, если где-то что-то не работает, приходится довольно долго. I2C в особенности. Бывает, самая незначительная ошибка приводит к странному поведению девайса, и мозг сломаешь, пока найдешь истинную причину. Кривизна библиотек - это отдельная тема. Вот на днях бился с CPAL. Документация скудная, а в интернете информации по этой библиотеке минимум. Даже спросить-то не у кого... Связь постоянно рушилась после энного количества (порядка нескольких сотен) успешных транзакций. Контроллер то начинает отправлять в шину неверные данные, то "видит" NACK, которого на самом деле нет. На разбор полетов ушло несколько дней. Оказалось, CPAL при неясных обстоятельствах иногда(!) повреждает указатель pbBuffer, который хранится в статической структуре и указывает на массив с данными для отправки/приема. В результате весь контроллер начинал себя вести неадекватно, маскируя источник проблемы. Сейчас в программе перед началом каждой транзакции указатель pbBuffer принудительно устанавливается в требуемое значение - проблема ушла. Ссылку на сайт с библиотекой с ходу не нашел. Во вложении CPAL v2 для серии STM32F3XX. UM1566.pdf STM32F37x_CPAL_Driver.rar -
I2C в STM32F37, ошибка в железе?
bseyur ответил fatlortroll тема в ARM
Библиотеку CPAL использовать не пробовали? Там есть режим для работы с внешней памятью, и поддержка ДМА. Нельзя сказать, что без проблем, но вроде, тьфу-тьфу-тьфу, оно работает. -
Понятно, здесь SSP как бы ни при чем. Правильно будет организовать побайтную передачу.
-
Скорее всего, в момент прошивки флеш ядро обращается к обработчику какого-нибудь прерывания.
-
А в вашем случае бит "MSB first" установлен? Никогда не сталкивался с такими трудностями на NXP, всегда пользовался примитивнейшими конструкциями. Может, дело в объявлении регистров? У меня регистр DR объявлен с типом unsigned long. Чтение 16-битного слова: data_ptr[index++] = (unsigned short)SSP1DR&0xFFFF; Запись еще проще, что-то вроде: unsigned int value = 0xAABB; SSP1DR = value; Передача идет старшим битом вперед, не помню, чтобы использовал обратный порядок. Соответственно, первым при передаче идет старший байт.
-
Ну, если целостность данных в обоих случаях сохранена, то причина явно нев интерфейсе I2S. В спящем режиме флэш не работает, соответственно DMA не имеет к нему доступ.
-
Разница есть, если совместно с I2S используется DMA и режимы энергосбережения. В остальных случах, кажется, все равно.
-
В stm32f4xx_gpio.c должно быть, как минимум, #include stm32f4xx_conf.h, т.к. в последнем дано определение assert_param