Gocator Development Kit
 All Classes Files Functions Variables Typedefs Friends Modules Pages
Getting Started

The Gocator Development Kit (GDK) provides a complete framework for the development, testing and deployment of custom Gocator firmware.

Using this kit, custom firmware upgrade packages containing custom tools can be generated and loaded onto sensors.

Build Pre-requisites

The GDK prerequisites package can be downloaded from the LMI website.

New versions are made available when the GDK dependencies change.

The GDK build system has the following pre-requisites:

  • Microsoft Visual Studio 2017 (Windows SDK 10.0.15063.0)
  • Python 3.4 or later
  • For Sensor builds:
    • GCC ARM7 tools 4.9.4-p23
    • GCC C64x tools 4.9.4-p23
    • Texas Instruments C6000 Code Generation Tools 7.4.13
    • Texas Instruments BIOS 6.42.03.35
    • GCC ARM8 tools 4.9.4-p13
    • GCC X64 tools 4.9.4-p23

Visual Studio 2017

Microsoft Visual Studio 2017 is needed for development and debugging. Debugging is supported only for Desktop targets (i.e. Win32/x64). No debugging support is provided for the embedded targets.

Make sure to select at least the following options from the "Workloads" tab:

  • Windows
    • Universal Windows Platform development
    • Desktop development with C++
    • .NET desktop development

Navigate to the "Individual components" tab and add the following options:

  • Compilers, build tools and runtimes
    • Visual C++ runtime for UWP
    • Windows Universal CRT SDK
  • Debugging and testing
    • Testing tools core features
  • SDKs, libraries and frameworks
    • MFC and ATL (x86 and x64)
    • Windows Universal C Runtime
    • Windows 10 SDK (10.0.15063.0) for UWP: C++

Python

The build steps for the GDK are automated using the Python programming language. The Python distribution can be downloaded for free. Use Python version 3.4 or later. After installation make sure the python.exe is in the %PATH% environment variable.

Link: https://www.python.org/downloads/

GCC tools

The GCC ARM7 tools are distributed as an installer for Windows and need to be installed at C:\tools\GccArm7_4.9.4-p23 by choosing the default installation path.

Installer: GccArm7_4.9.4-p23_55732ba7.exe

The GCC C64X tools are distributed as an installer for Windows and need to be installed at C:\tools\GccC64x_4.9.4-p23 by choosing the default installation path.

Installer: GccC64x_4.9.4-p23_55732ba7.exe

The GCC ARM8 tools are distributed as an installer for Windows and need to be installed at C:\tools\GccArm8_4.9.4-p13 by choosing the default installation path.

Installer: GccArm8_4.9.4-p13_8758.exe

The GCC X64 tools are distributed as an installer for Windows and need to be installed at C:\tools\GccX64_4.9.4-p23 by choosing the default installation path.

Installer: GccX64_4.9.4-p23_55732ba7.exe

TI C6000 Code Generation Tools

The Texas Instruments C6000 Code Generation Tools 7.4.13 need to be installed at C:\ti\cgtools_7.4.13.

Installer: ti_cgt_c6000_7.4.13_windows_installer.exe

TI BIOS

The Texas Instruments BIOS package needs to be installed at C:\ti\bios_6_42_03_35.

Installer: bios_setupwin32_6_42_03_35.exe

Sample

A sample project can be found under Gocator\GdkAppSample. This project can be built and used directly. It can also serve as a template for new projects.

The supplied sample project will build either a win32/x64 DLL (for use with the emulator) or a sensor firmware upgrade package.

The dlls should start with GdkApp.

After compiling for the sensor, GdkAppSample.xml should be copied to the /pkg folder and renamed with the name of the new tool.

Defining library information

The library name is defined by the assembly object name. The assembly object name can be defined by modifying Asm.x.h and Asm.c in the sample project. This is useful so that libraries can be uniquely distinguished and versioned. By default, ToolAsm is used as the GDK library name, all instances of ToolAsm must be replaced in three files; Asm.x.h, Asm.h and Asm.c

In Asm.x.h the assembly declaring macro takes a variable that is used as the library name. ToolAsm is used as the default assembly name, this can be modified to rename the library. This name must be the same as the one specified in Asm.h and Asm.c.

The version is also defined here as TOOL_VERSION:

#define TOOL_VERSION kVersion_Stringify_(1, 0, 0, 0) // Specify version here.
kDeclareAssemblyEx(Tool, ToolAsm) // "ToolAsm" is the name of this GDK library.

In Asm.h, the GDK library constructor is declared. ToolAsm is used as the prefix of the constructor, this can be modified to rename the library. This name must be the same as the one specified in Asm.x.h and Asm.c.

kBeginAssemblyEx(Tool, ToolAsm, TOOL_VERSION, GOCATOR_VERSION) // "ToolAsm" is the name of this GDK library.
.
.
.
kExtern kStatus kCall GoSensorAppLib_ConstructAssembly(kAssembly* userAsm)
{
return ToolAsm_Construct(userAsm); // "ToolAsm" is the name of this GDK library.
}

In Asm.c the assembly begin macro takes a variable that is used as the library name. ToolAsm is used as the default assembly name, this can be modified to rename the library. This name must be the same as the one specified in Asm.x.h and Asm.h.

kBeginAssemblyEx(Tool, ToolAsm, TOOL_VERSION, GOCATOR_VERSION) // "ToolAsm" is the name of this GDK library.
.
.
.
kExtern kStatus kCall GoSensorAppLib_ConstructAssembly(kAssembly* userAsm)
{
return ToolAsm_Construct(userAsm); // "ToolAsm" is the name of this GDK library.
}

Building a GDK application

  • Open the GDK Visual Studio solution, i.e. Gocator\Gdk.sln
  • Choose your target:
    • Select Win32 for 32 bit platform debugging and emulation
    • Select x64 for 64 bit platform debugging and emulation
    • Select Sensor for Gocator devices
  • Build the solution using <CTRL>+<Shift>+B

Running a GDK application

Debugging using the emulator

  1. Build virtual device using a Win32/x64 target.
  2. If target is Win32, make sure the output file is built into bin\win32 or bin\win32d
  3. If target is x64, make sure the output file is built into bin\win64 or bin\win64d

The emulator will now use the custom GDK module when emulating scenarios. It is possible to attach a debugger to the kFramework.exe process at run time for debugging.

Using a Gocator sensor

Custom upgrade packages are built into the pkg directory. These upgrade packages can be loaded to a Gocator sensor using the firmware upgrade process.

Recover from bad firmware

Use the following steps to recover from bad firmware:

  • Power off the device
  • Make sure the device is directly connected to the PC – don't use a switch
  • Configure the PC as to use IP-address: 192.168.1.1 and netmask: 255.255.0.0
  • Start the kRescue application bin\win32\kRescue.exe
  • Power on the device
  • Close the kRescue application
  • Open a browser and point it to http://192.168.1.10
  • Apply an upgrade package that is known to work