your collegue have confirmed it is the problem with the plug that fails to decrypt the NWK key so it cannot announce itself in the network. Can you please makesure that you decrypt the messages with the link key i gave you? I am confirming this device cannot join from the logs i have attached

Zigbee® Green Power (ZGP) is included in the Zigbee 3.0 specification (Z3) (Zigbee Alliance, Zigbee 3.0 specification, https://www.zigbee.org/zigbee-for-developers/greenpower/). It is an end-to-end open standard that allows ultra-low power devices called Green Power Devices (GPDs) to operate on Zigbee networks. The technology requires ultra-low power RF silicon that uses many orders of magnitude less power than required for a Zigbee sleepy or fully-networked wireless connection.

The EFR32xG22 EM2 and EM4 power modes along with the back-up RAM feature make it suitable to implement a periodic or event-based GPD sensor with bidirectional commissioning and secured key exchange.

GPD Communication

There are two types of communication modes based on energy budget:

- Unidirectional: the device only transmits information to the Zigbee network

- Bidirectional: the device transmits and then receives information back, such as security material.

The bidirectional mode implementation uses EM2 power mode and the low energy sleep timer as a wake-up source between transmit and receive.

Commissioning and Security

The hardware acceleration in EFR32xG22 makes it possible to implement a GPD with the highest level of security (encryption and message integrity with application key exchange) during bidirectional commissioning.

Storage of Security Material

In a battery-backed GPD implementation, the back-up RAM can hold the security material during EM4 sleep.

More Information

The user guides on Green Power fundamentals and information about using the Silicon Labs Green Power framework can be found here:

https://www.silabs.com/documents/public/user-guides/ug103-15-green-power-fundamentals.pdf

https://www.silabs.com/documents/public/user-guides/ug392-using-sl-green-power-with-ezp.pdf

Hi Diego,

This is very helpful feedback, and I've passed this along internally for consideration.

All,

If there's any other feedback about what would be helpful in how we distribute the libraries and code, please let us know.  As I mentioned, we're continuing to discuss how we can do this in a better way internally, so the more feedback the better!

~Tabi

Hi all,

Unfortunately, this issue is more complicated than just using git to push the SDK releases on Github, as there are several licensing and legal complications. We’re continuing to discuss this internally and will let you know when we have more we can share.

~Tabi

The purpose of this project is to demonstrate how to use the Stereo MEMS Microphone on SLSTK3701A.
The MCU publishes the received data using the LCD. The received digital data are converted to decibel dimension. Each side has two textboxes where the numbers are the RMS and Peak values. Moreover, there are two scales, represent the previous values visually. The pressing of BUTTON_0 resets the Peak values.
By going through the project, the reader gets information regarding several peripherals, like I2S, TIMER, GPIO, LCD handling and interrupts.

Physical layer

The STK has two MEMS microphones, using these to capture the left- and right-side. The output signal of the microphones is PDM (Pulse Density Modulation) signal. The EFM32GG11 has no PDM processor peripheral, instead the STK has a PDM-to-I2S codec. The output from both microphones is connected to this codec which again is connected to a USART peripheral which supports I2S. The below figure shows the physical connections, see Figure 1.

Figure 1.

Physical connection.

Application workflow

As every project, it starts with the initialization of the peripherals, clocks and interrupts. Hereupon the whole application is based on a state-machine, has the following states:

1. Idle before data comes
2. Data collection in progress
3. Idle before process the data
4. Data process in progress

Have a look at for each state.
The 1st state is made for synchronization. There are two microphones, but the data arrives on one line (MIC_I2S_DATA). The I2S standard define the LRCLK signal, to indicate the codec which microphone data is needed. On low-level the left-, on high-level the right-side data will be requested from codec. The LRCLK frequency is generated automatically by USART. At the beginning peripheral and codec delay might occur, therefore it can't be sure the first USART_RX interrupt is caused by the left or right-side data. To determine the cause of the interrupt, the level of LRCLK had to be known. The PRS and GPIO Interrupt help to know the state of LRCLK. If the level is low, a GPIO interrupt occurs to sign the left data will come. The PRS is used to connect to the USART_LRCLK and the GPIO.
After the falling edge of LRCLK, the next state is coming.
The purpose of the 2nd state is to collect both side data. For this, the USART generates an interrupt, if its buffer is full. The 16 bits data are stored in a common array for both sides. After 2400 samples (1200/side), the state-machine switches to the next state.
The 3rd state is made for waiting before processing the samples. Due to the high sampling frequency(48kHz) the data gathering takes about 50 ms. The TIMER0 ensures to elapse the defined LCD update time, even if the sample rate or buffer size would be modified.
In the 4th state, the data processing follows. Here the RMS and Peak values are calculated, then a string is made from the float numbers. After all the necessary data and strings are made, the content of the LCD have to be refreshed. The "red arrow" on Figure 2. shows how the process is repeated cyclically.
After the update we must know again which side data will come, because during the processing, the data gathering has been stalled. Similarly to the 1st state, the GPIO interrupt will indicate the active side.
The below figure illustrates the above.

Figure 2.

Application workflow.

Software key points

Since the project is attached to this KBA, only the important parts of the software is highlighted.

Interrupt priority

As the whole project is based on the data via USART, important to avoid data loss. The codec transmits the bits regardless what the MCU does at that time. To be sure none of bits are lost and the frequently generated GPIO_ODD interrupt doesn't influence the USART_RX interrupt, set the priorities.

  __NVIC_SetPriority(USART3_RX_IRQn, 0);
  __NVIC_SetPriority(GPIO_ODD_IRQn, 1);
  __NVIC_SetPriority(TIMER0_IRQn, 2);

Baud rate

The data sheet of codec specifies that the BCLK has to be at least 64 times greater than the LRCLK. In addition, the typical LRCLK is 48kHz, the related BCLK is 3.072MHz. The codec has 20-bit digital output. The width of frame determines the frequency of LRCLK. For example 32[bit width frame]* 2[side]*48kHz=3.072MHz, therefore it fulfills the requirements.
The above means we should use 32bit width frames. The useful data of frame could be 16 bits, because the LSBs may mean just noise.

  def.sync.databits = usartDatabits16;
  def.sync.autoCsEnable = true;
  def.sync.baudrate = BCLK_FREQUENCY_3MHz;
  def.format = usartI2sFormatW32D16;

USART interrupt

Since 16 of 20 bits are considered, the appropriate interrupt source would be the "RX buffer is full". By using this, we do not have to deal with the other bits.
Warning: It is not enough to read the RXDOUBLE register to clear the pending RXFULL interrupt flag like in case of RXDATAV, the RXFULL interrupt flag must be cleared by software.

  USART_IntClear(USART3, USART_IFC_RXFULL);

Filter the too low values

In the USART_RX IRQ low values are ignored to get more visible change on the scales.
For instance, if the data is 1, it means ~-96dB,100 means ~-56dB. These numbers rarely come, but sometimes it happens.
By considering the size of the LCD and the possible sound pressures in a room, suitable spectrum is between -30dB and 0dB.

Test

The demo is tested with

• EFM32GG11 Giant Gecko Starter Kit (SLSTK3701A)
• Simplicty Studio V4.
• Gecko SDK Suite v2.4

Figure 3.

Demo on STK.

Preparing for this lab

Project Overview | Next Step

First dock the Mini-Simplicity connectors onto your WSTKs are shown here:

Also connect your ribbon cable as shown. Then connect your Thunderboards on their corresponding 10 pin header. If your mini simplicity connectors do not have keyed headers, make sure to match your pin 1s of both 10 pin headers.

 

Since we are using Thurnderboards connected externally to our WSTKs, we must make sure our WSTKs are set to debug mode OUT. This can be done via commander. For each WSTK run the following command

commander adapter dbgmode OUT -s XXXXXXX

where XXXXXXX is the serial number of your WSTK.

This can also be performed within Studio from the Launcher perspective. Under the Debug Adapters pane near the top left, you should see the two boards/adapters show up as “J-Link Silicon Labs (4400xxxxx). Highlight each adapter and change the Debug Mode to “OUT”. If you are prompted to update the board firmware, please proceed with the update. Note that when the Debug Mode is OUT, Simplicity Studio does not know about the Thunderboard Sense 2 board anymore and this is expected. (WSTK main board is still recognized.)

Creating bootloaders

Because neither of our applications will run without a bootloader, we want to create a bootloader for each. Fortunately, a default Gecko application bootloader will work for each board in this example.

To generate this bootloader:

• Make sure your Simplicity Studio is in either the Launcher view or the Simplicity IDE view.
• Then select File > New > Project. This will bring up the New Project Wizard.
• On the first screen you want to select Silicon Labs AppBuilder Project and select Next.
• Then select Gecko Bootloader and select Next.
• When the Select Application screen comes up find the bootloader template titled “SPI Flash Storage Bootloader (single image)”. Select it and hit Next.
• Give your Project a name, such as “TB-app-BL” and hit Next.
• Finally, you will be asked for your Board, Part and Configuration. Make sure to specify the board as “Thunderboard Sense 2 (BRD4166A)”, this will populate the part field automatically (EFR32MG12P332F1024GL125) then specify your toolchain (GNU ARM 7.2.1 or IAR ARM 8.30.1) and hit Finish.

Once your App Builder project opens, click the generate button to generate your project without any changes. Once the Generation successful window appears, you are done.  Then use the Hammer icon on the toolbar to invoke your compiler and build your project. This will give you the binaries to flash onto your board. You will need to locate the file named -combined.s37, it should be located in your projects binary folder.

You should flash this application to each of your Thunderboards, making sure to erase each board as you do this. Because you are flashing an external part, it will ask you to use the device option (-d) to identify the part connected to your board, using EFR32 will be enough to proceed.

commander flash TB-app-BL-combined.s37 --masserase -s XXXXXXX -d EFR32

Once you have completed this, you will be ready to begin creating your projects.

Project Overview

Next Step

Question

My UZB Controller is not being recognized by the computer, even after installing the correct drivers and is listed in Windows device manager as an "unknown device". How do I recover it?

 

Answer

The firmware may have been corrupted, or a faulty image may have been programmed.

The only recovery option is to open the UZBs and solder wires on the testpads for UART RX, TX, Reset and ground. These signals can be connected to the ZDP03A or any other TTL level UART and be programmed through the Z-Wave Programmer.

Refer to the silkscreen labels on the UZB:

 

And connect the wires as follows on ZDP03A:

• T: J4 pin 2
• R: J3 pin 2
• VDD: J8 pin 1
• GND: J6 pin 9

The reset pin is not connected, it should be shorted to ground, when prompted to assert reset during programming.

From here, proceed with UART programming as normal.

It is also recommended to check that the NVR is correctly programmed.

 

For more information on UZB, refer to the product manual.

 

NB: Please note that this approach only applies to Sigma Design / Silabs branded UZBs. Other manufactures might not have exposed the test pads in the same way. Refer to the specific manufacture if you are not using a Silabs UZB.

Hi all,

I'm pleased to announce new software that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following: 

• EmberZNet 6.4.0 (Full release here)
  • Green Power Combo
  • Sub-GHz PHY running on RAIL
  • NVM3 support for single protocol Zigbee
  • Upgrade feature from SimEEv2 to NVM3
• Silicon Labs - Thread 2.8.0 (Full release here)
  • SL-Thread support for LZ4 decompression in Gecko Bootloader
  • Border Router support for Basil Hayden Thread features
  • Beta release for Dotdot 
• Flex 2.4.0 (Full release here)
  • Support for existing EFR32MG1x sub-GHz parts
  • Support for new EFR32MG1x sub-GHz parts
  • Multi-PHY support
  • Connect support for 500kbps data throughput
  • 2.4GHz and sub-GHz FHSS
  • Dynamic Multiprotocol RAIL + BLE Range test and  Mobile App support
• Bluetooth 2.10.0 (Full release here)
  • Optional Adaptive Frequency Hopping (AFH) and +20 dBm TX
  • Modules treated as individual products in Studio
  • RF channel now reported in scan events
  • Bluetooth + RAIL DMP range test application
• MCU (Full release here)
  • Production Bootloader for EFM32GG12x
  • CMSIS package for EFM32GG12x alpha 
  • Support for LTE-M expansion kit for EFM32GG11x STK
  • EFM32GG11x EBI support in EMLIB

Note that API documentation and release notes for most stacks are now available at docs.silabs.com.

Need help? Please contact Silicon Labs Technical Support.

Hi all,

I'm pleased to announce the latest SDK that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following: 

• EmberZNet 6.3.0 (Full release here)
  • Zigbee Pro 2017 (R22) compliant stack w/ GPPB and SE1.4/GBCS support
  • Dynamic block request delay support for OTA upgrades
  • Sub-GHz only mode support for SE1.4/GBCS
  • NVM3 G.A integration
  • Gecko Bootloader LZMA decompression support
  • IAR EWARM 7.80.4 and GCC 7.2.1 support
• Silicon Labs - Thread 2.7.0 (Full release here)
  • Thread with Micrium OS Beta support 
  • DotDot DTLS security support
  • DotDot resource directory and discovery support
  • DotDot conformance testing support
  • IAR EWARM 7.8.4 and GCC 7.2.1 support
  • GRL Test Harness support bug fixes
• Flex SDK (Full release here)
  • Version 2.2.1.0 GA – enhanced support for QFN68 variants of EFR32xG12
  • Version 2.2.2.0 GA – RAIL and Connect feature enhancements and bug fixes
  • Version 2.2.2.1 GA – minor metadata changes, no application or stack changes
• Bluetooth SDK (Full release here)
  • +20dBm support and AFH
  • Long advertisement packets & additional RF channels 
  • Bluetooth + RAIL DMP enhancements 
• MCU (Full release here)
  • Gecko LE-USB support on GG11, to complement existing Micrium USB 
  • Micrium OpenCAN support for GG11/TG11

Need help? Please contact Silicon Labs Technical Support.

~Tabi