LPC55S28 error for High Speed (PORT 1) not working for specific HID examples
Valentin-Otte opened this issue · comments
Operating System
Windows 11
Board
LPC55S28
Firmware
For the tests, we used the following examples found in the tiny-USB examples folder in the device section:
- hid_composite_freertos
- hid_generic_inout
What happened ?
We were interested in testing the HID+RTOS feature for the LPC55S28 board. To do this, we first used the latest version of tiny-USB (SHA: d10b65a), ran the hid_composite_freertos example and had the following results:
- Compiled the firmware image for full-speed USB (PORT==0) and loaded it on the LPC55S28; this worked as expected, appearing as an HID device in the Windows device manager.
- Compiled the firmware image for high-speed USB (PORT==1) and loaded it on the LPC55S28; this didn't work; it couldn't be found as an HID device, and there was no USB connection sound cue.
To verify that this wasn't an HID issue, we tried testing with the hid_generic_inout example, but a dependency issue prevented us from building it for this board.
As a precaution, we also tried the same test with a previous version of tiny-USB (SHA: 925ad67) and got the following results:
- Compiled the firmware image for full-speed USB (PORT==0) and loaded it on the LPC55S28; this worked as expected, appearing as an HID device in the Windows device manager.
- Compiled the firmware image for high-speed USB (PORT==1) and loaded it on the LPC55S28; this didn't work; it couldn't be found as an HID device, and there was no USB connection sound cue.
Again, to verify that this wasn't an HID issue, we tried testing with the hid_generic_inout example and got the following results:
- Compiled the firmware image for full-speed USB (PORT==0) and loaded it on the LPC55S28; this worked as expected, appearing as an HID device in the Windows device manager and responding to the messages sent by the Python example (hid_test.py).
- Compiled the firmware image for full-speed USB (PORT==1) and loaded it on the LPC55S28; this worked as expected, appearing as an HID device in the Windows device manager and responding to the messages sent by the Python example (hid_test.py).
Given these tests, we conclude that:
- HID should work as expected since there is a version that allows us to test the HID capability by itself successfully (SHA: 925ad67, example hid_generic_inout ), and there are solved issued regarding the high-speed capability for this board family.
- There's an issue with the hid_composite_freertos example that doesn't allow high-speed USB+RTOS+HID. I couldn't find any issues regarding this, and it seems to be one that happened in previous versions of Tiny-USB.
Is there a known version that could allow us to test the hid_composite_freertos example for high-speed USB on the LPC55S28 board?
Is this a known issue for the LPC55S28 and the hid_composite_freertos example? If so, what could be the source of it?
How to reproduce ?
For the latest master version test :
- clone the TinyUSB repository
- move to the latest commit in git (SHA: d10b65a)
- open a command prompt
- cd to the tools directory
- run the get_deps.py using:
python .\get_deps.py lpc55
- cd to the desired example subfolder ( hid_composite_freertos found at /examples/device/hid_composite_freertos or hid_generic_inout found at /examples/device/hid_generic_inout )
- build the application using make for the lpcxpresso55s28 board and desired port (full speed =0 or high speed = 1): make -r BOARD=lpcxpresso55s28 PORT=1 all
- Upload the hex file to the LPC55S28 board
- test the correct USB connection
These steps are shared for both examples; the tests we did and the results we got are the ones previously described in the "What happened?" section.
For the previous version test :
- clone the TinyUSB repository
- move to the desired commit in git (SHA: 925ad67)
- open a command prompt
- cd to the tools directory
- run the get_deps.py using:
python .\get_deps.py lpc55
- cd to the desired example subfolder ( hid_composite_freertos found at /examples/device/hid_composite_freertos or hid_generic_inout found at /examples/device/hid_generic_inout )
- build the application using make for the lpcxpresso55s28 board and desired port (full speed =0 or high speed = 1): make -r BOARD=lpcxpresso55s28 PORT=1 all
- Upload the hex file to the LPC55S28 board
- test the correct USB connection
These steps are shared for both examples; the tests we did and the results we got are the ones previously described in the "What happened?" section.
Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)
n.a
Screenshots
No response
I have checked existing issues, dicussion and documentation
- I confirm I have checked existing issues, dicussion and documentation.
There are 2 issues:
- FreeRTOS not supported by BSP:
In tinyusb/hw/bsp/lpc55/family.c
you can try to replace SysTick_Config(SystemCoreClock / 1000);
with
#if CFG_TUSB_OS == OPT_OS_NONE
// 1ms tick timer
SysTick_Config(SystemCoreClock / 1000);
#elif CFG_TUSB_OS == OPT_OS_FREERTOS
// If freeRTOS is used, IRQ priority is limit by max syscall ( smaller is higher )
NVIC_SetPriority(USB0_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY );
NVIC_SetPriority(USB1_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY );
#endif
Add #define configRUN_FREERTOS_SECURE_ONLY 1
in src/FreeRTOSConfig/FreeRTOSConfig.h
. (need evaluation to see any negative effects on other ports)
- Potentially USB RAM alignment issue (ref. https://community.nxp.com/t5/LPC-Microcontrollers/USB-and-newlib/m-p/1312833#M45952)
Happend with arm-none-eabi-gcc 12.2 newlib, I mainly use IAR which is not affected.
Add MPU config to allow unaligned access:
ARM_MPU_SetMemAttr(0, 0x44); // Normal memory, non-cacheable (inner and outer)
ARM_MPU_SetRegion(0, ARM_MPU_RBAR(0x40100000, ARM_MPU_SH_NON, 0, 1, 1), ARM_MPU_RLAR(0x40104000, 0));
ARM_MPU_Enable(MPU_CTRL_PRIVDEFENA_Msk | MPU_CTRL_HFNMIENA_Msk);
Thank you for the quick response, and I am sorry for the delay. There was no RAM alignment issue, simply with the first suggestion the example worked as expected. Depending on the selected USB port, I added some extra code to set the specific NVIC_SetPriority.
Again, thank you for your help! I'll close this issue.