-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How can we handle read buffer overflow? #35
Comments
I stepped through with the debugger and it seems that the chip does not panic or hardfault, it gets stuck somewhere in the interrupt routine, however by stepping through, I'm not really able to observe where (very long debug output): cortex_m::interrupt::free<synopsys_usb_otg::bus::{impl#2}::poll::{closure_env#0}<stm32f4xx_hal::otg_fs::USB>, usb_device::bus::PollResult> (f=...)
at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\cortex-m-0.7.7\src/interrupt.rs:64
64 let r = f(unsafe { &CriticalSection::new() });
(gdb) s
Program stopped.
synopsys_usb_otg::bus::{impl#2}::poll::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=0x2001ff9c) at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2\src/bus.rs:579
579 let core_id = read_reg!(otg_global, regs.global(), CID);
(gdb) s
Program stopped.
synopsys_usb_otg::target::UsbRegisters::global (self=0x200013ec <thermometry_ctrl_rust::usb::usb_init::USB_BUS+420>)
at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2/src\target.rs:51
51 unsafe { &*(self.0 as *const _) }
(gdb) s
halted: PC: 0x080042ee
synopsys_usb_otg::bus::{impl#2}::poll::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=0x2001ff9c) at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2\src/bus.rs:579
579 let core_id = read_reg!(otg_global, regs.global(), CID);
(gdb) s
synopsys_usb_otg::ral::register::RWRegister<u32>::read<u32> (self=<optimized out>) at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2/src\ral\register.rs:23
23 unsafe { ::core::ptr::read_volatile(self.register.get()) }
(gdb) s
core::ptr::read_volatile<u32> (src=<optimized out>) at /rustc/88fb1b922b047981fc0cfc62aa1418b4361ae72e/library/core/src/ptr/mod.rs:1552
1552 /rustc/88fb1b922b047981fc0cfc62aa1418b4361ae72e/library/core/src/ptr/mod.rs: No such file or directory.
(gdb) s
halted: PC: 0x080042f2
halted: PC: 0x080042f4
585 if reset != 0 {
(gdb) s
halted: PC: 0x080042f6
halted: PC: 0x080043bc
595 if enum_done != 0 {
(gdb) s
halted: PC: 0x080043be
halted: PC: 0x080043c0
636 } else if wakeup != 0 {
(gdb) s
halted: PC: 0x080043c4
halted: PC: 0x080043c6
641 } else if suspend != 0 {
(gdb) s
halted: PC: 0x080043c8
halted: PC: 0x080043ca
653 if rxflvl != 0 {
(gdb) s
halted: PC: 0x080043cc
halted: PC: 0x0800449a
654 let (epnum, data_size, status) = read_reg!(otg_global, regs.global(), GRXSTSR, EPNUM, BCNT, PKTSTS);
(gdb) s
synopsys_usb_otg::ral::register::RWRegister<u32>::read<u32> (self=0x5000001c) at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2/src\ral\register.rs:23
23 unsafe { ::core::ptr::read_volatile(self.register.get()) }
(gdb) s
core::ptr::read_volatile<u32> (src=0x5000001c) at /rustc/88fb1b922b047981fc0cfc62aa1418b4361ae72e/library/core/src/ptr/mod.rs:1552
1552 /rustc/88fb1b922b047981fc0cfc62aa1418b4361ae72e/library/core/src/ptr/mod.rs: No such file or directory.
(gdb) s
halted: PC: 0x0800449c
synopsys_usb_otg::bus::{impl#2}::poll::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=0x2001ff9c) at C:\Users\ls21y493\.cargo\registry\src\index.crates.io-6f17d22bba15001f\synopsys-usb-otg-0.3.2\src/bus.rs:654
654 let (epnum, data_size, status) = read_reg!(otg_global, regs.global(), GRXSTSR, EPNUM, BCNT, PKTSTS);
|
Actually this crate has an internal buffer that is enough only for usb 1.1 mode which only allows small packets Line 126 in 7331c49
With usb 2.0 packet size can go up to 512 bytes I guess, so just put some bigger number in there (for example 1024) and it would be good (at least helped for me last time I tried) |
Or you can just use |
@AzazKamaz thanks for the input! I am however not sure where I should place this import and/or adjust the buffer in my user-side code? Or would this require a PR / update in the library? |
@hacknus so the easy way to just get it working reliably is to switch to lower speed. It is done on the user side when you init usbd. I'm not really sure if this is available in any of the implementations/mcus, I'm currently using imxrt. I changed it here: https://github.com/imxrt-rs/imxrt-hal/blob/0cb3b8d320e3d2a0e43304f4beca06efba261af1/examples/rtic_usb_serial.rs#L41 I made a patch just for me, maybe will upstream it later, it should fix the issue and get high speed work properly: https://github.com/AzazKamaz/usbd-serial/tree/30b6cff9906be68267fe0960ebfba5b4754c9c80 Also I'm not really sure if after this patch it will be able to act as a full speed device since settings are different... It should in theory do some dynamic configuration |
I have an embedded project on an STM32F405 with USB serial configured and running with FreeRTOS (rust wrapper) as follows:
initialized in the main function like this:
my USB task (stack size 2048) does something like this:
I noticed that the
SerialPort::new(&usb_bus)
doc says: "Creates a new USB serial port with the provided UsbBus and 128 byte read/write buffers.". Whenever I send a message longer than 63 characters, the microcontroller gets stuck and requires a reset. How can I handle this case?The text was updated successfully, but these errors were encountered: