Issue with USB Serial at lower clock speeds
Posted: Thu Jun 16, 2016 5:44 am
Hi,
I'm running into an issue with the serial_usb driver when the system clock speed is set to 32 MHz. I've managed to reproduce it using the following patch to the STM32F4 discovery MEMS demo on the head of the 16.1.x branch:
When you run the command, it will iterate through the characters 0-9 and print 126 copies of each on every line. If you don't include the changes to the clock settings, it works as expected. However, when the clock settings are changed as shown in the patch, I get strange behavior as can be seen in the following output:
As you can see, lines get cut short, iterations get skipped and it also transitions to a different number within the same line. At first I thought that there must be an issue with buffers getting overfilled, but increasing the size of the the USB Serial buffers doesn't seem to alleviate the issue.
Can anyone else reproduce this issue and any thoughts on how I should approach this?
Erick
I'm running into an issue with the serial_usb driver when the system clock speed is set to 32 MHz. I've managed to reproduce it using the following patch to the STM32F4 discovery MEMS demo on the head of the 16.1.x branch:
Code: Select all
---
demos/STM32/RT-STM32F407-DISCOVERY-MEMS/main.c | 14 ++++++++++++++
demos/STM32/RT-STM32F407-DISCOVERY-MEMS/mcuconf.h | 10 +++++-----
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/main.c b/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/main.c
index 1c02f91..2268915 100644
--- a/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/main.c
+++ b/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/main.c
@@ -82,10 +82,24 @@ static void cmd_test(BaseSequentialStream *chp, int argc, char *argv[]) {
chThdWait(tp);
}
+static void cmd_serialDump(BaseSequentialStream *chp, int argc, char *argv[]) {
+ (void)argc;
+ (void)argv;
+ char buf[256] = {0};
+ for (uint32_t i = 0; i < 1024; i++) {
+ for (uint8_t j = 0; j < 126; j++) {
+ char c = (i % 10) + '0';
+ buf[j] = c;
+ }
+ chprintf(chp,"%s\r\n", buf);
+ }
+}
+
static const ShellCommand commands[] = {
{"mem", cmd_mem},
{"threads", cmd_threads},
{"test", cmd_test},
+ {"serialDump", cmd_serialDump},
{NULL, NULL}
};
diff --git a/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/mcuconf.h b/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/mcuconf.h
index 3f21441..b16adb3 100644
--- a/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/mcuconf.h
+++ b/demos/STM32/RT-STM32F407-DISCOVERY-MEMS/mcuconf.h
@@ -45,12 +45,12 @@
#define STM32_SW STM32_SW_PLL
#define STM32_PLLSRC STM32_PLLSRC_HSE
#define STM32_PLLM_VALUE 8
-#define STM32_PLLN_VALUE 336
-#define STM32_PLLP_VALUE 2
-#define STM32_PLLQ_VALUE 7
+#define STM32_PLLN_VALUE 192
+#define STM32_PLLP_VALUE 6
+#define STM32_PLLQ_VALUE 4
#define STM32_HPRE STM32_HPRE_DIV1
-#define STM32_PPRE1 STM32_PPRE1_DIV4
-#define STM32_PPRE2 STM32_PPRE2_DIV2
+#define STM32_PPRE1 STM32_PPRE1_DIV1
+#define STM32_PPRE2 STM32_PPRE2_DIV1
#define STM32_RTCSEL STM32_RTCSEL_LSI
#define STM32_RTCPRE_VALUE 8
#define STM32_MCO1SEL STM32_MCO1SEL_HSI
--
2.8.0When you run the command, it will iterate through the characters 0-9 and print 126 copies of each on every line. If you don't include the changes to the clock settings, it works as expected. However, when the clock settings are changed as shown in the patch, I get strange behavior as can be seen in the following output:
Code: Select all
888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
000000000000000000000000000000000000000000000000033333333333333333333333333333333333333333333333333333333333333333333333333333
444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444
555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777777778888888888888
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333As you can see, lines get cut short, iterations get skipped and it also transitions to a different number within the same line. At first I thought that there must be an issue with buffers getting overfilled, but increasing the size of the the USB Serial buffers doesn't seem to alleviate the issue.
Can anyone else reproduce this issue and any thoughts on how I should approach this?
Erick