STM32L02 USB CDC weird reaction upon sending some characters.

[Electro707]

Hello,

I have an STM32L052K6 running a simple USB CDC class firmware, generated by STM32CubeIDE. I have it as a test setup that if it receives a 'v' character, it responds with a version number of some kind. If I set that version to 16 0xAA's , the device works fine. But if I change that so it sends 16 0xFF's, the device stops responding after a while.

I've been stuck on this for a while, so any help/hints are appreciated.

Included are my main.c, usbd_cdc_if.c.

Also here is a Python program I am using to test this out:

import usb.core
import usb.util
import sys
import time
 
dev = usb.core.find(idVendor=0x0483, idProduct=0x5740)
 
if dev is None:
    print("No Device Found")
    sys.exit(-1)
 
if dev.is_kernel_driver_active(0):
    try:
        dev.detach_kernel_driver(0)
        print("kernel driver detached")
    except usb.core.USBError as e:
        sys.exit("Could not detach kernel driver: ")
else:
    print("no kernel driver attached")
 
dev.set_configuration()
cfg = dev.get_active_configuration()
 
print(cfg[(1, 0)])
 
out_ep = cfg[(1, 0)][0]
in_ep = cfg[(1, 0)][1]
#print(out_ep, in_ep)
 
 
for i in range(10):
    dev.write(0x01, 'v\n')
    ret = dev.read(0x81, 17, 1000)
    print(ret)
    time.sleep(0.5)
 
if not dev.is_kernel_driver_active(0):
    dev.attach_kernel_driver(0)

[Electro707]

UPDATE:

Simply setting the generator's RCC setting from LL to HAL fixed this issue. Now the question becomes why the different generation methods cause drastic differences in performance.

I ran a debug test with a breakpoint right before a while(1) loop, so in theory the RCC, USB, and CRS registers should be the same, but they are not. I have attached the GDB register dump to those who are curious and for future reference.

GDB register dump of RCC LL code:

$2 = {EP0R = 0x0, RESERVED0 = 0x0, EP1R = 0x0, RESERVED1 = 0x0, EP2R = 0x0, RESERVED2 = 0x0, EP3R = 0x0, RESERVED3 = 0x0, EP4R = 0x0, RESERVED4 = 0x0, EP5R = 0x0, RESERVED5 = 0x0, EP6R = 0x0, RESERVED6 = 0x0, EP7R = 0x0, RESERVED7 = {0x0, 0xbf80, 0x0, 0x2f00, 0x0, 0xa54d, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8000, 0x0, 0x0, 0x0}, CNTR = 0xbf80, RESERVED8 = 0x0, ISTR = 0x2f00, RESERVED9 = 0x0, FNR = 0xa54d, RESERVEDA = 0x0, DADDR = 0x0, RESERVEDB = 0x0, BTABLE = 0x0, RESERVEDC = 0x0, LPMCSR = 0x0, RESERVEDD = 0x0, BCDR = 0x8000, RESERVEDE = 0x0}
(gdb) p /x *RCC
$3 = {CR = 0x305, ICSCR = 0x7ab094, CRRCR = 0x7503, CFGR = 0x5, CIER = 0x0, CIFR = 0x0, CICR = 0x0, IOPRSTR = 0x0, AHBRSTR = 0x0, APB2RSTR = 0x0, APB1RSTR = 0x0, IOPENR = 0x1, AHBENR = 0x100, APB2ENR = 0x400001, APB1ENR = 0x10800000, IOPSMENR = 0x8f, AHBSMENR = 0x1111301, APB2SMENR = 0x405225, APB1SMENR = 0xb8e64a11, CCIPR = 0x4000000, CSR = 0xc000000}
(gdb) p /x *CRS
$4 = {CR = 0x2000, CFGR = 0x2022bb7f, ISR = 0x0, ICR = 0x0}

GDB dump of RCC with HAL:

$2 = {EP0R = 0x0, RESERVED0 = 0x0, EP1R = 0x0, RESERVED1 = 0x0, EP2R = 0x0, RESERVED2 = 0x0, EP3R = 0x0, RESERVED3 = 0x0, EP4R = 0x0, RESERVED4 = 0x0, EP5R = 0x0, RESERVED5 = 0x0, EP6R = 0x0, RESERVED6 = 0x0, EP7R = 0x0, RESERVED7 = {0x0, 0xbf80, 0x0, 0xf00, 0x0, 0xb94d, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8000, 0x0, 0x0, 0x0}, CNTR = 0xbf80, RESERVED8 = 0x0, ISTR = 0xf00, RESERVED9 = 0x0, FNR = 0xb94d, RESERVEDA = 0x0, DADDR = 0x0, RESERVEDB = 0x0, BTABLE = 0x0, RESERVEDC = 0x0, LPMCSR = 0x0, RESERVEDD = 0x0, BCDR = 0x8000, RESERVEDE = 0x0}
(gdb) p /x *RCC
$3 = {CR = 0x305, ICSCR = 0x7ab094, CRRCR = 0x7503, CFGR = 0x5, CIER = 0x0, CIFR = 0x0, CICR = 0x0, IOPRSTR = 0x0, AHBRSTR = 0x0, APB2RSTR = 0x0, APB1RSTR = 0x0, IOPENR = 0x1, AHBENR = 0x100, APB2ENR = 0x400001, APB1ENR = 0x18800000, IOPSMENR = 0x8f, AHBSMENR = 0x1111301, APB2SMENR = 0x405225, APB1SMENR = 0xb8e64a11, CCIPR = 0x4000000, CSR = 0xc000000}
(gdb) p /x *CRS
$4 = {CR = 0x2560, CFGR = 0x2022bb7f, ISR = 0x1100020f, ICR = 0x0}