Hi Artem,

Can you check the reset source register to determine what kind of reset is occurring during this event?

Thanks,

Brian

Hi Albert,

Source for the Linux CP2110 libraries is available in the Linux download here: https://www.silabs.com/products/development-tools/software/interface#software

The source is available under CP2110_4/srcpkg for slabhiddevice and slabhidtouart libraries that are used with a CP2110 device.

There are also prebuilt libraries for "ARM7" under the CP2110_4/lib/arm7 directory that may work for you.

-Brian

Hi Lei Wang,

There's a function called "CP210x_GetFirmwareVersion" in the CP210x Manufacturing Library that can do what you want:

/// @brief Reads and returns the Firmware Version from the  device
///
/// @param[in] cyHandle is an open handle to the device
/// @param[out] lpVersion points to a buffer into which the Firmware Version will be written
///
/// @returns Returns #CP210x_SUCCESS on success, or another @ref CP210x_STATUS Return value if there is an error.
///	@retval	#CP210x_SUCCESS -- success
///	@retval	#CP210x_INVALID_HANDLE -- cyHandle is invalid
///	@retval	#CP210x_INVALID_PARAMETER -- lpVersion is an unexpected value
///	@retval	#CP210x_FUNCTION_NOT_SUPPORTED -- the device does not support reporting its Firmware Version
///	@retval	#CP210x_DEVICE_IO_FAILED -- the device failed to respond to I/O in any expected manner
_Check_return_
_Ret_range_(CP210x_SUCCESS, CP210x_DEVICE_NOT_FOUND)
_Success_(return == CP210x_SUCCESS)
CP210xDLL_API CP210x_STATUS WINAPI
CP210x_GetFirmwareVersion(
	_In_ _Pre_defensive_ const HANDLE cyHandle,
	_Out_writes_bytes_(sizeof(firmware_t)) _Pre_defensive_ pFirmware_t lpVersion
	);

Firmware version 1.0.4 or 1.0.2 = A01. 1.0.8 = A02

Hi Lei Wang,

There's a function called "CP210x_GetFirmwareVersion" that can do what you want:

/// @brief Reads and returns the Firmware Version from the  device
///
/// @param[in] cyHandle is an open handle to the device
/// @param[out] lpVersion points to a buffer into which the Firmware Version will be written
///
/// @returns Returns #CP210x_SUCCESS on success, or another @ref CP210x_STATUS Return value if there is an error.
///	@retval	#CP210x_SUCCESS -- success
///	@retval	#CP210x_INVALID_HANDLE -- cyHandle is invalid
///	@retval	#CP210x_INVALID_PARAMETER -- lpVersion is an unexpected value
///	@retval	#CP210x_FUNCTION_NOT_SUPPORTED -- the device does not support reporting its Firmware Version
///	@retval	#CP210x_DEVICE_IO_FAILED -- the device failed to respond to I/O in any expected manner
_Check_return_
_Ret_range_(CP210x_SUCCESS, CP210x_DEVICE_NOT_FOUND)
_Success_(return == CP210x_SUCCESS)
CP210xDLL_API CP210x_STATUS WINAPI
CP210x_GetFirmwareVersion(
	_In_ _Pre_defensive_ const HANDLE cyHandle,
	_Out_writes_bytes_(sizeof(firmware_t)) _Pre_defensive_ pFirmware_t lpVersion
	);

Firmware version 1.0.4 or 1.0.2 = A01. 1.0.8 = A02

Hi, we're connecting a device using the CP210x USB UART bridge. We're using a Win10 computer, up-to-date.

The device connects to the PC with USB.

We've installed the driver found on SIlicon Labs web site.

When trying to exchange with the device we (apparently) can send data (ENQ) but we then wait for a ACK we never receive. Either the ENQ wasn't actually sent or the driver can't return the answer, but we never can read from the device.

Does the driver CP210 USB UART bridge actually work under Win10 or not ?

We've been told the device works with WinXP ( :D ) but we all have the same problem with Win10.

Anybody has a clue ?

Hi Alex,

You should be able to erase the device, even if the debug interface is not routed out (in the case where the UART was switched to the debug pins) using Simplicity Commander here: https://www.silabs.com/products/mcu/programming-options#programming

Use the following command:

commander device recover

More info: https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

Hi Sinisa,

On devices with a flash prefetch engine, the instruction execution time may actually be less than the maximum based on where the jump/destination addresses are located (if they're on a particular address boundary). So, 6 cycles may be the absolute worst case if the instruction is at a non-optimal address. This article has more information: https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2016/10/07/branch_instructionv-wJQ1

-Brian

Hello,

I am running into trouble while trying to add the NCP serial interface to a DMP application.

I started off with the SOC - Empty - RAIL - DMP example.
I tried adding the the NCP interface (BGApi?) on USART2 to the example.

I ran into problems due to the ncp_gecko.h and rtos_gecko.h overlapping.
I managed to somewhat manage to work around that, but it does not work as expected.

The serial communication is working as such, but I neither get the boot event,
nor the correct responses when running commands.

When sending the system_get_bt_address command (0x20 0x00 0x01 0x03) using HTerm,
for example get the response 0x20 0x02 0x01 0x03 0x83 0x01 instead of the expected response.

I was trying to merge the ncp-empty-target and DMP examples in order to control the Bluetooth from a host IPC.
Is there an easier solution on how to correctly add the NCP functionality to the SOC - Empty - RAIL - DMP example?