Doh!  Please excuse me for not reading closely enough and noticing that this discussion concerns the EFM8BB1LCK and NOT the EFM8BB1 STK!  Sorry for the misdirection/irrelevant information.  Also thank you to the others who provided answers on this thread.

Yes, the debug chip (CF326-SX0261GM) on the EFM8BB1LCK can program the EFM8BB3/EFM8LB1 (any EFM8).

Additionally, though you will probably have to remove or disable the EFM8BB1 on the LCK in order to program an external target, you should be able to do it by connecting your external target C2CK, C2D, GND, and VDD signals to the corresponding signals connecting to the EFM8BB1 target device on the LCK, as delu mentions.

Please be aware, however, that these debug signals correspond to pins 1 (C2CK) and 28 (C2D) of the debug device (CF326), however pins 9 and 10 do not correspond to the the target MCU debug/programming pins and using these connections will not work for programming a target device.

On the board, this means that the test points labeled '1' and '2' correspond to "DBG_C2CK" and "DBG_C2D," respectively and are the correct connection points to use for device programming using the onboard debugger (please refer to the illustration below).  Note that the board test points labeled "C2D" and "C2CK" are debug signals associated with the debug device, not the target device, and can NOT be used to program the EFM8BB1 onboard target or an external target (please refer to the illustration below).

Additionally, here are a couple other posts/threads with related information:

https://www.silabs.com/community/mcu/8-bit/forum.topic.html/how_to_debug_externalboardbyefm8bb1lowcostki-CvVi

https://www.silabs.com/community/mcu/8-bit/forum.topic.html/unable_to_use_usbdebuggeradapter8bitonefm8bb-6bG2

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

Regards,

Mitch

Hi Alexander,

Can you please elaborate on your question?  In your post title, you say you are using 8051F340 with UART1 and in the post you mention C8051F320.  Which device are you using?

If you are using C8051F340 and need to skip pins to reassign or shift UART1 pins to other pins, you appear to already do this correctly in your post here, and there are other answers to your post there as well, as delu mentioned.

If you are using, C8051F320, there is no UART1, and UART0 is restricted to using P0.4 and P0.5.  Thus, I am not sure what your question is asking.  Please clarify.  Thank you!

Regards,

Mitch

MCU Applications Engineer

Hi C Becke,

Thank you for your inquiry about debugging an external device using your EFM8BB1 STK (SLSTK2020A).  For your reference, I want to point out the UG236: EFM8BB1-SLSTK2020A User's Guide:

https://www.silabs.com/documents/public/user-guides/ug236-efm8bb1-slstk2020a.pdf

Please note that it is not necessary to de-solder and remove the target MCU on any Silicon Labs starter kit in order to debug an external MCU on a custom board, and the debug adapter device present on all Starter Kits should be able to debug any EFM8 or EFM32/EFR32 device.  To debug an external target, you simply need to place the kit in Debug OUT mode and select the target device in the Adapter configuration window of Simplicity Studio.  Information on configuring the kit debug mode can be found on page 18 of the User Guide:

Connecting the Starter kit to your external device should be done using the keyed debug connector on the board (see page 12 of the user guide):

As for why your setup is not working, there could be a number of reasons, including board damage during the de-soldering of the SLSTK2020A target MCU, the connecting wire length being too long, or circuit problems on your custom board.  Do you have a 1 k-ohm pull up resistor connected between your C2CK/RSTb (pin 5) and VDD on your custom board?  Are the C2CK and C2D pins and wires matched up properly between the SLSTK pads/pins and your target device (custom board)?  Have you soldered wires to the pads where the EFM8BB1 from the SLSTK used to be?

Feel free to post pictures of your modified SLSTK and entire setup, as well as a schematic of your custom board if you need help debugging this issue further.  Thank you, and I hope this helps.

Regards,

Mitch

MCU Applications Engineer

Hi Michael,

I reproduced the behavior you are referring to on my Simplicity Studio v5 installation nd have created an internal ticket to address this apparent bug in the Configurator.  In the meantime, I recommend manually configuring the pin in your code to open drain.

Besides the reference manual information on multiprocessor communications, I recommend browsing the Silicon Labs community forums for additional information and posts on this application, such as the following:

https://www.silabs.com/community/mcu/8-bit/forum.topic.html/c8051f380_multiproce-tmgc

Additionally, you can find many external resources online for this industry standard application use case.

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

Regards,

Mitch

MCU Applications Engineer

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