LPC55S28 error for High Speed (PORT 1) not working for specific HID examples

[Valentin-Otte]

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: d10b65ada4be7d5754b3128e80a9b4db72bdb23f), ran the _hid_compositefreertos 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_genericinout 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: 925ad67f9794491cb12fe27382e7ea9f60c8dcd3) 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_genericinout 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: 925ad67f9794491cb12fe27382e7ea9f60c8dcd3, example _hid_genericinout ), and there are solved issued regarding the high-speed capability for this board family.
• There's an issue with the _hid_compositefreertos 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_compositefreertos example for high-speed USB on the LPC55S28 board? Is this a known issue for the LPC55S28 and the _hid_compositefreertos 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: d10b65ada4be7d5754b3128e80a9b4db72bdb23f)
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_compositefreertos found at /examples/device/_hid_compositefreertos or _hid_genericinout found at /examples/device/_hid_genericinout )
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: 925ad67f9794491cb12fe27382e7ea9f60c8dcd3)
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_compositefreertos found at /examples/device/_hid_compositefreertos or _hid_genericinout found at /examples/device/_hid_genericinout )
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

• [X] I confirm I have checked existing issues, dicussion and documentation.

[HiFiPhile]

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)

2. 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);

[Valentin-Otte]

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.