Issue with USB Serial at lower clock speeds

[efuentes]

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:

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.0

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:

Code: Select all

888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
000000000000000000000000000000000000000000000000033333333333333333333333333333333333333333333333333333333333333333333333333333
444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444
555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666
77777777777777777777777777777777777777777777777778888888888888
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222
333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333

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

[Giovanni]

Hi,

Please verify on the STM32 Reference Manual if there are constraints on the AHB frequency, some peripheral require a minimum frequency.

Giovanni

[efuentes]

Just to do a quick sanity check, here is the math on the clock frequencies:
XTAL Frequency = 8 MHz
PLLVCO Frequency = XTAL * PLLN/PLLM = 8 * 192 / 8 = 192 MHz (Must be > 100 MHz and < 432 MHz)
SYSCLK Frequency = PLLVCO / PLLP = 192 / 6 = 32 MHz
USBCLK Frequency = PLLVCO / PLLQ = 192 / 4 = 48 MHz (Must be 48 MHz)
AHBCLK = SYSCLK / STM32_HPRE = 32 / 1 = 32 MHz
APB1CLK = AHBCLK / STM32_PPRE1 = 32 / 1 = 32 MHz
AHB2CLK = AHBCLK / STM32_PPRE2 = 32 / 1 = 32 MHz

This seems to check out to me. I took a look through the reference manual and I found the following restrictions on AHB frequency:
- Must be less than 168 MHz
- Must be > 14.2 MHz to use OTG_FS
- Must be > 30 MHz to use OTG_HS
- Must be > 25 MHz to use Ethernet

The only other thing that I saw that is worth mentioning is that they recommend that XTAL / PLLM to be between 1 and 2 MHz with 2 MHz being preferred to reduce jitter. I'll try that out and see if there are any improvements.

Erick