Перейти к содержанию
    

bseyur

Участник
  • Постов

    65
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о bseyur

  • Звание
    Участник
    Участник

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

1 384 просмотра профиля
  1. Добрый день! Решил не создавать отдельную тему. Ни у кого среда не зависает при запуске сборки проекта? Не в каждом случае, но бывает. Можно даже сказать, регулярно. Версия 8.40.1 для ARM.
  2. Благодарю за наводку! Мне приходило это в голову, но я думал, есть более изящное решение) PS. Я бы добавил этот вопрос в FAQ :)
  3. Добрый день! Вопрос по автонумерации компонентов. К примеру, есть сложный компонент (некий ОУ, логика и т.п.), состоящий из двух или более одинаковых частей. По умолчанию Part ID у них не залочен. В схеме используется много таких компонентов, и они логически сгруппированы мною. Я хочу, чтобы компоненты с совпадающими Designators после автоматической перенумерации по-прежнему оставались под одинаковыми Designators. Как это можно сделать? Сейчас AD упорно "раскидывает" такие элементы по разным корпусам. Спасибо!
  4. Линковщик IAR 7.50

    Ну практика показала, при каждой сборке не обязательно проверять, достаточно раз написать стабильно работающую конфигурацию :-)
  5. Линковщик IAR 7.50

    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-файлу.
  6. Спасибо, посмотрю! Вообще пробовал на разных частотах, сейчас стоит кварц на 8 МГц без PLL.
  7. Доброе время суток, уважаемые коллеги! Возможно, ранее поднималась похожая тема, но я пока не нашел. Есть миландровский МК 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)?
  8. Полностью согласен. Разбираться с периферией на STM32, если где-то что-то не работает, приходится довольно долго. I2C в особенности. Бывает, самая незначительная ошибка приводит к странному поведению девайса, и мозг сломаешь, пока найдешь истинную причину. Кривизна библиотек - это отдельная тема. Вот на днях бился с CPAL. Документация скудная, а в интернете информации по этой библиотеке минимум. Даже спросить-то не у кого... Связь постоянно рушилась после энного количества (порядка нескольких сотен) успешных транзакций. Контроллер то начинает отправлять в шину неверные данные, то "видит" NACK, которого на самом деле нет. На разбор полетов ушло несколько дней. Оказалось, CPAL при неясных обстоятельствах иногда(!) повреждает указатель pbBuffer, который хранится в статической структуре и указывает на массив с данными для отправки/приема. В результате весь контроллер начинал себя вести неадекватно, маскируя источник проблемы. Сейчас в программе перед началом каждой транзакции указатель pbBuffer принудительно устанавливается в требуемое значение - проблема ушла. Ссылку на сайт с библиотекой с ходу не нашел. Во вложении CPAL v2 для серии STM32F3XX. UM1566.pdf STM32F37x_CPAL_Driver.rar
  9. Библиотеку CPAL использовать не пробовали? Там есть режим для работы с внешней памятью, и поддержка ДМА. Нельзя сказать, что без проблем, но вроде, тьфу-тьфу-тьфу, оно работает.
  10. STM32F3 SPI

    Понятно, здесь SSP как бы ни при чем. Правильно будет организовать побайтную передачу.
  11. Скорее всего, в момент прошивки флеш ядро обращается к обработчику какого-нибудь прерывания.
  12. STM32F3 SPI

    А в вашем случае бит "MSB first" установлен? Никогда не сталкивался с такими трудностями на NXP, всегда пользовался примитивнейшими конструкциями. Может, дело в объявлении регистров? У меня регистр DR объявлен с типом unsigned long. Чтение 16-битного слова: data_ptr[index++] = (unsigned short)SSP1DR&0xFFFF; Запись еще проще, что-то вроде: unsigned int value = 0xAABB; SSP1DR = value; Передача идет старшим битом вперед, не помню, чтобы использовал обратный порядок. Соответственно, первым при передаче идет старший байт.
  13. Ну, если целостность данных в обоих случаях сохранена, то причина явно нев интерфейсе I2S. В спящем режиме флэш не работает, соответственно DMA не имеет к нему доступ.
  14. Разница есть, если совместно с I2S используется DMA и режимы энергосбережения. В остальных случах, кажется, все равно.
  15. В stm32f4xx_gpio.c должно быть, как минимум, #include stm32f4xx_conf.h, т.к. в последнем дано определение assert_param
×
×
  • Создать...