The Silicon Labs EFR32 family of IoT microcontrollers are very flexible and can do a ton of cool stuff. However, along with all that flexibility comes a lot of complexity. With that complexity are default settings that work fine for many applications but in some cases you want to dig into the details to come up with an optimal solution. In this post I’ll show how to speed up the wake up time for the Z-Wave ZGM130S chip from a GPIO.

But first – a caveat: This post applies to Z-Wave SDK 7.13.x. Future releases of the SDK may have different methods for sleep/wake and thus may require a different solution.

The Problem

Frequently Listening Routing Slaves (FLiRS) devices like door locks and many thermostats spend most of their time in Energy Mode 2 (EM2) to conserve battery power. Once per second they wake up briefly and listen for a Beam from an always-on device. If there is a beam, the FLiRS device will wakeup and receive the Z-Wave command. This allows battery powered devices to use very little power but still be able to respond to a Z-Wave command within one second. FLiRS devices use more battery power than fully sleeping devices like most sensors which use Hibernate Sleep mode (EM4). To wake every second the ZGM130 has to wake quickly and go right back to sleep to minimize power. The problem with EM4 is that it takes a few tens of milliseconds to wake up as the entire CPU and RAM have to be initialized as they were powered down to save power. For a FLiRS device, it’s more efficient to keep RAM powered but in a low-power state and resume quickly to go right back to sleep if there is no beam. Typically the ZGM130 can wake up in about 500 microseconds from EM2. But in many cases this is still too long of a time to stay awake if there are other interrupts such as UARTs or other sensors.

The scope shot above shows the processing that takes place by default on the ZGM130S. In this case I am using a WSTK to drive the SPI pins of another WSTK running the DoorLockKeyPad sample application. The chip is in EM2 at the start of the trace. When SPISEL signal goes low, the chip wakes up. But it is running on the HFRCO oscillator which is not accurate enough to run the radio but it is stable and usable in just a few microseconds. Thus, the SPI clock and data is captured in the USART using this clock. However, by default the Interrupt Service Routine is blocked waiting for the HFXO to stabilize. The 39MHz HFXO crystal oscillator has the accuracy required for the radio.

The question is what’s going on during this 500usec? The answer is the CPU is just waiting for the HFXO to stabilize. Can we use this time to do some other work? Fortunately, the answer is YES! The challenge is that it takes some understanding and some code which I’ll describe below.

The Solution

There are three functions that do the majority of the sleep processing. These are provided in source code so you can read the code but you should not change it. Instead you’ll provide a callback function to do your processing while the chip is waking up.

Simplified Sleep Processing Code:

1. SLEEP_Sleep in sleep.c: The main function called to enter sleep
   1. CORE_ENTER_CRITICAL – PRIMASK=1 mask interrupts
   2. DO-WHILE loop
      1. Call enterEMx() – this is where the chip sleeps
      2. Call restoreCallback (return 0 to wake, 1 to sleep)
   1. Call EMU_Restore – waits for HFXO to be ready ~500us
   2. CORE_EXIT_CRITICAL – ISRs will now run
2. enterEMx() in sleep.c:
   1. sleepCallback called
   2. Call EMU_EnterEM[1-4]
   3. wakeupCallback after returning from EMU_EnterEMx
3. EMU_EnterEM2 in em_emu.c:
   1. Scales voltage down
   2. Call EMU_EM23PresleepHook()
   3. __WFI – Wait-For-Interrupt instruction – ZGM130 sleeps here
   4. Call EMU_EM23PostsleepHook() ~ 17usec after wakeup
   5. Voltage Scale restored which takes ~20us

The code is in sleep.c in the SDK which has a lot more detail but at a high level this is what you need to know. The important part to understand here is where the “hooks” are and how to use them.

• Use Sleep_initEx() to assign:
  • sleepCallback – called just before sleeping
  • restoreCallback – Return 0 to wake, 1 to sleep
  • wakeupCallback – called after waking
  • Sleep_initEx() input is a pointer to a structure with the three callbacks or NULL if not used
• Define the function:
  • EMU_EM23PresleepHook()
  • EMU_EM23PostsleepHook()
  • These are both WEAK functions with nothing in them so if you define them then the compiler will install them

The two EMU_EM23* weak functions are run immediately before/after the Wait-For-Interrupt (WFI) instruction which is where the CPU sleeps. These are very low level functions and while you can use them I recommend using the callbacks from Sleep_initEx().

The SLEEP_initEx() function is the one we want to use and in particular the restoreCallback. The comments around the restoreCallback function talk about restoring the clocks but if the function returns a 0 the chip will wake up and if it returns a 1 then it will immediately go back to sleep which is what we want! You can use the other two hooks if you want but the restoreCallback is the key one since it will immediately put the chip back to sleep if everything is idle.

The key to using ANY of these function is that you CANNOT call ANY FreeRTOS functions! You cannot send any Z-Wave frames or call any Z-Wave function as they all require the RTOS. At this point in the wakeup processing the RTOS is not running! All you can do in these routines is to capture data and quickly decide if everything is idle and to go back to sleep. If there is more processing needed, then return 0 and wait for the event in the RTOS and process the data there. You also don’t want to spend too much time in these routines as it may interfere with the timing of the RTOS. A hundred microseconds is probably fine but longer you should wait for the HFXO.

In ApplicationInit() you will call Sleep_initEx() like this:

const SLEEP_Init_t sleepinit = {NULL, NULL, CheckSPI};
...
ZW_APPLICATION_STATUS ApplicationInit(EResetReason_t eResetReason) {
...
SLEEP_InitEx(&sleepinit); // call checkSPI() upon wakeup from EM2.
...
}
...
uint32_t CheckSPI(SLEEP_EnergyMode_t emode) { 
	uint32_t retval=0; // wake up by default
	if (GPIO_IntGetEnabled() & 0x0000AAAA) { // Check SPI
		GPIO_ODD_IRQHandler(); // service the GPIO interrupt
		// wait for all the bytes to come in and compute checksum 
		NVIC->ICPR[0] = NVIC->ICPR[0]; //clear NVIC pending interrupts
		if (!SPIDataError && !IsWakeupCausedByRtccTimeout())	{
			 retval=1; // go back to sleep!
		}
	}
	return(retval); // 0=wakeup, 1=sleep
}

Recall that every second the FLiRS device has to check for a Z-Wave beam which is triggered by the RTCC timer. Thus the check for IsWakeupCausedByRtccTimer ensures that the beaming still works.

This scope shot shows the wake up processing of the ZGM130S:

1. SPISEL_N SPI chip select signal goes low triggering a GPIO_ODD interrupt
   1. The chip wakes up, the HFRCO begins oscillating
2. HFRCO begins oscillating in a few microseconds
   1. Once HFRCO is running, the peripherals are functional
   2. SPI data can begin shifting once the HFRCO is running
   3. The default HFRCO frequency is 19MHz but can be increased
   4. Higher frequencies for HFRCO also may need more wait states for the CPU and will use more power
3. The WFI instruction that put the CPU to sleep is exited here
   1. EMU_EM23PostSleepHook function is called if defined
   2. After returning from PostSleepHook, the VSCALE is returned to full power which takes about 10usec
   3. It is best to wait for the voltage to be powered up to ensure all logic is running at optimal speeds
4. EMU_EnterEM2 is exited and restoreCallback is called if initialized
   1. This is the function where the ISR should be called to process data
   2. If the data says things are idle and want to go back to sleep, return 1
   3. If more analysis is needed, then return 0
   4. Carefully clear the interrupt bits
      1. First clear the peripheral Interrupt Flags
      2. Then clear the NVIC Interrupt pending register
         1. NVIC->ICPR[n]=NVIC->ICPR[n] where n is 0-1 depending on your interrupt
   5. Make sure there aren’t other reasons to wake up fully
      1. !IsWakeupCausedByRtccTimeout() is the 1s FLiRS interrupt
      2. There may be other reasons to wake up which is application dependent
5. In this example the SPI data is being fetched from the USART at each toggle of the GPIO
   1. The final toggle shows that the checksum was computed and the data is idle so go back to sleep
6. The chip returns back to sleep in a few more microseconds
   1. Total processing time of this interrupt is less than 200usec which is a fraction of the time just waiting for the HFXO to stabilize
   2. Much of that time is receiving and processing the SPI data
   3. It is possible to sleep in under 50usec if the check for idle is quicker

If your peripheral processing will take significantly less than 500usec, then it may be more efficient to process the data using the HFRCO and not wait for the HFXO to power up. But if your application needs more processing, then you are probably better off waiting. Each application must make their own calculations to determine the most efficient path.

What About Sleeping Devices?

Fully sleeping devices (EM4 also known as RSS – Routing Sleeping Slaves) have entirely different wake/sleep processing. For sleeping slaves the processor and RAM have to be re-initialized and the chip essentially boots out of reset. All that initialization takes quite a bit of time – a few tens of milliseconds. If your device needs to do a lot of frequent checking of a sensor, then it might make more sense to force it to stay in EM2 by setting a Power Lock to PM_TYPE_PERIPHERAL. For more details on power locks see INS14259 section 7.6. Deciding which way to go is application specific so you have to make the calculations or measurements to find the right balance for your project.

This is a complex posting but I hope I’ve made it clear enough to enable you to optimize your application firmware. Let me know what you think by leaving a comment below or on my blog at drzwave.blog.

 

SDK 7.13.3.1.0 was released today which provides the workaround for creating the GBL file in the release notes. See SRN14629 page 8 or search for SWPROT-4021. The code was not fixed, just the release notes explaining the workaround.

This guide uses the DoorlockKeyPad built under 7.12.2 but the same basic concepts apply to any sample app and your project. A generic KBA on upgrading SDKs for Bluetooth projects provides general insights but this document is specific to this Z-Wave release.

1. Update Simplicity Studio (SS)
   1. From the Launcher perspective, click on the download icon and then click on Update All
   2. Close Simplicity and restart (just to be safe) - SS may ask to do this as well
   3. Click on the download button again, click on Package Manager, click on SDK tab, click on each Update button (keep scrolling down). I recommend restarting SS between each update.
2. Set the Preferred SDK to the latest release
   1. Plug in a WSTK devkit or select the ZGM130S in the MyProduct window
   2. From the Launcher perspective, click here:
   3. Select the Gecko SDK Suite 7.13.3.0
   4. Now when you want to create a new project it will start with the 7.13.3 release
3. At this point there are 3 options for upgrading:
   1. Open a new 7.13.3 project and then copy your changes into it
   2. Import/Export parts of your project into a new 7.13.3 project
   3. Manually edit the .cproject and .project files
4. Far and away the best option is the first one - option A
   1. The advantage of this is that you get all the latest and newest files of the Z-Wave Application Framework (ZAF), emlib, linker scripts, and lots of other stuff
   2. The challenge is that you have to plug all of your changes back into the sample application
   3. If you’ve made most of the changes in files other than the sample application, then the changes are probably easy to install
   4. However, if you’ve made a lot of changes to the sample application source code file it will take more time
   5. Option B or C might be the way to go but at some point it might still be better to go back to option A. Option A is fairly straightforward as the sample apps in the 7.13.3 release already work so just copy in your changes a few at a time and keep recompiling to make sure you haven’t broken something.
   6. If taking option A you’re done! No need to read any further! Create the new sample app and start plugging in your changes
   7. If you’re not taking option A, pick one of the 2 options below. The choice of B or C is up to you and primarily how confident you are in fixing XML files. If you think you can fix an XML file, then use option C otherwise use B.
5. Option B - Import/Export parts of your project into a new 7.13.3 project:
6. This option avoids manually editing the XML file but requires importing/exporting several files and using the GUI to fix paths. The advantage however is that you shouldn’t break the XML file which is easily done with manual editing.
7. Export the project created with Z-Wave 12.2 SDK using [File] > [Export...].
8. Window->Preferences->SimplicityStudio->SDKs
   1. Remove the 7.1x.xx SDKs from the Simplicity Studio SDK preferences
   2. This does not delete or uninstall the actual SDK, just removes it from the current workspace settings so it will not be used during the project import step
9. Import the .sls file created with the export. ([File] > [Import...]) above
10. Right click the project from the IDE perspective
11. Project Properties [C/C++ Build] > [Board / Part / SDK] and select the Gecko SDK Suite: 7.13.3.0, Flex 2.7.3 from the dropdown list
12. When it asks to Rebuild Now - click on YES!
13. The build will fail because the Linker script location has changed from:
    1. ${StudioSdkPath}/ZWave/linkerscripts/zgm13-zw700.ld
    2. to
    3. ${StudioSdkPath}/protocol/z-wave/ZWave/linkerscripts/zgm13-zw700.ld
    4. Right click on the project
    5. Properties->C/C++ Build->Settings->Memory Layout
    6. Change the linker script location as shown here
14. Try to Build again but now there are all sorts of problems with basic things like SizeOf.h cannot be found. This is caused by the change in the directory structure for the 7.13 SDK.
15. In the 7.13.3 project - right click on the project->properties->C/C++ General->Paths and Symbols and click on EXPORT Settings
16. Export them all to a temporary file - IE:Seven13Paths.xml
17. Return to the same screen in your project, <CTL-A> to select all the paths then Delete - be sure to delete ALL of them
18. Then click on Import Settings and select the Seven13Paths.xml file
19. Build again and you should get a “conflicting types for __Vectors” error
    1. This is caused by a new Device/startup_zgm13[.S,.c] - copy these files from the 7.13.3 project into your project
20.  Build again and you get an error “No rule to make target libZWaveSlave.a”.
21. Right click properties->C/C++Build/Settings->GNU ARM C Linker->Other objects
22. Change
    1. ${StudioSdkPath}/ZWave/lib/libZWaveSlave.a
    2. to
    3. ${StudioSdkPath}/protocol/z-wave/ZWave/lib/libZWaveSlave.a
    4. and
    5. ${StudioSdkPath}/SubTree/rail-import/platform/radio/rail_lib/autogen/librail_release/librail_efr32xg13_gcc_releasa
    6. to
    7. ${StudioSdkPath}/platform/radio/rail_lib/autogen/librail_release/librail_efr32xg13_gcc_release.a
23. If other errors turn up, try doing a Clean Project and exit SS and start it up again
24. Click Build
    1. OtaInit() function has changed to CC_FirmwareUpdate_Init() which needs a 4th argument which is “true”.
25. Click Build
    1. The error is: Undefined reference to `FileSystemVerifySet' in DoorLockKeyPad.c
    2. The problem here is that the ZAF has changed how it is checking the state of the file system and using a much easier process of checking a few Tokens in NVM3. Compare the 7.13.3 sample app code and use that process instead of the one from 7.12.2. Basically, delete (or #if 0/#endif) several lines of code.
26. Click Build
    1. The error is: Undefined Reference to CC_FirmwareUpdate_InvalidateImage
    2. The confusing part of this error is that you can click on this function and it will open the correct file. The problem is that it is not included in the project.
    3. The problem is there are 2 new Linked files - btl_reset_cause_util.[c,h].
    4. Copy via a link into the ZAF_CommandClasses_FirmwareUpdate
27. The project builds correctly! You may have additional files/directories that need to be cleaned up or corrected. Usually compare what is in the 7.13.3 project with yours to find what’s changed.
28. Program your project in your device and verify it still works
29. It is possible that other changes to the code may be required for SmartStart, Inclusion, handling of NVM3, interrupts, peripherals and other features. Expect that it may take a day or so to resolve these problems.
30. For example, in the DoorLockKeyPad sample application, when a Z-WavePlusInfo_GET is sent, an ASSERT is executed and the CPU takes a hardfault and essentially crashes.
31. Connect the debugger using an Attach To
32. Click on Pause and the Debug pane shows the call stack which says we hit an assert within the SDK from handleCommandClassZWavePlusInfo()
33. Set a breakpoint at the start of this command and restart the debug session and resend the ZWavePlusInfo_GET which should stop the CPU at the start of the handler
34. Single step thru the code until you find the CPU in the defaultHandler again (you’ll have to click Pause)
35. The problem is that the Static structure pData is NULL and as a result the ASSERT is triggered:
    1. ASSERT(NULL != pData);
36. Looking back in the sample app we notice there is a new Init routine for this command class:
    1.   CC_ZWavePlusInfo_Init(&CCZWavePlusInfo);
    2. Which also needs a new definition:
    3. SCCZWavePlusInfo CCZWavePlusInfo = { …
    4. Adding these to the source code, recompiling and downloading and testing it now works
37. There may be several other things that need to be updated or initialized with each release so more testing and debug may be required.
38.  
39. Option C - Manually edit the .cproject and .project XML files:
40. This option uses a text editor to edit the two XML files SS uses to build your project. XML files are very picky and if you mess up the structure of the document it simply won’t work. So be very careful or go back to option A.
41. Open a new sample project in the 7.13.3 release using the same sample app you started with originally
42. Compile it and make sure it builds without error - change APP_FREQ to REGION_US (or your region) if needed
43. Close Simplicity Studio
44. The .cproject and .project are XML files which you can edit in a text editor. If you mess up the hierarchy of the file, it can make the files unusable. Editing the files is tricky so be very careful and keep backups of your work.
45. Rename the .cproject and .project files in your application directory - add .orig or .old to the filename
46. Copy the .cproject and .project files from the top level of the 7.13.3 sample app into your application directory
47. Open the two .cproject files in a text editor and diff the two files
    1. Carefully copy the few things you need from your original .cproject file into the 7.13.3 one - typically this is just a few filenames you have added to the project and other customizations
    2. You’ll see that many files are now in different directories
    3. many files now have /protocol/z-wave added or /util removed - all of these changes are necessary now that Z-Wave has been integrated with the other wireless protocols
48. Open the two .project files in a text editor and diff the two files
    1. Follow the same procedure as with the .cproject file
    2. The project name is the 3rd line of the file - this will certainly need to change
49. Open SS and select the project
50. Click on Clean Project
51. Click on Build
52. There are likely several errors usually caused by include paths not being correct
    1. Click on the Problems tab and highlight the error
    2. Go to the corresponding line in the 7.13.3 project and find the correct include path
    3. Copy that into your project properties
    4. In my trial SS was not able to find ZAF_common_helper.h
       1. Adding "${StudioSdkPath}/protocol/z-wave/ZAF/ApplicationUtilities/_commonIF" to the C include paths got it past this error
    5. Click Build
    6. Next problem is that UReceiveCmdPayload did not have a corresponding member
    7. In this case the structure has added an extra level of hierarchy so the reference changes from:
    8. RxPackage.uReceiveParams.Rx.Payload.ZW_Common.cmdClass
    9. to
    10. RxPackage.uReceiveParams.Rx.Payload.rxBuffer.ZW_Common.cmdClass
    11. Next problem is that __Vectors has conflicting types
    12. This is caused by a new Device/startup_zgm13[.S,.c] - copy these files from the 7.13.3 project into your project
    13. Click Build again
    14. Now the error is: Undefined reference to `FileSystemVerifySet' in DoorLockKeyPad.c
    15. The problem here is that the ZAF has changed how it is checking the state of the file system and using a much easier process of checking a few Tokens in NVM3. Compare the 7.13.3 sample app code and use that process instead of the one from 7.12.2.
    16. Click Build
    17. OtaInit() function has changed to CC_FirmwareUpdate_Init() which needs a 4th argument which is “true”.
    18. Click Build
    19. The project should now build correctly
    20. There are other potential problems with missing include directories,  #defines or function names that have changed. The solution is to search the new 7.13.3 project for the same area of code and identify the new directory or function name.
53. Program your project in your device and verify it still works
54. It is possible that other changes to the code may be required for SmartStart, Inclusion, handling of NVM3, interrupts, peripherals and other features. Expect that it may take a day or so to resolve these problems.
55. For example, in the DoorLockKeyPad sample application, when a Z-WavePlusInfo_GET is sent, an ASSERT is executed and the CPU takes a hardfault and essentially crashes.
56. Connect the debugger using an Attach To
57. Click on Pause and the Debug pane shows the call stack which says we hit an assert within the SDK from handleCommandClassZWavePlusInfo()
58. Set a breakpoint at the start of this command and restart the debug session and resend the ZWavePlusInfo_GET which should stop the CPU at the start of the handler
59. Single step thru the code until you find the CPU in the defaultHandler again (you’ll have to click Pause)
60. The problem is that the Static structure pData is NULL and as a result the ASSERT is triggered:
    1. ASSERT(NULL != pData);
61. Looking back in the sample app we notice there is a new Init routine for this command class:
    1.   CC_ZWavePlusInfo_Init(&CCZWavePlusInfo);
    2. Which also needs a new definition:
    3. SCCZWavePlusInfo CCZWavePlusInfo = { …
    4. Adding these to the source code, recompiling and downloading and testing it now works
62. There may be several other things that need to be updated or initialized with each release so more testing and debug may be required.

 

Another minor issue with the 7.13.3 release is that it is not properly creating the .GBL files for OTA. The fix is simple:

Modify line 46 in \SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.7\protocol\z-wave\ZAF\ApplicationUtilities\application_properties.c

from:

.type = 1<<6UL,

to:

.type = 1<<7UL,

 

My recommendation is to click on this file in the Project Explorer->ZAF_ApplicationUtilites and make the change. When you change the code, this popup comes up:

And you should click on Make A Copy.

When the next minor release comes out this will be fixed and you will then want to delete the copy and go back to the Linked version of the file. I do NOT recommend changing the files in the SDK.

This guide uses the DoorlockKeyPad build under 7.12.2 but the same basic concepts apply to any sample app and your project. A generic KBA on upgrading SDKs for Bluetooth projects provides some general insights but this document is specific to this Z-Wave release.

1. Update Simplicity Studio (SS)
   1. From the Launcher perspective, click on the download icon and then click on Update All
   2. Close Simplicity and restart (just to be safe) - SS may ask to do this as well
   3. Click on the download button again, click on Package Manager, click on SDK tab, click on each Update button (keep scrolling down). I recommend restarting SS between each update.
2. Set the Preferred SDK to the latest release
   1. Plug in a WSTK devkit or select the ZGM130S in the MyProduct window
   2. From the Launcher perspective, click here:
   3. Select the Gecko SDK Suite 7.13.3.0
   4. Now when you want to create a new project it will start with the 7.13.3 release
3. At this point there are 3 options for upgrading:
   1. Open a new 7.13.3 project and then copy your changes into it
   2. Import/Export parts of your project into a new 7.13.3 project
   3. Manually edit the .cproject and .project files
4. Far and away the best option is the first one - option A
   1. The advantage of this is that you get all the latest and newest files of the Z-Wave Application Framework (ZAF), emlib, linker scripts, and lots of other stuff
   2. The challenge is that you have to plug all of your changes back into the sample application
   3. If you’ve made most of the changes in files other than the sample application, then the changes are probably easy to install
   4. However, if you’ve made a lot of changes to the sample application source code file it will take more time
   5. Option B or C might be the way to go but at some point it might still be better to go back to option A. Option A is fairly straightforward as the sample apps in the 7.13.3 release already work so just copy in your changes a few at a time and keep recompiling to make sure you haven’t broken something.
   6. If taking option A you’re done! No need to read any further! Create the new sample app and start plugging in your changes
   7. If you’re not taking option A, pick one of the 2 options below. The choice of B or C is up to you and primarily how confident you are in fixing XML files. If you think you can fix an XML file, then use option C otherwise use B.
5. Option B - Import/Export parts of your project into a new 7.13.3 project:
6. This option avoids manually editing the XML file but requires importing/exporting several files and using the GUI to fix paths. The advantage however is that you shouldn’t break the XML file which is easily done with manual editing.
7. Export the project created with Z-Wave 12.2 SDK using [File] > [Export...].
8. Window->Preferences->SimplicityStudio->SDKs
   1. Remove the 7.1x.xx SDKs from the Simplicity Studio SDK preferences
   2. This does not delete or uninstall the actual SDK, just removes it from the current workspace settings so it will not be used during the project import step
9. Import the .sls file created with the export. ([File] > [Import...]) above
10. Right click the project from the IDE perspective
11. Project Properties [C/C++ Build] > [Board / Part / SDK] and select the Gecko SDK Suite: 7.13.3.0, Flex 2.7.3 from the dropdown list
12. When it asks to Rebuild Now - click on YES!
13. The build will fail because the Linker script location has changed from:
    1. ${StudioSdkPath}/ZWave/linkerscripts/zgm13-zw700.ld
    2. to
    3. ${StudioSdkPath}/protocol/z-wave/ZWave/linkerscripts/zgm13-zw700.ld
    4. Right click on the project
    5. Properties->C/C++ Build->Settings->Memory Layout
    6. Change the linker script location as shown here
14. Try to Build again but now there are all sorts of problems with basic things like SizeOf.h cannot be found. This is caused by the change in the directory structure for the SDK.
15. In the 7.13.3 project - right click on the project->properties->C/C++ General->Paths and Symbols and click on EXPORT Settings
16. Export them all to a temporary file - IE:Seven13Paths.xml
17. Return to the same screen in your project, <CTL-A> to select all the paths then Delete
18. Then click on Import Settings and select the Seven13Paths.xml file
19. Build again and you should get a “conflicting types for __Vectors” error
    1. This is caused by a new Device/startup_zgm13[.S,.c] - copy these files from the 7.13.3 project into your project
20.  Build again and you get an error “No rule to make target libZWaveSlave.a”.
21. Right click properties->C/C++Build/Settings->GNU ARM C Linker->Other objects
22. Change
    1. ${StudioSdkPath}/ZWave/lib/libZWaveSlave.a
    2. to
    3. ${StudioSdkPath}/protocol/z-wave/ZWave/lib/libZWaveSlave.a
    4. and
    5. ${StudioSdkPath}/SubTree/rail-import/platform/radio/rail_lib/autogen/librail_release/librail_efr32xg13_gcc_releasa
    6. to
    7. ${StudioSdkPath}/platform/radio/rail_lib/autogen/librail_release/librail_efr32xg13_gcc_release.a
23. If other errors turn up, try doing a Clean Project and exit SS and start it up again
24. Click Build
    1. OtaInit() function has changed to CC_FirmwareUpdate_Init() which needs a 4th argument which is “true”.
25. Click Build
    1. The error is: Undefined reference to `FileSystemVerifySet' in DoorLockKeyPad.c
    2. The problem here is that the ZAF has changed how it is checking the state of the file system and using a much easier process of checking a few Tokens in NVM3. Compare the 7.13.3 sample app code and use that process instead of the one from 7.12.2. Basically, delete (or #if 0/#endif) several lines of code.
26. Click Build
    1. The error is: Undefined Reference to CC_FirmwareUpdate_InvalidateImage
    2. The confusing part of this error is that you can click on this function and it will open the correct file. The problem is that it is not included in the project.
    3. The problem is there are 2 new Linked files - btl_reset_cause_util.[c,h].
    4. Copy via a link into the ZAF_CommandClasses_FirmwareUpdate
27. The project builds correctly! You may have additional files/directories that need to be cleaned up or corrected. Usually compare what is in the 7.13.3 project with yours to find what’s changed.
28. Program your project in your device and verify it still works
29. It is possible that other changes to the code may be required for SmartStart, Inclusion, handling of NVM3, interrupts, peripherals and other features. Expect that it may take a day or so to resolve these problems.
30. For example, in the DoorLockKeyPad sample application, when a Z-WavePlusInfo_GET is sent, an ASSERT is executed and the CPU takes a hardfault and essentially crashes.
31. Connect the debugger using an Attach To
32. Click on Pause and the Debug pane shows the call stack which says we hit an assert within the SDK from handleCommandClassZWavePlusInfo()
33. Set a breakpoint at the start of this command and restart the debug session and resend the ZWavePlusInfo_GET which should stop the CPU at the start of the handler
34. Single step thru the code until you find the CPU in the defaultHandler again (you’ll have to click Pause)
35. The problem is that the Static structure pData is NULL and as a result the ASSERT is triggered:
    1. ASSERT(NULL != pData);
36. Looking back in the sample app we notice there is a new Init routine for this command class:
    1.   CC_ZWavePlusInfo_Init(&CCZWavePlusInfo);
    2. Which also needs a new definition:
    3. SCCZWavePlusInfo CCZWavePlusInfo = { …
    4. Adding these to the source code, recompiling and downloading and testing it now works
37. There may be several other things that need to be updated or initialized with each release so more testing and debug may be required.
38.  
39. Option C - Manually edit the .cproject and .project XML files:
40. This option uses a text editor to edit the two XML files SS uses to build your project. XML files are very picky and if you mess up the structure of the document it simply won’t work. So be very careful or go back to option A.
41. Open a new sample project in the 7.13.3 release using the same sample app you started with originally
42. Compile it and make sure it builds without error - change APP_FREQ to REGION_US (or your region) if needed
43. Close Simplicity Studio
44. The .cproject and .project are XML files which you can edit in a text editor. If you mess up the hierarchy of the file, it can make the files unusable. Editing the files is tricky so be very careful and keep backups of your work.
45. Rename the .cproject and .project files in your application directory - add .orig or .old to the filename
46. Copy the .cproject and .project files from the top level of the 7.13.3 sample app into your application directory
47. Open the two .cproject files in a text editor and diff the two files
    1. Carefully copy the few things you need from your original .cproject file into the 7.13.3 one - typically this is just a few filenames you have added to the project and other customizations
    2. You’ll see that many files are now in different directories
    3. many files now have /protocol/z-wave added or /util removed - all of these changes are necessary now that Z-Wave has been integrated with the other wireless protocols
48. Open the two .project files in a text editor and diff the two files
    1. Follow the same procedure as with the .cproject file
    2. The project name is the 3rd line of the file - this will certainly need to change
49. Open SS and select the project
50. Click on Clean Project
51. Click on Build
52. There are likely several errors usually caused by include paths not being correct
    1. Click on the Problems tab and highlight the error
    2. Go to the corresponding line in the 7.13.3 project and find the correct include path
    3. Copy that into your project properties
    4. In my trial SS was not able to find ZAF_common_helper.h
       1. Adding "${StudioSdkPath}/protocol/z-wave/ZAF/ApplicationUtilities/_commonIF" to the C include paths got it past this error
    5. Click Build
    6. Next problem is that UReceiveCmdPayload did not have a corresponding member
    7. In this case the structure has added an extra level of hierarchy so the reference changes from:
    8. RxPackage.uReceiveParams.Rx.Payload.ZW_Common.cmdClass
    9. to
    10. RxPackage.uReceiveParams.Rx.Payload.rxBuffer.ZW_Common.cmdClass
    11. Next problem is that __Vectors has conflicting types
    12. This is caused by a new Device/startup_zgm13[.S,.c] - copy these files from the 7.13.3 project into your project
    13. Click Build again
    14. Now the error is: Undefined reference to `FileSystemVerifySet' in DoorLockKeyPad.c
    15. The problem here is that the ZAF has changed how it is checking the state of the file system and using a much easier process of checking a few Tokens in NVM3. Compare the 7.13.3 sample app code and use that process instead of the one from 7.12.2.
    16. Click Build
    17. OtaInit() function has changed to CC_FirmwareUpdate_Init() which needs a 4th argument which is “true”.
    18. Click Build
    19. The project should now build correctly
    20. There are other potential problems with missing include directories,  #defines or function names that have changed. The solution is to search the new 7.13.3 project for the same area of code and identify the new directory or function name.
53. Program your project in your device and verify it still works
54. It is possible that other changes to the code may be required for SmartStart, Inclusion, handling of NVM3, interrupts, peripherals and other features. Expect that it may take a day or so to resolve these problems.
55. For example, in the DoorLockKeyPad sample application, when a Z-WavePlusInfo_GET is sent, an ASSERT is executed and the CPU takes a hardfault and essentially crashes.
56. Connect the debugger using an Attach To
57. Click on Pause and the Debug pane shows the call stack which says we hit an assert within the SDK from handleCommandClassZWavePlusInfo()
58. Set a breakpoint at the start of this command and restart the debug session and resend the ZWavePlusInfo_GET which should stop the CPU at the start of the handler
59. Single step thru the code until you find the CPU in the defaultHandler again (you’ll have to click Pause)
60. The problem is that the Static structure pData is NULL and as a result the ASSERT is triggered:
    1. ASSERT(NULL != pData);
61. Looking back in the sample app we notice there is a new Init routine for this command class:
    1.   CC_ZWavePlusInfo_Init(&CCZWavePlusInfo);
    2. Which also needs a new definition:
    3. SCCZWavePlusInfo CCZWavePlusInfo = { …
    4. Adding these to the source code, recompiling and downloading and testing it now works
62. There may be several other things that need to be updated or initialized with each release so more testing and debug may be required.

 

Another minor issue with the 7.13.3 release is that it is not properly creating the .GBL files for OTA. The fix is simple:

Modify line 46 in \SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.7\protocol\z-wave\ZAF\ApplicationUtilities\application_properties.c

from:

.type = 1<<6UL,

to:

.type = 1<<7UL,

 

My recommendation is to click on this file in the Project Explorer->ZAF_ApplicationUtilites and make the change. When you change the code, this popup comes up:

And you should click on Make A Copy.

When the next minor release comes out this will be fixed and you will then want to delete the copy and go back to the Linked version of the file. I do NOT recommend changing the files in the SDK.

I ran into this same problem. The issue is that in SPI mode the TX pin is used as the data input when in slave mode.

So MOSI is in fact the pin you want.

In my case I used: 

        USART1->ROUTELOC0 = (USART_ROUTELOC0_CLKLOC_LOC9) | // US1_CLK       on location 9 = PC6 per datasheet section 6.2
                            (USART_ROUTELOC0_TXLOC_LOC12) | // US1_TX (MOSI) on location 14 = PC7 - in SPI slave mode (Master=0) this is the datain
                            (USART_ROUTELOC0_CSLOC_LOC0 );// | // US1_CS        on location 0 = PA3

        USART1->ROUTEPEN = USART_ROUTEPEN_CLKPEN | USART_ROUTEPEN_CSPEN | USART_ROUTEPEN_TXPEN;

Which seems backwards as you're using TXPEN to enable the data input. But it works.

Looks like your UZB7 already the SerialAPI in it and thus is a binary protocol. Details on the SerialAPI can be found here: https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf

You'll only get ASCII text if the Bootloader is running on the UZB7 and it doesn't have the SerialAPI firmware loaded into it.

We’re all trying to make the Smart Home products smaller and less visible. Using coin cells instead of bulky cylindrical batteries significantly reduces the size of many products. The challenge with making products smaller is that the area available on the PCB for a debug header is in short supply.

Many customers I’ve worked with want to use less PCB real estate which means they come up with a custom set of test points. Typically a jig with spring loaded pins are used to contact to the PCB or more often wires are soldered to the PCB. The problem with this solution is that the jig is large, expensive and fragile. Soldering a cable to a board often results in a fragile connection where the cable can easily break a pin and not be immediately obvious. I’ve spent far too much time trying to figure out why I could program the part a minute ago but now I can’t only to realize the cable has a loose wire.

700 Series Debug Header

Fortunately Silicon Labs has a solution for the 700 series – use a 0.05″ spacing 10 pin SMT header. The Mini Simplicity Debug connector is described in AN958. If you have a little room then use the standard SMT header which is 6x6mm. If you are very tight on real estate then put down the pads for the thru-hole version of the connector but hand-solder the thru-hole header to the pads. Using just the pads results in a header only 3x6mm. You can’t tell me you can’t come up with 18sqmm to make the PCB debug reliable!

Either solution requires only a small amount of space on a single side of the PCB. Usually the header pads can be under a coin cell since during debug a power supply is used instead of the battery. This same header can be used for production programming using a jig to contact to the pads. Having a standard and reliable connection to the PCB will save you time during debug and on the production floor.

Conclusion

No matter how tempted you might be to come up with your own cable/connector/test points, DON’T DO IT! Use the standard Mini Simplicity connector to save you so many headaches during debug. A solid, reliable debug connection is an absolute must otherwise you risk spinning your wheels chasing ghosts that are caused by a flakey connector. Take it from me, I’ve tried to debug just way too many of these over the years and it is not fun.

This article was also published on my blog at DrZWave.blog.

Piz Wang, No, 700 series does not support OTW. Instead you use commander to program the ZGM130 or EFRZG14 using the normal ARM programming pins. This makes the chip cheaper because it does not have to have double the flash to hold the OTW image. Instead it is up to the host to store the image and then just reprogram the 700 series chip.

I have a somewhat easier method. Below are two scripts you can use. 

1) GenGblToken.bat is run ONCE when you first create the project. And then is NEVER run again!

2) Build the application with the new tokens and program into the DUT via JLink (hardwire)

3) run PgmToken.bat to program the tokens into the DUT. You run this with EVERY DUT you build/ship.

Then you can OTA the files with the fully encrypted and signed keys and you know your firmware is protected.

 

Note that it is VERY important to change the Post-Build step in Simplicity Studio as described in GenGblToken.bat

While these are Windows batch files the commands are basically the same for other platforms - just change REM to # or whatever comment character is needed.