Hi LB,

Thank you for your inquiry about the toolstick terminal application.  Unfortunately, there is no Linux version of this application.  I am not sure whether this can be run in Wine, but it is worth a shot.  Sometimes emulator programs can have problems when an application has to access computer hardware such as USB which would be required in this case.  Still, my recommendation is to give it a try.

If you can not run the Toolstick Terminal in the Wine emulator, I suggest using the CP2102N USB to UART bridge, which should run natively in Linux as a virtual COM port.  This will allow you to connect the LCK UART TX and RX signals to the CP2102N (CP2102N-EK) and perform serial communications to a normal terminal in Linux via the virtual COM port.  More information on the CP2102N-EK can be found here:

https://www.silabs.com/development-tools/interface/cp2102n-development-kit

I hope this helps.

Regards,

Mitch

Hi Lee,

Thank you for this bug report.  I have verified that the list of CLU3B inputs in Simplicity Studio v5 does not match the list from the reference manual and datasheet.  I have filed an internal bug ticket for this so that it will be addressed by our internal teams.  

Thank you, and please let me know if you have any other issues or questions.

Regards,

Mitch

MCU Applications Engineer

Hi SLJ_IT,

Thank you for your inquiry about using Port Match wakeup and the UART on the Si1083.  It seems from your latest comment that this issue is solved, however I just wanted to check with you to see if your application is now working as expected?  

My first thought about the problem you described was that the Port Match wakeup did not occur fast enough for the UART to correctly receive the data.  Are you using Port Match on your UART RX pin as the wake up pin?

How did you resolve this issue?  Did you modify the calibration value for the internal oscillator in the OSCICL register?

Thank you, and please let me know if you have any questions.

Regards,

Mitch

Hi Davide,

You are welcome for the assistance, an sorry for the delay.  Silicon Labs has a driver for the an I2S microphone as is present on our Thunderboard Sense 2 board, and the driver uses LDMA for transfer of data from the USART to memory.  I suggest looking at this for additional insight into ways you might be able to utilize the LDMA with the USART/I2S for your purposes:

https://docs.silabs.com/mcu/latest/efr32mg12/group-Mic-i2s

The LDMA transfers as set up in mic_i2s.c (you can find these files in the Gecko SDK with your Simplicity Studio installation) as byte transfers.  Since you can only read 1 byte (USART_RXDATA) or 2 bytes (USART_RXDATADOUBLE) from the USART at a time, I am not sure there is a way to store your data in memory LSB first if you are receiving 24 bit samples MSB first over the wire.

Based on the WS/CS functionality you describe, to get MONO working, it sounds like you may need to just configure the USART for one of the stereo modes and ignore the half cycle in which data is not transmitted from the mic to the EFR32xG12 device.

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

Regards,

Mitch

HI Kenneth,

Thank you for the additional information.  I am not sure, but I suspect that since the SWO viewer in Simplicity Studio stopped working for you sometime since February but still works in the Segger Viewer and with the same code as before, I suspect something in an update may have caused the issue.  

I am glad that you have the workaround of using he Segger Viewer.  I would like to suggest that you open a Simplicity Studio support ticket in our support portal to report this potential bug.  Please export your Simplicity Studio log files by clicking [Help]>[Report Bug...] in Simplicity Studio and following the instructions on screen.  Then please upload them to the support case, as this will help the Simplicity Studio support team with their evaluation.

Thank you, and please let me know if you have any questions.

Regards,

Mitch

Hi Kenneth,

First, the CNT and AUXCNT counters of the PCNT module are not designed to count separate events from distinct inputs.  Rather, in quadrature decoder modes, one can be configured to count absolute events (i.e. down and up events) while the other can count only one or the other.  Additionally, the AUXCNT can only count up, although it can be configured to count up or down events.  For more information on this, please refer to section 16.3.3 Auxiliary Counter on page 424 of the EFR32xG1 Reference Manual.

As for using @delu's suggestion of the the S0IN input directly, to do this you would need to

1) ensure that the S0PRSEN bit in PCNT0_INPUT is 0 (PRS input not enabled). I.e. so not call

	/* Enable PRS Channel 0 */
	PCNT_PRSInputEnable(PCNT0, pcntPRSInputS0, true);

2) Set S0INLOC to LOC13 for PC8:

  PCNT0->ROUTELOC0 = (PCNT0->ROUTELOC0 & ~_PCNT_ROUTELOC0_S0INLOC_MASK) | PCNT_ROUTELOC0_S0INLOC_LOC13;

As I mentioned, however, you can only use both input to the PCNT for a quadrature decoder input mode, not to clock the CNT and AUXCNT counters separately.

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

Regards,

Mitch

Hi Kenneth,

Thank you for your inquiry about using the PRS to route a GPIO pin (PC8) input to the PCNT on the BGM111.  As you identified in your screenshot from the datasheet alternate functionality table, PC8 is available to PRS channel 0 at location 10, however these location and pin enable selections are necessary for PRS output to a pin.  GPIO input to a PRS channel is handled/selected differently, as I will describe below.  

You now have posted two versions of code, so I will comment only on your new code.  In your function setupCounter(), you call GPIO_ExtIntConfig() to attempt to set up GPIO external rising edge interrupt 6 to be triggered from PC8, which is an invalid combination.  PC8 belongs to pin grouping 2 (pins 8-11) which can be assigned interrupt number 8-11.  For  additional information on this, please refer to the EFR32xG1 Wireless Gecko Reference Manual, section 28.3.5.1 Edge Interrupt Generation (page 910) and the following API documentation for GPIO_ExtIntConfig():

https://docs.silabs.com/mcu/latest/efr32mg12/group-GPIO#gac954a361034e059b980964055f6d735a

I find it convenient to use the same interrupt number as the pin in question, so I recommend changing this call to:

	/* Configure external interrupt for BTN0 */
	GPIO_ExtIntConfig(gpioPortC, 8, 8, true, false, false);

Secondly, you need to set up the PRS to take PC8 as input to channel 0.  Two things here: 1) PC8 is in the GPIOH subset of pins, and 2) the PRS signal select field/parameter expects a selection based on pin number, not location number for the PRS output.  Thus, your call to PRS_SourceAsyncSignalSet() should be changed accordingly:

	/* Link PRS Channel 0 to GPIO PIN 8 (PC8) */
	PRS_SourceAsyncSignalSet(0, PRS_CH_CTRL_SOURCESEL_GPIOH, PRS_CH_CTRL_SIGSEL_GPIOPIN8);

Other sections you may wish to refer to in the EFR32xG1 Reference Manual and API documentation that may be helpful include the following:

EFR32xG1 RM section 15.3.2 Producers (PRS), page 392

https://docs.silabs.com/mcu/latest/efr32mg12/group-PRS#gaf05c066e83d651bfbdcb170af48c6843

I hope this helps!  Please let me know if this resolves your issue or if you have any questions/problems.  Thank you.

Regards,

Mitch

Hi Kenneth,

Thank you for your inquiry about using the PRS to route a GPIO pin (PC8) input to the PCNT on the BGM111.  As you identified in your screenshot from the datasheet alternate functionality table, PC8 is available to PRS channel 0 at location 10, however these location and pin enable selections are necessary for PRS output to a pin.  GPIO input to a PRS channel is handled/selected differently, as I will describe below.  

You now have posted two versions of code, so I will comment only on your new code.  In your function setupCounter(), you call GPIO_ExtIntConfig() to attempt to set up GPIO external rising edge interrupt 6 to be triggered from PC8, which is an invalid combination.  PC8 belongs to pin grouping 2 (pins 8-11) which can be assigned interrupt number 8-11.  For  additional information on this, please refer to the EFR32xG1 Wireless Gecko Reference Manual, section 28.3.5.1 Edge Interrupt Generation (page 910) and the following API documentation for GPIO_ExtIntConfig():

https://docs.silabs.com/mcu/latest/efr32mg12/group-GPIO#gac954a361034e059b980964055f6d735a

I find it convenient to use the same interrupt number as the pin in question, so I recommend changing this call to:

	/* Configure external interrupt for BTN0 */
	GPIO_ExtIntConfig(gpioPortC, 8, 8, true, false, false);

Secondly, you need to set up the PRS to take PC8 as input to channel 0.  Two things here: 1) PC8 is in the GPIOH subset of pins, and 2) the PRS signal select field/parameter expects a selection based on pin number, not location number for the PRS output.  Thus, your call to PRS_SourceAsyncSignalSet() should be changed accordingly:

	/* Link PRS Channel 0 to GPIO PIN 10 (C8) */
	PRS_SourceAsyncSignalSet(0, PRS_CH_CTRL_SOURCESEL_GPIOH, PRS_CH_CTRL_SIGSEL_GPIOPIN8);

Other sections you may wish to refer to in the EFR32xG1 Reference Manual and PAI documentation that may be helpful include the following:

EFR32xG1 RM section 15.3.2 Producers (PRS), page 392

https://docs.silabs.com/mcu/latest/efr32mg12/group-PRS#gaf05c066e83d651bfbdcb170af48c6843

I hope this helps!  Please let me know if this resolves your issue or if you have any questions/problems.  Thank you.

Regards,

Mitch

Hi Kenneth,

Thank you for writing to inquire about this issue using the SWO viewer in Simplicity Studio v4 with the BGM111.   I have a few questions and suggestions to get started debugging this issue:

1) You say it stopped working but worked a couple months age.  In this time, did you change or update Simplicity Studio or your SDK?

2) What is the SDK version number for the instance a) where the SWO viewer used to work and b) the SDK version number now where is no longer works?  You mention v4.1 - is that the new version number in which the SWO viewer stopped working?

3) There are a couple posts/knowledge base articles that might help - note that both have attached example code.  Do either of these examples work/help resolve the problem?

https://www.silabs.com/community/mcu/32-bit/forum.topic.html/print_to_swo_console-sZ7M  (Scroll down to find the code posted by John)

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

I hope this helps.  Thank you, and please let me know if you have any questions.

Regards,

Mitch

MCU Applications Engineer

Hi Davide,

Thank you for your inquiry about using the USART with LDMA to transfer I2S samples from your I2S microphone to the EFR32MG12.  I have a couple points of feedback regarding the two questions you have asked:

1) You have indicated that your data is written by the LDMA in big-endian format, but you need it in little-endian format.  The LDMA of the EFR32xG12 device has a configuration option that will automatically swap the bytes (and hence the endianness) of 16 or 32 bit transfers.  Unfortunately, it looks like DMADRV dies not provide a means to select this configuration in the API, so if you wish to use it you may consider using EMLIB instead of EMDRV.  Note that EMDRV uses EMLIB under the hood.  The byte swap configuration is controlled using the LDMA_Descriptor_t Union, which is a parameter to the function LDMA_StartTransfer():

https://docs.silabs.com/mcu/latest/efr32mg12/group-LDMA#ga0b27c0375b6e3f6a862f9317a7d04fba

For more information on the byte swap feature of the LDMA, please refer to section 8.3.1.8 of the EFR32xG12 Wireless Gecko Reference Manual.

If you would like to reference some DMA examples that use EMLIB natively, please refer to our 32-bit Peripheral Examples on Github:

https://github.com/SiliconLabs/peripheral_examples/tree/master/series1/ldma

2) As for getting the system working in MONO mode, there are a couple things that could affect this.  First, note that in I2S mode, the USART CS pin functions as the WS signal and has different behavior depending on the I2S mode (i.e. mono vs. stereo).  In stereo mode, the WS signal toggles at the start of a new word to signal that word is either left channel (WS low) or right channel (WS high).  In mono mode, the WS pulses at the beginning of each new word.  

For more info on this, please refer to the EFR32xG12 Reference Manual, section 18.3.3.8 I2S on page 569.

Thus, you may need to investigate the operating parameters of your I2S microphone to see what it is expecting to see on the WS line and whether the scheme I described is compatible.  

I'm not sure you will need a dummy descriptor to handle the missing right channel, you may just need to treat the data you are receiving from the microphone as mono or stereo as appropriate in your handling of the incoming samples.  Have you tries enabling mono mode in the I2S/USART and not using a dummy LDMA transfer - just treating all incoming data in your left channel descriptor as mono audio data?

I hope this helps!

Regards,

Mitch

MCU Applications Engineer