[Решено] STM32VL-Discovery Serial1 Recv не работает

Рик Кимбалл
Пн, 07 августа 2017 г., 19:09
Я заметил, что теперь добавлена ​​совет STM32VL-Discovery. Я подарил ему, сериал1.print () кажется хорошим и извергает персонажи. Однако попытка использовать сериал.Vaility () никогда не получает никаких персонажей. Я положил зонд с прицелом на PA10, а напряжение холостого хода - ~ 400 мА. Если я введу символы в терминальную программу, я вижу, как данные поступают. Однако напряжение слишком низкое.

Если я использую один и тот же USB-ключ (CP2102) на плате Nucleo-F030R8 на D2/D8, он показывает правильные уровни сигналов и работает должным образом эхо.

У кого-нибудь еще успел, используя аппаратный Serial1 с доской STM32VL-Discovery?

Вот код, который я использовал: void setup() { Serial1.begin(9600); Serial1.println("Echo type some stuff"); } void loop() { if ( Serial1.available() ) { int c = Serial1.read(); Serial1.write(c); } }

fpistm
Вторник 8 августа 2017 г. 6:36 утра
Привет, Рик,
Как сказано, у меня нет дискотеки STM32VL.
Я только что просмотр кода и последовательное определение кажется правильным (Pinname, PIN -код, номер USART, IRQ,...).
Вы пытались сделать петлю, кстати RX и TX?

Пито
Вторник 8 августа 2017 г. 6:49
Поскольку VL не имеет USB Serial Handy, это может быть, что UART PA9/PA10 является последовательным (не последовательно1).

Рик Кимбалл
Вторник 8 августа 2017 г. 18:34
[Пито - Вторник 8 августа 2017 г. 6:49] - Поскольку VL не имеет USB Serial Handy, это может быть, что UART PA9/PA10 является последовательным (не последовательно1).
Да, он использует PA9/PA10. Я прокомментировал выше, что вывод работает нормально. Это только та сторона приема, которая не работает. Он не заканчивается в IRQ и не верен уровень сигнала.

Чтобы проверить и посмотреть, смогу ли я использовать STM32CubeMX / HAL с этой платой STM32VL, я взял один из примеров STM32Cube для доски STM32VL-Discovery и получил его для компиляции с Eclipse. К сожалению, они не предоставляют ни проект GCC Makefile, ни проект SWS4STM32 для любого из примеров STM32VL. Я просто прошел через это и получил демонстрационное приложение uart_hypermerminal_dma для компиляции и загрузки. И да, это работает нормально. Он отправляет и получает должным образом, а уровни сигнала на выводах - это то, чего я ожидал.

Я предполагаю, что вариант совета директоров STM32VL-раскрытия в ядре STM32 является источником проблемы. Это я вышел после того, как попробовал недавно полученную плату Nucleo-F103RB, которая отлично работает с тем же USB-ключом, что и с STM32VL-Discovery. Который использует тот же код ядра F1 (UART.C / Hardwareserial.CPP) вещи. Я в основном ставил эту проблему, чтобы ребята св.

fpistm
Ср. 09 августа 2017 г. 20:29
Я думаю, что проблема возникает в HAL для F1. Я скоро выпущу обновление F1 HAL с UART обновленным.
Вот почему это, вероятно, работает с Cubemx.

fpistm
Чт 10 августа 2017 г. 15:05
Обновление F1 доступно в этом PR:
https: // github.com/stm32duino/arduino_c ... 32/тяга/78

Рик Кимбалл
Пт 11 августа 2017 г., 19:55
[fpistm - Ср. 09 августа 2017 20:29] - Я думаю, что проблема возникает в HAL для F1. Я скоро выпущу обновление F1 HAL с UART обновленным.
Вот почему это, вероятно, работает с Cubemx.
Я попробовал вашу последнюю регистрацию, и это ничего не изменило в лучшую сторону. VL-доска STM32F100RB по-прежнему нарушается в отношении последовательного ввода.

fpistm
Пт 11 августа 2017 г., 19:58
:плакать:
Хорошо. Спасибо за тест. Я постараюсь получить vldisco, чтобы отладить эту проблему. Может быть, конкретная часть для F100 в HAL.

Рик Кимбалл
Чт 17 августа 2017 г., 19:33
Хорошо, я потратил кучу времени, глядя на это, пытаясь выяснить, почему получение не работает для STM32VL-Discovery.

Я сравнил nucelo_f103rb с вариантами Disco_F100RB. Я сосредоточился на том, чтобы просто попытаться заставить работу PA2/PA3.
Я заметил, что в F103 есть PA2/PA3, прокомментированный из всех таблиц, кроме UART, поэтому я изменил F100, чтобы сделать то же самое. Это ничего не исправляло, без изменений.

Я провел в чрезвычайном времени в отладке, проверяя, что USART2_IRQHandler работает. Это всегда работает на
Получите на F103, но никогда не работает на F100. Обе чипы запускают USART2_IRQHandler при передаче символов.
Я в растерянности, потому что я не очень хорошо знаю код hal_uart. Мой единственный комментарий будет, почему существует так много государственных переменных, связанных с состоянием устройства, вместо того, чтобы просто использовать аппаратные регистры USART, чтобы решить, что происходит.

Код для UART.C кажется таким же для F100 и F103. Я не уверен, на что еще смотреть.

Код создает и соответствующий обработчик USART IRQ. Код запускает обработчик IRQ, по крайней мере, для передачи. Код HAL слишком сложный и скрывает то, что происходит до такой степени, что я не могу его отладить.

В качестве другой точки данных BluePill в ветви F1_Merge_other проявляет ту же проблему. Так что я не думаю, что это конкретно проблема F100.
Кроме того, я могу использовать ту же доску VL-Discovery с ядром STM32Duino/Libmaple и тому же .INO -файл, и он работает нормально.

@fpistm вы делаете какие -либо прогресс в этом? Я надеюсь, что если вы поймете это, вы также сможете обеспечить то же самое для Bluepill.

fpistm
Чт 17 августа 2017 г., 8:10 вечера
В настоящее время не Рик : oops:
Я пытаюсь получить vldisco. Но, как вы сказали, есть та же проблема на BP. Я сосредоточусь на этом.
Спасибо за ваше время, чтобы попробовать отладить эту проблему.
Поддерживать связь

fpistm
Пт 18 августа 2017 г. 8:55 утра
Рик, не могли бы вы проверить, добавив Uart.в, Функция: void uart_init (serial_t *obj) В // настройка части UART
huart->gState = HAL_UART_STATE_RESET;

Рик Кимбалл
Пт 18 августа 2017 г. 11:37
Я попробовал это ... Нет разницы.

В качестве еще одной точки данных, я вошел в отладчик, и до того, как я добавил строку, он уже был установлен на HAL_UART_STATE_RESET
Breakpoint 3, uart_init (obj=obj@entry=0x20000218 ) at /home/kimballr/Arduino/hardware/st/stm32/cores/arduino/stm32/uart.c:248 248 huart->Init.OverSampling = UART_OVERSAMPLING_16; (gdb) l 243 huart->Init.WordLength = obj->databits; 244 huart->Init.StopBits = obj->stopbits; 245 huart->Init.Parity = obj->parity; 246 huart->Init.Mode = UART_MODE_TX_RX; 247 huart->Init.HwFlowCtl = UART_HWCONTROL_NONE; 248 huart->Init.OverSampling = UART_OVERSAMPLING_16; 249 // huart->Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE; 250 huart->gState = HAL_UART_STATE_RESET; 251 252 if(HAL_UART_Init(huart) != HAL_OK) { (gdb) p/x huart->gState $9 = 0x0 (gdb) p huart->gState $10 = HAL_UART_STATE_RESET (gdb) n 250 huart->gState = HAL_UART_STATE_RESET; (gdb) n 252 if(HAL_UART_Init(huart) != HAL_OK) { (gdb) p huart->gState $11 = HAL_UART_STATE_RESET (gdb) p/x huart->gState $12 = 0x0 (gdb) p *huart $13 = {Instance = 0x40004400, Init = {BaudRate = 9600, WordLength = 0, StopBits = 0, Parity = 0, Mode = 12, HwFlowCtl = 0, OverSampling = 0}, pTxBuffPtr = 0x0, TxXferSize = 0, TxXferCount = 0, pRxBuffPtr = 0x0, RxXferSize = 0, RxXferCount = 0, hdmatx = 0x0, hdmarx = 0x0, Lock = HAL_UNLOCKED, gState = HAL_UART_STATE_RESET, RxState = HAL_UART_STATE_RESET, ErrorCode = 0}

fpistm
Пт 18 августа 2017 12:13
Я думаю, что это было так, как компилятор, все до 0 (= hal_uart_state_reset)
Спасибо за тест. Я попробую с BP, я переусердствовал PR, чтобы я мог проверить.

fpistm
Солнце 20 августа 2017 г. 9:31
Проблема поступает от конфигурации GPIO для PIN UART RX.
Для F1 он должен быть настроен как STM_MODE_INPUT

Рик Кимбалл
Солнце 20 августа 2017 14:40
Просто, чтобы быть ясным, эта проблема не исправлена ​​в текущем мастере только в вашем частном репо/филиале, да?

https: // github.com/fpistm/arduino_core_ ... mits/f1_af

fpistm
Sun 20 августа 2017 г. 15:06
Да, Рик, я жду комментариев fprwi6labs, если таковые имеются, прежде чем слияние ;)