Thanks for your help!!

Finally I figured it out on my own (at least it is working as I want...).

What I've done:

• Remove USBDESC_strings completely from descriptor (all other description like class, endpoint and so on are still in the description file.
• Create the langID, Manuf and Prod string in my usbprotocol file.
• In my initialisation method, I change the value of the serialnumber string to the one collected from userData

void* USBDESC_Strings[4];

static const USBD_Callbacks_TypeDef callbacks =
{
    .usbReset       = NULL,
    .usbStateChange = CDC_StateChangeEvent,
    .setupCmd       = CDC_SetupCmd,
    .isSelfPowered  = NULL,
    .sofInt         = NULL
};

static const USBD_Init_TypeDef usbInitStruct = 
{
    .deviceDescriptor       = &USBDESC_deviceDesc,
    .configDescriptor       = USBDESC_configDesc,
    .stringDescriptors      = USBDESC_Strings,
    .numberOfStrings        = sizeof(USBDESC_Strings) / sizeof(void*),
    .callbacks              = &callbacks,
    .bufferingMultiplier    = USBDESC_bufferingMultiplier,
    .reserved               = 0
};

SL_PACK_START(1)
typedef struct
{
    uint8_t  len;
    uint8_t  type;
    char16_t name[1 + sizeof((char16_t[]){'0', '0', '0', '0', '0', '0'}) / 2];
} SL_ATTRIBUTE_PACKED _serialNumberStringStruct;
SL_PACK_END()
SL_ALIGN(4)
SL_PACK_START(1)
_serialNumberStringStruct _serialNumberString SL_ATTRIBUTE_ALIGN(4);
SL_PACK_END()
  
STATIC_CONST_STRING_DESC_LANGID(langID, 0x04, 0x09);
STATIC_CONST_STRING_DESC(iManufacturer, 'M', 'a', 'n', 'u', 'f', 'S', 't', 'r', 'i', 'n', 'g');
STATIC_CONST_STRING_DESC(iProduct, 'P', 'r', 'o', 'd', 'S', 't', 'r', 'i', 'n', 'g');

/*******************************************************************************
DECLARATIONS
*******************************************************************************/
/**
  * @brief  Initialization of USBProtocol module
  * @param  None
  * @retval None
  */
void USBPROTOCOL_Init(void)
{
    /* Set new serial number */
    _serialNumberString.len = sizeof(_serialNumberStringStruct) - 2;
    _serialNumberString.type = USB_STRING_DESCRIPTOR;
    _serialNumberString.name[0] = '0';
    _serialNumberString.name[1] = '1';
    _serialNumberString.name[2] = '4';
    _serialNumberString.name[3] = '0';
    _serialNumberString.name[4] = '1';
    _serialNumberString.name[5] = '5';
    _serialNumberString.name[((sizeof(_serialNumberStringStruct) - 2) / 2) - 1] = '\0';
    
    USBDESC_Strings[0] = (void*)&langID;
    USBDESC_Strings[1] = (void*)&iManufacturer;
    USBDESC_Strings[2] = (void*)&iProduct;
    USBDESC_Strings[3] = (void*)&_serialNumberString;

    /* Initialise & Connect USB */
    USBD_Init(&usbInitStruct);
    USBD_Connect();
}

Now when I connect the EFM running my bootloader firmware, it shows exactly what I want...

When I have already this topic open, a short side-question. If you want that I open a new one, please let me know, if not, here is (hopefully) my last question regarding USB...

We are using the VendorID and obtained a ProdID from Silabs.

When I connect the EFM to my host machine (at the moment Windows) and I open the device manager, my COM Port is just called "USB Serial Device (COM24)". Is there any possibility that WIndows is recognising my product name or something like that as a visualisation inside the device manager?

Please try a new post. 

I think others may also interested in your new question.

Thanks for quick reply.

I haven't try this yet. 

But  a quick thought on this is that it is possible if you are ok to change the descriptor file.

Since current serial number string and its pointer are located in flash (const ), i think you could seek some pragma (like at) to relocate the pointer and string to the user data flash  region.

I encourage you search via Googleto see how to use that kind of pragma.

What toolchain you are using, keil, iar or gnu?

Thanks for quick reply.

I haven't try this yet. 

But  a quick thought on this is that it is possible if you are ok to change the descriptor file.

Since current serial number string and its pointer are located in flash (const ), i think you could seek some pragma (like at) to relocate the pointer and string to the user data flash  region.

I encourage you search via Googleto see how to use that kind of pragma.

What toolchain you are using, keil, iar or gun?

Thanks for quick reply.

I haven't try this yet. 

But  a quick thought on this is it is possible if you are ok to change the descriptor file.

Since current serial number string and its pointer are located in flash (const ), i think you could seek some pragma (like at) to relocate the pointer and string to the user data flash  region.

I encourage you search via Googleto see how to use that kind of pragma.

What toolchain you are using, keil, iar or gun?

Thanks for quick reply.

I haven't try this yet. 

But i a quick thought on it is possible if you are on to change the descriptor file.

Since current serial number string and its pointer are located in flash (const ), i think you could seek some pragma (like at) to relocate the pointer and string to the user data flash  region.

I encourage you search via Googleto see how to use that kind of pragma.

What toolchain you are using, keil, iar or gun?

Yes, there is conflict if both the JLink CDC and external USB-2-UART try to communicate with the UART0 (Bootloader use that) of EFM8.

both external and JLink VCOM could receive, but they will try to control the RX pin of EFM8 UART0.

That's the reason you see abnormal phenomenon.

I noticed that once it enters the bootloader, it holds the RX pin, I mean: it looks RX pin is set to output because my TX device cannot set it to low.

Yes, there is conflict if both the JLink CDC and external USB-2-UART try to communicate with the UART0 (Bootloader use that) of EFM8.

both external and JLink VCOM could receive, but they will try to control the RX pin of EFM8 UART0.

That's the reason you see abnormal phenomenon.

I noticed that once it enters the bootloader, it holds the RX pin, I mean: it looks RX pin is set to output because my TX device cannot set it to low.

So you are ok to made change like the descriptor.c file.

You are reluctant to made any change on the Silabs Gecko USB lib (file in folder usb_gecko),

right?

I need to re-think this requirement.

Try the bootloader for the STK. I am wondering if the pre-build binary image should work for the STK or not.

or image in folder \AN945SW\StarterKitHexfiles after unzip the AN945 package.