Доброго времени суток всем. Есть отладочная плата STM32373C, пытаюсь организовать работу её контроллера с EEPROM. При работе с установленными на ней EEPROM-инами случились следующие проблемы:

1. При приёме NACK в режиме Master-Reader не взводится флаг этого самого NACK-а и, соответственно, не вызывается прерывание (прерывания разрешил, TC и TCR, например, взводятся). В режиме Master-Writer при появлении NACK-а на шине глохнут по меньшей мере прерывания I2C и USART (остальные проверять пока лень).

2. После корректной записи в EEPROM по заданному адресу пробую прочитать записанное с того же адреса: функции I2C_TransferHandling задаю канал I2C, адрес EEPROM на шине, количество байт к передаче (2 байта адреса, с которого будет производиться чтение), режим SoftEnd и Generate_Start_Write, после чего настраиваю DMA на передачу этих двух байт адреса чтения. На осциллографе виден сильно другой адрес, не тот, который задан в переменной. Причём, если производить чтение после сброса контроллера -- адрес отдаётся корректный. Первая же запись всё ломает.

Сталкивался ли кто с подобными проблемами, и есть ли решения? Если да -- поделитесь. Очень уж неохота программно реализовывать I2C.

Библиотеку CPAL использовать не пробовали? Там есть режим для работы с внешней памятью, и поддержка ДМА.
Нельзя сказать, что без проблем, но вроде, тьфу-тьфу-тьфу, оно работает.

Когда я касался вопроса I2C, то где-то читал, что ST при работе с этим интерфейсом настаивают на использовании их собственных библиотек. Есть там какая-то заморочка с временными интервалами. Я взял билиотечные функции и перепер их на понятный язык (без индусских наворотов). Все отлично заработало.

Может поможет.

 eep.zip ( 1.89 килобайт ) Кол-во скачиваний: 98

Пробовал -- оно вообще отказалось взлетать. Собственно, отчего я и полез вручную всё это раскручивать. А какие проблемы с CPAL-ом были?

Можно ссылку на неё?

Например, только для F3xx отдельно искать надо.

Не знаю как в stm32f3xx (если правильно указано), а в STM32F207 для I2C и в харде и в либах нарисована полная лажа, которая работает совершенно криво. Стандартные либы не работают вообще. Т.е. у них есть какие-то баги в харде (изматерился борясь с кривизной харда) и они попробовали скомпенсировать их софтом, но тоже неудачно. Нормально запустить их I2C (чтобы не взвисало ни в каких ситуациях, в том числе и при отсутствии ACK) удается только путем долгих проб и ошибок. Про ресурс, зажираемый в результате при работе с этой шиной, даже думать не хочется. Причем дебаггер только мешает - информация в регистрах меняется при их чтении.

И это без DMA. Что они накрутили там - не знаю и даже думать не хочу.

Печально. Так хорошо всё в теории получалось с DMA, и так отвратно на практике. А вообще ST за такую реализацию I2C пинают? Хоть какие подвижки происходят?

Не знаю, но, похоже, что нет. Они непрерывно и со страшной скоростью клепают новые версии (предполагаю, что, практически, с теми же ошибками) - тут не до исправлений.

И вообще, на мой взгляд, STM32F - это какая-то помойка периферии. Какой-то ихний рационализатор решил все сделать по своему и, вместо стандартных отработанных схем интерфейсов, наклепал что-то свое, совершенно невразумительное. При переходе на STM идиотизм периферии просто поражает.

А после чего поражает? Как по мне так после атмела нормально. Конфигурирование более гибче и продуманей.

Именно после атмела. Вы внимательно смотрели биты их I2C? Или работу с их RTC в сравнении со стандартными внешними чипами? И сколько команд требуется для аккуратной (именно аккуратной) работы с ними? Раз в 10-100 больше, чем на том же атмеле +непрерывное висение в таймаутах чтобы не пропустить зависания их замечательных программных автоматов в некоторых ситуациях. Я уже не говорю про отсутствие нормальных описаний, схем автоматов и т.п.

Имея такие ресурсы можно было сделать раз в 100 лучше. Обидно, проц хороший, но вынужденно висит на кривой периферии.

Полностью согласен. Разбираться с периферией на STM32, если где-то что-то не работает, приходится довольно долго. I2C в особенности. Бывает, самая незначительная ошибка приводит к странному поведению девайса, и мозг сломаешь, пока найдешь истинную причину.
Кривизна библиотек - это отдельная тема. Вот на днях бился с CPAL. Документация скудная, а в интернете информации по этой библиотеке минимум. Даже спросить-то не у кого... Связь постоянно рушилась после энного количества (порядка нескольких сотен) успешных транзакций. Контроллер то начинает отправлять в шину неверные данные, то "видит" NACK, которого на самом деле нет. На разбор полетов ушло несколько дней. Оказалось, CPAL при неясных обстоятельствах иногда(!) повреждает указатель pbBuffer, который хранится в статической структуре и указывает на массив с данными для отправки/приема. В результате весь контроллер начинал себя вести неадекватно, маскируя источник проблемы. Сейчас в программе перед началом каждой транзакции указатель pbBuffer принудительно устанавливается в требуемое значение - проблема ушла.

Ссылку на сайт с библиотекой с ходу не нашел. Во вложении CPAL v2 для серии STM32F3XX.