Also see:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/09/12/etm_and_itm_swo_tr-VB56

The MAX13235E transceiver on the CP2102N-EK will not transmit the first bits of data if left idle for more than 30s.

The MAX13235E transceiver on TXD enters AutoShutdown Plus mode after 30s of inactivity on the data bus. Exiting the mode requires a transition edge. The transceiver takes ~40uS to return to normal operation. This will cause incorrect data on the RS-232 side of the transceiver.

To workaround this issue, place the MAX13235E in always-on mode by moving the 1KOhm resistor at R13 to R23. 

Hi Ralf,

Thank you for your inquiry about re-establishing a connection between two BGX modules.  I wanted to let you know that the feature you are requesting is being considered for an upcoming firmware release that is scheduled for sometime around September.  I recommend that you check back around that time and stay tuned for the update.

In the meantime, if you know the specific address of the device you are trying to re-connect to, you can do this with current firmware with the "con {MAC_ADDR}" command.

I hope this helps.  Please let me know if you have any questions.

Regards,

Mitch

Hi TimEcc,

Thank you for sharing this information about your USB packet analyzer that utilizes a CP2130 to interface to the analysis computer.  Perhaps you would like to create a post about this project in our "Projects" section of this community website at the following location:

https://www.silabs.com/community/projects

Thanks!

Regards,

Mitch

Hello,

Thank you for your inquiry  regarding the BGM111 ADC.  I have a couple tips and suggestions to help get this issue resolved:

First, the error you are seeing in the expressions window of the debugger is likely due to compiler optimization (-O2 by default) levels causing the static inline function to be inserted inline in the actual machine code generated.  If this is the case, then the parameter "adc" is actually not implemented and will not show up there.  If you change your optimization to -O0, you should be able to view the adc parameter as an expression.

I found this external forum post relating to this topic which may provide additional details about this topic:

https://stackoverflow.com/questions/47819719/static-inline-functions-in-a-header-file

As for the actual behavior of the ADC, I recommend having a look at our simple adc_single_polled peripheral example for the EFR32BG1 ADC (BRD4100A_EFR32BG1P_adc_single_polled.slsproj) and using this as a template for operating the BGM111 ADC.  The code should be portable between the devices with minimal changes if any.  You can find this and other ADC projects in our peripheral examples GitHub repository:

https://github.com/SiliconLabs/peripheral_examples/tree/public/adc/adc_single_polled

https://github.com/SiliconLabs/peripheral_examples

Finally, can you describe in more detail what you are expecting to observe with regard to your ADC setup and measurement, what your actual observations are,  and how your actual observations differ form what is expected?

Thank you, and I hope this helps.

Regards,

Mitch

Hi superpanda,

Thank you for your inquiry about the PCNT.  Can you please specify which device you are using?

In referring to the Series 1 reference manual PCNT section, it appears as if this may be expected behavior, given that you are running the PCNT in EXTCLKSINGLE mode with the clocking input signal on your PCNT0_S0IN pin:

"When the RSTEN bit in the PCNTn_CTRL register is set, the PCNT clock domain is asynchronously held in reset. The reset is synchronously
released two PCNT clock edges after the RSTEN bit in the PCNTn_CTRL register is cleared by software. This asynchronous
reset restores the reset values in PCNTn_TOP, PCNTn_CNT and other control registers in the PCNT clock domain." (EFR32xG12 reference manual, section 16.3.5 Register Access, page 477)

The function PCNT_CounterReset() indeed sets the RSTEN bit and then clears it, so a 2 PCNT clock edge delay before the PCNT clock domain is released from reset.

Please let me know what device you are using in case this affects the applicability of this information to your case.  Thank you.

Regards,

Mitch

Hi Jack,

As an addendum to John's answer, please note that if you are interested in extracting the device revision information, you can get this information as described in section 3.6 Device Revision on page 9 of EFM32HG reference manual.

Regards,

Mitch

Hi Fred,

Thank you for your inquiry regarding installing the CP210x VCP driver v5.0.10 on iMac with Mojave 10.14.4.  I have a couple questions and suggestions:

1) Have you tried all the suggestions from the driver release notes (https://www.silabs.com/documents/public/release-notes/Mac_OSX_VCP_Driver_Release_Notes.txt):

Mount the DMG file and double click on 
	Silicon Labs VCP Driver. 
	On MacOS 10.13 and later, the installation of the driver may be blocked. 
	To unblock, open the System Preferences Security & Privacy pane and
	unblock the system extension. See Apple Technical Note TN2459
	"User-Approved Kernel Extension Loading" for more information.

2) Here are some commands that may help troubleshoot the problem (note that I can see you already did some of these):

kextload This command loads a kext. You can use it like this:
sudo kextload SiLabsUSBDriver.kext

kextutil This command does the same thing as kextload, but will print out debugging information.

kextunload This command unloads a kext if possible.

kextstat Shows a list of loaded kernel extensions.

3) Can you please check the VID/PID of the device you are using. You can see that by using the System Information app which you can access from Apple menu "About this Mac" and then click the button labeled "System Report…". Then click "USB" in the lefthand list under "Hardware". This will show the USB device tree. Click your device and it will show various information about the device.

I hope this helps.  Please let me know if you have any questions.

Regards,

Mitch

The I2C needs software interaction during the transfer. But you can move the call to I2C_Transfer() to the interrupt routine and stay in EM1 during the transfer. The I2C_Transfer() function takes care of all the I2C interrupt flags so all you need to do is to enable the I2C interrupts in NVIC. 

Define a status flag and the interrupt routine: 

volatile I2C_TransferReturn_TypeDef transferStatus;

void I2C0_IRQHandler(void)
{
  transferStatus = I2C_Transfer(I2C0);
}

In your transfer function, enable the I2C interrupt in NVIC during the transfer and enter EM1 instead of polling. 

NVIC_EnableIRQ(I2C0_IRQn);
transferStatus = I2C_TransferInit(I2C0, seq);
while (transferStatus == i2cTransferInProgress && timeout--)
{
  EMU_EnterEM1();
}
NVIC_DisableIRQ(I2C0_IRQn);