Nosaer

Здравствуйте. Начал использовать Mplab и столкнулся с непонятным поведением программы. Переменную "bFlagDataReady" инициализировал в файле tca0.c. Там же по прерыванию изменяю ее значение: bFlagDataReady = true. Согласно отладчику, bFlagDataReady в прерывании выставляется как нужно, но в main.c условие почему то не срабатывает. Хотя согласно отладчику, все выставлено верно(скриншот прилагаю). Как по мне элементарная конструкция, которая ранее никогда не вызывала проблем, но здесь прямо ступор. Возможно другие IDE, которые я использовал ранее, мне прощали какую то мою ошибку. // В Файле tca0.c определяю переменную. И в прерывании меняю статус на true bool bFlagDataReady = false; // В Файле tca0.h extern bool bFlagDataReady; // В файле main.c #include "mcc_generated_files/timer/tca0.h" int main(void) { SYSTEM_Initialize(); while(1) { if(bFlagDataReady == true) // Сюда не заходит { LED.OUTTGL=PIN3_bm; //vDataCalculation(); bFlagDataReady = false; } } }

Здравствуйте. т.е. у меня есть проект, который без проблем работает со всевозможными NAND флешками типа SLC. При попытке заменить SLC память на MLC или TLC, максимум что могу ID сосчитать. Стирание/чтение/запись уже не работают. т.к. MLC и TLC медленнее. тайминги увеличил, но не помогло. Судя по даташитам, набор команд у них примерно одинаковый. Есть ли какие то нюансы(разница) при работе с SLC или TLC памятью?

Спасибо, за рекомендации. Что то я на самом деле упустил момент с параллельным включением.

День добрый. Пытаюсь найти малогабаритный NTC термистор, который при 25 градусах имел бы сопротивление 0-300 Ом, а при низких температурах чтоб сопротивление было от 5кОм и выше т.е. нужны экземпляры с довольно крутой R/T характеристикой. из того, что нахожу либо при отрицательных температурах не выше 1кОм, либо при положительных температурах кОмы Возможно кто то использует что то подобное или сталкивался с такими.

Arlleex, большое спасибо. // if ((huart->Init.WordLength == UART_WORDLENGTH_9B) && (huart->Init.Parity == UART_PARITY_NONE)) // { // if ((((uint32_t)pData) & 1U) != 0U) // { // return HAL_ERROR; // } // } Решило всю проблему, МК и в самом деле автоматически подстраивается

1) STM32G071 2) Размер буфера взят с большим запасом. В прерывании по простою вычисляю сколько данных пришло. 3) Я понимаю, что нельзя и почему. Но надеялся, что есть какого то рода обходные пути, чтоб как можно меньше исправлять уже в существующей программе. Как вариант нашел это: https://blog.ghmit.com.au/2019/09/stm32-9-bit-uart-halerror.html Но пока разбираюсь и не совсем понимаю как это реализовать.

Доброго времени суток. UART работает в 9 битном режиме. Девятый бит мне как таковое не интересен, поэтому я его всегда отбрасываю и собираю данные в 8 битный буфер. При запуске DMA на прием данных: uint8_t Data[BUFFER_SIZE] = {0}; HAL_UART_Receive_DMA(BKI_UART, &Data[Index], BUFFER_SIZE); В тех случаях когда Index нечетное значение, получаю HAL_ERROR HAL_StatusTypeDef HAL_UART_Receive_DMA(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size) { /* In case of 9bits/No Parity transfer, pData buffer provided as input parameter should be aligned on a u16 frontier, as data copy from RDR will be handled by DMA from a u16 frontier. */ if ((huart->Init.WordLength == UART_WORDLENGTH_9B) && (huart->Init.Parity == UART_PARITY_NONE)) { if ((((uint32_t)pData) & 1U) != 0U) { return HAL_ERROR; } } Собственно вопрос, можно ли как то это обойти?

У журнала "Современная электроника" тоже такая акция.

Извиняюсь, за долгий ответ. Как писал выше, проблемы выскакивают далеко не сразу. Поэтому понадобилось много времени, чтоб опробовать ваши советы. Не выставляется мастером. Хотя я больше склоняюсь, что ведомый удерживает линию. Сначала использовал HAL. После того, как столкнулся с проблемой переписал все на CMSIS. Проблема осталась та же. Поэтому исходник я в какой то степени исключил. Плюс у меня есть проекты на МК F0 и F1 серии, и там я тоже использую I2C и подобных проблем у меня нет. Питание слейвов отключаю. Делаю сброс как в вашем первом сообщении. В итоге на 2 или 3 измерении показаний опять зависает в том же месте. Опять делаю сброс. Опять хватает на 2-3 измерения и опять зависает. Итого после примерно 20 сбросов, начинает работать. Через сколько опять зависнет остается загадкой. Сейчас пробую второй предложенный вами способ. Тактировать линию, пока ведомый не отпустит SDA. Собственно мой код, где я выставляю Nak при чтении for(register uint16_t Counter = 0; Counter < Size; Counter++) { if(Counter < (Size-1)) { EmergencyCycleCounter = 0; while(!READ_BIT(I2C1->SR1, I2C_SR1_RXNE)) { EmergencyCycleCounter++; if(EmergencyCycleCounter > 1000) break; } pData[Counter] = READ_BIT(I2C1->DR, I2C_DR_DR); } else { CLEAR_BIT(I2C1->CR1, I2C_CR1_ACK); SET_BIT(I2C1->CR1, I2C_CR1_STOP); EmergencyCycleCounter = 0; while(!READ_BIT(I2C1->SR1, I2C_SR1_RXNE)) { EmergencyCycleCounter++; if(EmergencyCycleCounter > 1000) break; } pData[Counter] = READ_BIT(I2C1->DR, I2C_DR_DR); } }

Доброго времени суток. К МК подключено 2 микросхемы, с которыми он общается по средствам I2C. Запрос к обеим идет раз в секунду В процессе работы прилетает два типа косяков, которые могут себя проявить как через 10 часов работы, так и через 30. Поймать их отладчиком или анализатором довольно проблемно. При первом я просто получаю единоразово не корректные данные. При втором косяке полное зависание шины I2C. При первом косяке регистры: CR1 = 0x201 , SR1 = 0, SR2 = 0x03 При втором косяке регистры: CR1 = 0x301 , SR1 = 0x200, SR2 = 0x02 Случай с полным зависанием, удалось поймать анализатором пару раз. Видно, что не выставляется NAK по окончанию передачи и линия SDA остается прижатой к земле. В ерата на этот контроллер есть пункт 2.4.2, где описывается схожая проблема. Рекомендуют проводить Reset I2C. Но здесь или я чего не так делаю, или проблема не совсем та. В общем проблема никуда не уходит Возможно кто то сталкивался с таким или у кого есть мысли по решению проблемы?! Так же интересует каков правильный алгоритм для сброса I2C.

Всем большое спасибо. Проблема была в том, что при инициализации не выставлялся бит UDE в DIER.

Я пока не использую АЦП. А просто пытаюсь считать любой порт, где заведомо подал сигналы на некоторые выводы.

DMA менял в кубе. Контроллер STM32F407 С шимом проблем нет, в этом плане все работает. Пробовал считывать все порты, во всех случаях вижу только 0xFF. У меня больше подозрений на запуск: HAL_DMA_Start(&hdma_tim4_up, (uint32_t)&PORT_ADC->IDR, &TestDMA[0], 100); Возможно не так запускаю или не то использую. Пробовал так же HAL_DMA_Start_IT(&hdma_tim4_up, (uint32_t)&PORT_ADC->IDR, &TestDMA[0], 100); Результата тоже не дало

Xenia, тактирование и запуск прерываний прописан в MX_DMA_INIT, как и написал HardEgor. static void MX_DMA_Init(void) { /* DMA controller clock enable */ __HAL_RCC_DMA2_CLK_ENABLE(); /* DMA interrupt init */ /* DMA2_Stream5_IRQn interrupt configuration */ HAL_NVIC_SetPriority(DMA2_Stream5_IRQn, 0, 0); HAL_NVIC_EnableIRQ(DMA2_Stream5_IRQn); } Хандлер для их приема тоже автоматически сгенерирован кубом. П.С. Как я уже писал выше, заменил DMA1 на DMA2.

Да вы правы, мне уже подсказали это. И я заменил DMA1 на DMA2, но это не помогло.