STM32 HAL SPI ошибка или глюки IAR,, ошибка чтения SPI с помощью HAL от CubeMX Опции

[Pasa]

STM32F051, IAR, CubeMX

Читаю в пакетном режиме два регистра - ответ правильный. Добавляю чтение 3-его регистра - в приемном буфере ерунда.
На осцилографе картинка нормальная - все диаграмы и ответы красивые и правильные...

В парметрах функции пробовал и 3 сразу читать и в цикле по одному байту - не получается....

И вот так уже попробовал:

Код

uint8_t localRxBuf[4];
uint8_t data1,data2,data3;

HAL_SPI_Receive(&hspi1, (uint8_t*)&localRxBuf[0], 1, 10000);
data1 = localRxBuf[0];
HAL_SPI_Receive(&hspi1, (uint8_t*)&localRxBuf[0], 1, 10000);
data2 = localRxBuf[0];
//HAL_SPI_Receive(&hspi1, (uint8_t*)&localRxBuf[0], 1, 10000);
//data3 = localRxBuf[0];

придобавлении третьего чтения портятся data1,data2,data3......мистика какая-то. Повторюсь - на осцилографе все красиво и правильно

Такое ощущение, что HAL-библиотека глючит...
внутрь HAL что-ли полезть

Сообщение отредактировал IgorKossak - Jul 27 2016, 14:30

Причина редактирования: [codebox] для длинного кода. [code]-для короткого!!!

[Pasa]

На сегодняшний момент вызывает вопрос код в HAL_SPI_Init()

Код

  if(hspi->Init.DataSize > SPI_DATASIZE_8BIT)
  {
    frxth = SPI_RXFIFO_THRESHOLD_HF;
  }
  else
  {
    frxth = SPI_RXFIFO_THRESHOLD_QF;
    //frxth = SPI_RXFIFO_THRESHOLD_HF;   //  может надо здесь так?
  }

При установке 8-битного режима при инициализации SPI всегда делается frxth = SPI_RXFIFO_THRESHOLD_QF;
Хотя ручное прописывание frxth = SPI_RXFIFO_THRESHOLD_HF; не помогло...



Функция HAL_SPI_Receive() собственно сводится к вызову HAL_SPI_TransmitReceive().

В ней тоже вызывает вопрос вот это:

Код

  if((hspi->Init.DataSize > SPI_DATASIZE_8BIT) || (hspi->RxXferCount > 1))
  {
    /* set fiforxthreshold according the reception data length: 16bit */
    CLEAR_BIT(hspi->Instance->CR2, SPI_RXFIFO_THRESHOLD);
  }
  else
  {
    /* set fiforxthreshold according the reception data length: 8bit */
    SET_BIT(hspi->Instance->CR2, SPI_RXFIFO_THRESHOLD);
    //CLEAR_BIT(hspi->Instance->CR2, SPI_RXFIFO_THRESHOLD);   // может надо так?
  }

Хотя в stm32f0xx_hal_spi.h прописано вот это:

Код

/** @defgroup SPI_FIFO_reception_threshold SPI FIFO Reception Threshold
  * @{
  * This parameter can be one of the following values:
  *     SPI_RXFIFO_THRESHOLD or SPI_RXFIFO_THRESHOLD_QF :
  *          RXNE event is generated if the FIFO
  *          level is greater or equal to 1/2(16-bits).
  *     SPI_RXFIFO_THRESHOLD_HF: RXNE event is generated if the FIFO
  *          level is greater or equal to 1/4(8 bits). */
#define SPI_RXFIFO_THRESHOLD            SPI_CR2_FRXTH
#define SPI_RXFIFO_THRESHOLD_QF         SPI_CR2_FRXTH
#define SPI_RXFIFO_THRESHOLD_HF         ((uint32_t)0x00000000)

В результате на сегодняшнее утро предварительно помогла перед вызовом HAL_SPI_Receive() пачковая вычитка DR регистра:

Код

   dataX1=(uint16_t)hspi1.Instance->DR;
   dataX1=(uint16_t)hspi1.Instance->DR;
   dataX1=(uint16_t)hspi1.Instance->DR;
   dataX1=(uint16_t)hspi1.Instance->DR;
   HAL_SPI_Receive(&hspi1, (uint8_t*)&localRxBuf1[0], 1, 10000);

Но надо все проверить .... думаю к вечеру это дело прояснится

0. Как выделена память под буфер и данные - проверьте "время жизни". Ведь при передаче в ф-ю вы используете адрес,
а оптимизатору-компилятору это ПОФИГ
1. Ваш код работает в составе проекта или "отсажен" в минимальный вид для отладки.
(в смысле нет ли "сторонних" факторов влияния)
2. Я бы разобрался почему портится приемный буфер.
Заполните буфер паттерном.
Поставть на отладчике breakpoint типа "изменение памяти". Или вообще пошагово оттрасируйте состояние этй области.
Этот путь вылавливания демона проще всего - ведь есть "устойчивый сбой", и это хорошо
Проверьте, ведь возможно работу ф-ии SPI сбивает вообще что-то другое, к ней не относящиеся.
3. Ну и классика - размеры стека итп.

ps к п.0:
Чтоб компилятор не своевольничал, я нужные переменные итд
объявляю в глоб. области, в виде

Код

__root char flag_Alarm;
#pragma required=flag_Alarm

(IAR)

0. Буфер объявлен как глобальные переменные. Оптимизация компилера полностью отключена.
1. Собственно это начальный проект, но весь код отрублен и из main() вызывается единственный этот тестовый процесс чтения по SPI. Ничего лишнего нет. Все прерывания запрещены, кроме системного тика для HAL_Delay();
2. Собственно портится не сам буфер, а портится регистр DR.....ну и соответственно портится буфер
3. Стек не смотрел....но вроде ничего не делается для переполнения.

__root char flag_Alarm - эта штука для меня новинка, так как STM32 занимаюсь только около месяца....почитаю, разберусь и попробую применить...

Чувствую, что в HAL-драйверах какая-то засада при работе с 8-битным приемом.

У меня вот тоже ОЧЕНЬ-ОЧЕНЬ похожие чувства.....сильно похоже на засаду....еще в коде полностью не разобрался, но есть большое желание это все прошерстить