I2C в STM32F37, ошибка в железе?, Попытка работы с M24M01 (EEPROM) через DMA. Опции

[fatlortroll]

Доброго времени суток всем. Есть отладочная плата 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.

[rudy_b]

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

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

[bseyur]

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

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

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

Прикрепленные файлы

 UM1566.pdf ( 517.12 килобайт ) Кол-во скачиваний: 12
 STM32F37x_CPAL_Driver.rar ( 30.51 килобайт ) Кол-во скачиваний: 10