hathach / tinyusb

An open source cross-platform USB stack for embedded system

Home Page:https://www.tinyusb.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 :

  1. clone the TinyUSB repository
  2. move to the latest commit in git (SHA: d10b65a)
  3. open a command prompt
  4. cd to the tools directory
  5. run the get_deps.py using: python .\get_deps.py lpc55
  6. 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 )
  7. 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
  8. Upload the hex file to the LPC55S28 board
  9. 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 :

  1. clone the TinyUSB repository
  2. move to the desired commit in git (SHA: 925ad67)
  3. open a command prompt
  4. cd to the tools directory
  5. run the get_deps.py using: python .\get_deps.py lpc55
  6. 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 )
  7. 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
  8. Upload the hex file to the LPC55S28 board
  9. 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:

  1. 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)

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