See if below application notes helps or not:

http://www.silabs.com/documents/public/application-notes/AN534.pdf

http://www.silabs.com/documents/public/example-code/an534sw.zip

http://www.silabs.com/documents/public/application-notes/AN533.pdf

Hi Rasem,

We do have a more complex example showing a device bootloader using the CAN interface. I've linked the relevant text and code below.

The main point of interest is the F50x_CAN.c file in both Target_BL_FW/ and Master_BL_FW/ . These show how to init the CAN module for both receive and transmit, as well as handling multiple interrupt types.

AN text:

http://www.silabs.com/documents/public/application-notes/AN534.pdf

AN code:

http://www.silabs.com/documents/public/example-code/an534sw.zip

Another AN with some context on the bootloader code:

http://www.silabs.com/documents/public/application-notes/AN533.pdf

Best,

David

Hey Rolf! 

I am able to use the driver as is successfully in mac os 10.15.4 (refer to my screenshots above) and I am able to communicate with a CP210x device. I am unsure of the product you're using(since it is a third party device) and there could be issues with that. The driver on 10.15.4 should work as expected. I also recommend moving your question to a new forum post since Rob's original question on this post has already been answered. 

Silicon Labs sells CP21xx USB bridge devices to product manufacturers for use in end-customer products. Silicon Labs provides reference drivers primarily for development purposes. Product manufacturers are expected to customize/productize the CP21xx device and reference driver for their product.

Silicon Labs does not support end customers directly. Please contact your product manufacturer for support. They can always reach out to us for support is required from our end. 

You're welcome, Derek. 

I am glad you were able to use a workaround that suited your application. 

Hi Derek,

I heard back from our developers and it looks like you have come across a race condition that exists both in hardware and software and normally these are very difficult to reproduce, debug and fix. There are no caveats to using the USBD_AbortTransfer function, so what you were doing is technically correct. I will be creating an internal ticket with out development team to add a timeout into the USBD_AbortTransfer function and to investigate if the functions are safe to call when there is nothing to abort. I am not sure when this ticket will be scheduled and when the fix will be released. 

Meanwhile, can you use USBD_AbortAllTransfer function? You could also add a timeout in the USBD_AbortTransfer function too. 

Dear sir,

In one of our product, we are using SI445 transceiver. Kindly provide C driver code to integrate with STM8/STM32 MCU.

Best Regards,

Sheela

The config wizard is a legacy tool and we intend to support the hardware configurator for 8-bit devices going forward. Can you tell me what is not clear in the hardware configurator? I can pass along your feedback to our developers. 

Hi Derek,

Thanks for the additional information. I am talking to our developers to figure out why there is no timeout in the abortTransfer function and will get back to you once I hear from them. 

You mentioned that you were using SDK v2.7. The latest version is v2.7.5 (MCU - 5.9.5.0). Can you try this on the latest version of the SDK and let me know if you still see the same issue? 

Thanks! 

Hello Rob,

I reached out to our developers with this question. This is “normal” behavior under the latest version of MacOS X.

The reason why you are now seeing this message is that Apple is referring to Kernel Extension(kext) based Device Drivers as “legacy” extensions. Under Catalina it is possible to use a Device Extension (DEXT) which is Apple’s new API for USB extensions and other kinds of device drivers. Apple is showing this message to users to give developers a warning that in the next version of MacOS X they probably won’t allow kernel extensions to load at all and also to get users to inform developers to rewrite their drivers using Device Kit.

You're welcome, Rob. 

It is on our roadmap to migrate to device extension based drivers. I don't have a schedule for it, but we intend to support future OSes of Mac as well.