На сегодняшний момент вызывает вопрос код в 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);
Но надо все проверить .... думаю к вечеру это дело прояснится
Цитата(k155la3 @ Jul 29 2016, 10:17)
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 занимаюсь только около месяца....почитаю, разберусь и попробую применить...
Цитата(serglg @ Jul 29 2016, 12:06)
Чувствую, что в HAL-драйверах какая-то засада при работе с 8-битным приемом.
У меня вот тоже ОЧЕНЬ-ОЧЕНЬ похожие чувства.....сильно похоже на засаду....еще в коде полностью не разобрался, но есть большое желание это все прошерстить
