As many of you have noticed, www.elkhorn-creek.org has been offline for quite a while (actually since December 22,2018).  I know that many of you have really missed knowing how much water is in the creek.  Given that it blew up in December, and I knew that I was going to have to crawl into the muddy creek to fix it, I had not gotten around to it.  But, now it is July and the water is nice, so I don’t have much of an excuse.  I have written extensively about my system, in fact, it was my first real IoT project.  I assumed that it would not be that hard to fix.  Boy was I wrong.

In this article I will:

• Get the Sensor out of the Elkhorn Creek & Debug
• Update the PSoC Project to use a Different GPIO
• Blow up the CyPi Power Supply
• Debug the Wrong Pressure Sensor
• Turn the Raspberry Pi Back on and Retest

Get the Sensor out of the Creek and Debug

I felt like Stanley in the Congo heading down the path to the Elkhorn Creek.

But, when you get there, look how beautiful it is.

Here is a picture looking down at the sensor setup from the top of the bank (that is a 6 foot ladder, so that bank is something like 10 feet high)

When you slide down the bank onto the ladder, this is where you end up.  After I jumped off the ladder into the creek, I was in mud up to my knees.  I had assumed that the problem was that water had leaked around sensor NPT connection.  You can see the drain valve that I installed to drain water out of the pipe for just that case.  When I opened the valve, there was no water… like none. This made me start to wonder what was going on.  The sensor is installed in the end of that square clear out.

When I undid the sensor and brought it up into my lab, there was no leaking around the sensor.  My original theory that the sensor had gotten water onto the dry side was incorrect.

So, I plugged the sensor in on my bench to try to figure out what was going on.

The first measurement I took was across the 51.1 ohm sensor resistor.  Last time I checked, V=IR, so this means that it is drawing 133mA.  That is bad given that it is a 4-20mA current loop.

It is also bad to put 6.81V onto a PSoC pin.  When I measure the voltage at the pin it is 0.003 V.  Dead.  At this point, I suspect that whatever killed the sensor also killed the PSoC, but I don’t know.  I suppose that the sensor could have blown up (maybe an ESD event) and then when the voltage went to 6.81, it blew up the PSoC?  I suppose that I will never know.

In fact, when I connect the power supply directly to the A0/P2[0] analog input, I get 0.023A … which means that I also blew up the GPIO and it is now shorted to ground.  Well, actually it isn’t a short, it is more like 43 Ohm resistor.  Bad.

Here is the spec from the PSoC 4 data sheet.  2mA is a long long way from 2nA.

Unfortunately, this is the only CyPi board that I have.  Moreover, I don’t have another PSoC4 chip to fix it with (or at least at my house right now).  So, I decided that I will assume that the other pins are OK and I will use PSoC Creator to move to another pin (A2) that hopefully isn’t blown up.  To do this, I snip off the Arduino pin, then solder a jumper on the top from A0 to A2.

Update the PSoC Project to use a Different GPIO

Next, I have to fix the firmware to use A2 instead of A0.  This is AKA P2[2] instead of P2[0].  When I open up the workspace in PSoC Creator, it immediately starts complaining about components that are old.  Notice that all of the “dwr’s” which are opened have an asterisk indicating they have changed.  In order to fix this I need to update all of the components.

Starting with the boot loader project called “p4bootloader”, right click and select “Update Components…”

Notice that eight of the components in the project are old.  Select Next.

Then turn off the “create a workspace archive before updating option”.  My project is in Git so I don’t need to save it in case something bad happens.  Then click Finish.

And after a minute I can Build the project.

Next I update the main project which is called “p4arduino-creek”

Follow the same process as before:

In this case I forget to click the archive button, but I can cancel the archive.

Once the update is done, look at the schematic.  The first thing that I notice is that I called the pressure input “high side”.  I hate the name high side… so I am going to fix it to be called pressure

Double click the pin and change it to “pressure”

Because the boot loader hex changed, I need to update the reference in the bootloadable component.  Double click it and correct the path.

Notice that it has a new version of the compiler.

Then reassign the pressure pin to be P2[2] which is also known as A2

Then rebuild and notice that everything is OK.

Once I reprogram the board, I take it outside to reinstall the whole mess.  After I hook it up I start probing with the multimeter and immediately short out the power supply with one of the multi-meter probes.

Blow up the CyPi Power Supply

Which blows up the REG1117.  Here is an animated GIF where you can see that it turns on.. then immediately goes off.  This is more than a little bit annoying.

Fortunately, I have my original CyPi prototype.  So, I go back to the prototype CyPi – which means that I have to use two power supply connections.  One of the things that I fixed in the final CyPI was to have the ability to drive the Raspberry Pi with the 12V input (I have ordered a new REG 1117).

Debug the Wrong Pressure Sensor

When I install everything, an unbelievably frustrating thing happens. I put the probe on the sensor and I immediately measure 1.007V  which is 19.7 mA which is also known as 14.7346 PSI.  This is seriously bad.  I have been standing in mud up to my knees fixing the damn system and it is already broken again.  I should be measure 4mA*51.ohm = .202V.  But no.  This was a deeply frustrating moment because I assumed that something else is wrong with my system.

When I got back inside and tried to figure out what in the world was happening, I thought, maybe the pressure sensor is clogged or something?  This made me wonder what the air pressure in Kentucky at that moment was.  After a little bit of google I find that the air pressure is 30 inches of Hg… which turns out to be … guess… 14.7 PSI.  I knew immediately that I purchased the WRONG DAMN SENSOR.

Measurement Specialties makes the US381 in both Gauge and Absolute pressure.  In the Absolute case, it gives you the pressure with a reference to a vacuum.  In the gauge case it gives you a relative measurement.  The back side of this pressure sensor is exposed to the air, which lets it cancel out atmospheric pressure changes.  But I bought US381-000005-015PA instead of the correct US381-000005-015PG.

And, a few days later Mouser delivered me the correct sensor, and after and hour of mud and sweat I had things ready to try again.

Turn the Raspberry Pi Back on and Retest

After re-installing everything in the barn, I now get .202V across the 51.1 Ohm Sensor Resistor, which means that I am getting exactly 4mA.  That makes perfect sense as right now the pressure sensor is just exposed to the air. (meaning it is sticking out of the water)

And now www.elkhorn-creek.org is working again.  Good.

On the days that my newspaper carrier decides to deliver the newspaper, you can be sure that it won’t be there before 4:00am or after 10:00am.  Why do I still get a newspaper?  Because my wife likes it.  The status of the delivery is a constant source of speculation in the morning.  Have you been out to the newspaper box?  Will you go?  etc.  So it seems only logical to make an IoT device that figures out if I have a newspaper.  Obviously this is a bit silly to put as much time and effort as I have into that simple task.  But, doing something cool has it own worth.  And it will give me a chance to use the new WICED XR (extended range) Bluetooth radio module CYBT-483039-02.

And here is a picture of the new module on the CYBT-483039-EVAL EZ-BT evaluation kit.

For this design I want

1. A newspaper sensor (not sure what that will be)
2. Waterproof case
3. A temperature sensor
4. A custom circuit board
5. A solar battery charger
6. The ability to program and debug the 20719 (which will be acting as a beacon)
7. An OTA Bootloader
8. A Real Time Clock
9. A wifi/ble bridge (inside the house)
10. Some cloud data capture and display
11. An iOS App

So far, this project has been quite a rabbit hole as I don’t/didn’t know anything about battery power supplies.  Specifically energy harvesting solar powered lithium ion battery chargers and system power supply.  Unfortunately Cypress doesnt make an IC that performs this application … so if you send Mouser a few hundred dollars and they will send you a box of a bunch of different Solar PMIC Evaluation kits, ST, TI, Linear, Analog Devices, and Microchip. (which I will write about in detail later)

Architecture

Here is a picture of the architecture.

In the next Article I will start the process of learning about Solar Battery Charging PMICs.

Summary

You probably noticed and wondered “Why did he use WICED_LED_2 instead of WICED_LED_1”?  The answer to that question is that by default the CYW920719Q40EVB_01 is setup with WICED_LED_2 enabled as a GPIO and WICED_LED_1 used for another purpose.  But to what purpose?  In this lesson we will answer the questions:

1. What are the default pins?
2. How do you use the SuperMux tool?
3. How do you use a PWM?

To do this we are going to copy the L2_HelloWorld project and add a PWM to drive the Green LED also known as WICED_LED_1.

The steps we are going to follow are

1. Copy the L2_HelloWorld to start a new project called L3_SuperMux
2. Rename L2_HelloWorld.c
3. Fix the makefile.mk for the updated source file
4. Create a new make target
5. Program to make sure everything is still working
6. Look at the platform files for CYW920719Q40EVB_01
7. Run  the SuperMux Tool
8. Delete the SPI Slave_1 From the SuperMux
9. Add an LED to the SuperMux
10. Configure the LED to P28
11. Apply the SuperMux configuration
12. Look at the new files added to the project
13. Look a the makefile.mk
14. Look L3_SuperMux_pin_config.c
15. Update L3_SuperMux.c to have correct includes
16. Update L3_SuperMux.c to start the clock, pin and PWM
17. Program the project
18. Look at the Hardware Abstraction Layer Documentation

Copy L2_HelloWorld –> L3_SuperMux

Instead of starting from a blank project.  Lets make a copy of the L2_HelloWorld project.  If you right click on the L2_HelloWorld folder and select copy

Then click on the “wiced_bt_class” folder and select paste.

WICED Studio will then complain that you already have a directory called “L2_HelloWord” and give you the opportunity to rename it.  Call the new project “L3_SuperMux”

Now you need to rename the L2_HelloWorld.c to be L3_SuperMux.c.  Right click on the L2_HelloWorld.c and select rename

Then give it a new file name… like L3_SuperMux.c

Double click makefile.mk and edit it.  You need to change the comment, and the name of the APP_SRC source file.

#
# Lesson 3 - SuperMux
#
APP_SRC +=  L3_SuperMux.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE

Create a make target for this project by right clicking the L2_HelloWorld Make Target, then selecting “New”

That will make a new target… and it will bring up this dialog box.  Notice that it named the target “Copy of …”

Fix it to be “L3_SuperMux” like this:

You should now have an exact copy of L2_HelloWorld, in the project L3_SuperMux.  Double click the make target and make sure that things are still working.  When you build you should get this.  Don’t forget to “Start the Bootloader” if the programming doesn’t work.

Platform Files

If you look on the back of your CYW920719Q40EVB-01 development kit you will find the exact pin map of this board.  On this picture you can see that LED1 is connected to P28

In WICED Studio, the world “Platform” is just another word for Board Support Package.  Basically all of the configuration required to build the firmware for a specific board.  If you click on platforms you will find a directory for the CYW920719Q40EVB.  All of the default configuration for the pins are located in the file “wiced_platform_pin_config.c”

If you look at this file closely, you will see on line 47 that pin P28 is setup as the MOSI of WICED_SPI_1.  That isnt a GPIO!!!.  And you will see a whole block of code on line 74 that is commented out that COULD   configure P28 as a GPIO.  But that would require modifying our default platform files, which I dont want to do.  Now what?  Simple use the SuperMux tool.

/* all the pins available on this platform and their chosen functionality */
const wiced_platform_gpio_t platform_gpio_pins[] =
    {
        [PLATFORM_GPIO_0 ] = {WICED_P00, WICED_GPIO              },      //Button
        [PLATFORM_GPIO_1 ] = {WICED_P01, WICED_SPI_1_MISO        },
        [PLATFORM_GPIO_2 ] = {WICED_P02, WICED_PCM_OUT_I2S_DO    },
        [PLATFORM_GPIO_3 ] = {WICED_P04, WICED_PCM_IN_I2S_DI     },
        [PLATFORM_GPIO_4 ] = {WICED_P06, WICED_GCI_SECI_IN       },
        [PLATFORM_GPIO_5 ] = {WICED_P07, WICED_SPI_1_CS          },
        [PLATFORM_GPIO_6 ] = {WICED_P10, WICED_GCI_SECI_OUT      },
        [PLATFORM_GPIO_7 ] = {WICED_P16, WICED_PCM_CLK_I2S_CLK   },
        [PLATFORM_GPIO_8 ] = {WICED_P17, WICED_PCM_SYNC_I2S_WS   },
        [PLATFORM_GPIO_9 ] = {WICED_P26, WICED_GPIO              },      //Default LED 2
        [PLATFORM_GPIO_10] = {WICED_P25, WICED_I2C_1_SCL         },
        [PLATFORM_GPIO_11] = {WICED_P28, WICED_SPI_1_MOSI        },      //Optional LED 1
        [PLATFORM_GPIO_12] = {WICED_P29, WICED_I2C_1_SDA         },
        [PLATFORM_GPIO_13] = {WICED_P33, WICED_UART_2_TXD        },
        [PLATFORM_GPIO_14] = {WICED_P34, WICED_UART_2_RXD        },
        [PLATFORM_GPIO_15] = {WICED_P38, WICED_SPI_1_CLK         },
    };

/* LED configuration */
const wiced_platform_led_config_t platform_led[] =
    {
        [WICED_PLATFORM_LED_2] =
            {
                .gpio          = (wiced_bt_gpio_numbers_t*)&platform_gpio_pins[PLATFORM_GPIO_9].gpio_pin,
                .config        = ( GPIO_OUTPUT_ENABLE | GPIO_PULL_UP ),
                .default_state = GPIO_PIN_OUTPUT_HIGH,
            },

// We can use either LED1 or SPI1 MOSI, by default we are using WICED_P28 for SPI1 MOSI,
// uncomment the following initialization if WICED_P28 is to be used as an LED and set PIN
// functionality in platform_gpio_pins as WICED_GPIO

//        [WICED_PLATFORM_LED_1] =
//            {
//                .gpio          = (wiced_bt_gpio_numbers_t*)&platform_gpio_pins[PLATFORM_GPIO_11].gpio_pin,
//                .config        = ( GPIO_OUTPUT_ENABLE | GPIO_PULL_UP ),
//                .default_state = GPIO_PIN_OUTPUT_HIGH,
//            }
    };

SuperMux Tool

The SuperMux tool is a GUI for setting the default configurations of the Pins on the chip.  Like all capable MCUs, this chip has PWMs, SPIs, UARTs, GPIOs, I2C, ADCs etc.  Each pin on the chip can do a bunch of different functions, but only one at a time.  Each pin has a multiplexor in front of it that selects the function of that pin.  The SuperMux tool helps you setup the multiplexors for each pin on the chip.

To run the SuperMux tool, first click on your project directory (remember L3_SuperMux).  The select File–>New–>WICED SuperMux GPIO Pin Configuration

It will ask you which “App Name” you want it to work on.  Since we clicked on the L3_SuperMux app, it uses that name by default.  Press Next

The SuperMux Wizard will give you the opportunity to select which pins you want to configure.  It also shows you the default configuration of each of the pins.  In this case just press “Next” because we want to configure them all.

Now you will see the functions of the chip and which pins they are assigned to.  Notice that WICED_P28 is assigned as the MOSI of SPI(Slave)_1.  We don’t want that.

Remove the SPI(Slave)_1 by selecting it and then pressing the “Remove” button

Now your screen will look like this.  In order to add a new pin configuration you can press the little “+” at the bottom of the function column.

Next press the little “+” button and select LED.

The select which Pin you want assigned to the LED.  In this case we want WICED_P28

After you press finish you will notice that it adds a several files to your project.  And you notice that it creates a file called “makefile.mk.bak” (which is the backup of the original makefile)

First look at the makefile and notice that it added the “L3_SuperMux_pin_config.c” to the sources and added a CFLAG

#
# Lesson 3 - SuperMux
#
APP_SRC +=  L3_SuperMux.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE
C_FLAGS += -DSMUX_CHIP=$(CHIP)
APP_SRC += L3_SuperMux_pin_config.c

So, what is up with the  L3_SuperMux_pin_config.c.  OH!!! I See, this is just a replacement for the default platform configuration.  Notice that P28 is now a WICED_GPIO and that it is now defined in the LED list.

wiced_platform_gpio_t platform_gpio_pins[]=
	{
		[PLATFORM_GPIO_0]	= {WICED_P00, WICED_GPIO},
		[PLATFORM_GPIO_1]	= {WICED_P02, WICED_PCM_OUT_I2S_DO},
		[PLATFORM_GPIO_2]	= {WICED_P04, WICED_PCM_IN_I2S_DI},
		[PLATFORM_GPIO_3]	= {WICED_P06, WICED_GCI_SECI_IN},
		[PLATFORM_GPIO_4]	= {WICED_P10, WICED_GCI_SECI_OUT},
		[PLATFORM_GPIO_5]	= {WICED_P16, WICED_PCM_CLK_I2S_CLK},
		[PLATFORM_GPIO_6]	= {WICED_P17, WICED_PCM_SYNC_I2S_WS},
		[PLATFORM_GPIO_7]	= {WICED_P25, WICED_I2C_1_SCL},
		[PLATFORM_GPIO_8]	= {WICED_P26, WICED_GPIO},
		[PLATFORM_GPIO_9]	= {WICED_P28, WICED_GPIO},
		[PLATFORM_GPIO_10]	= {WICED_P29, WICED_I2C_1_SDA},
		[PLATFORM_GPIO_11]	= {WICED_P33, WICED_UART_2_TXD},
		[PLATFORM_GPIO_12]	= {WICED_P34, WICED_UART_2_RXD},
	};

const wiced_platform_button_config_t platform_button[WICED_PLATFORM_BUTTON_MAX]=
	{
		[WICED_PLATFORM_BUTTON_1] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_0].gpio_pin,
				.config			= (GPIO_INPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_LOW,
				.button_pressed_value	= GPIO_PIN_OUTPUT_LOW,
			},
	};

const size_t button_count =  (sizeof(platform_button) / sizeof(wiced_platform_button_config_t));


const wiced_platform_led_config_t platform_led[WICED_PLATFORM_LED_MAX]=
	{
		[WICED_PLATFORM_LED_1] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_9].gpio_pin,
				.config			= (GPIO_OUTPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_HIGH,
			},
		[WICED_PLATFORM_LED_2] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_8].gpio_pin,
				.config			= (GPIO_OUTPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_HIGH,
			},
	};

Now that the pins are configured.  We need to setup the PWM.

Configure the Clock and the PWM

Now I will add a little bit of code to the top of  our L3_SuperMux.c to configure the PWM, Clock and Pin.

First add includes for the ACLK and PWM driver.

#include "wiced_hal_aclk.h"
#include "wiced_hal_pwm.h"

Then startup the Clock, Pin and PWM.

    wiced_hal_aclk_enable(2000, ACLK1, ACLK_FREQ_1_MHZ );
    wiced_hal_pwm_configure_pin (WICED_GPIO_PIN_LED_1, PWM1 );
    wiced_hal_pwm_start(PWM1, PMU_CLK, 0xFFFF-500, 0xFFFF-999,0);

If you want to turn on the PWM you need to do three things

1. Turn on a clock to drive it (line 17) sets the clock frequency to 2000hz
2. Attach the PWM to a Pin (line 18) attaches PWM 1 to the pin
3. Turn on the PWM which is a 16-bit up-counting PWM.  When the PWM is reset it will go to 0xFFFF-999 (the period)… then it will switch at 0xFFFF-500 (the compare value)

When you program this your Green LED aka WICED_LED_1 is being driven by the PWM.  And your RED LED is being driven by your firmware.

Documentation

All of the hardware blocks on the chip have a set of API functions to help you interface with them.  You can find all of that in the Documentation

Summary

For our first project, I am going to stand on the shoulder of giants.  In 1978, Brian Kernighan and Dennis Ritchie published “The C Programming Language”.  Here are pictures of my copy.

The reason you do “Hello, World” is that you want to make sure that your compiler chain, programmer etc are all working correctly with something that is super simple.  The only change that I will make to their classic program is to add the “Blinking LED” which is the embedded developers version of “Hello, World”.

The concepts that I want to show in this lesson are.

1. How to make a new project – makefile.mk, <appname>.c
2. How NOT to make a new project
3. How to create a “Make Target”
4. CYW920719Q40EVB01 Development Kit
5. WICED PUART and WICED HCI UART
6. How to start the bootloader
7. Where the documentation resides for the WICED 20719 hardware abstraction layer
8. WICED uses ThreadX RTOS

To make this first project the steps are:

1. Make a new folder called wiced_bt_class  in the Apps Folder
2. Make a new folder called L2_HelloWorld in the wiced_bt_intro Folder
3. Create a new file called L2_HelloWorld.c
4. Create a new file called makefile.mk
5. Add the code to print HelloWorld & blink the LED to L2_HelloWorld.c
6. Add the secret incantation to makefile.mk to build the project
7. Create a “Make Target”
8. Connect the development kit to your computer
9. Attach a serial terminal to the PUART
10. Run the Make Target to Build and Program

Lets do this!

DO NOT DO File->New Project

I always hate to start with a negative statement… but DO NOT make a file project by doing File->New Project.  This is used for creating a new Eclipse project, not a new WICED Studio project.  In WICED Studio we use the make external build system.  If you do File->New Project all hell is going to break loose.  So don’t do any of the things on this menu:

Hello World & Blinking LED

Now lets get on with making a WICED Studio Project.  First create a new folder to hold the projects for the Class in the “Apps” folder by right-clicking and selecting New->Folder

Give it the name “wiced_bt_class”

Create a folder to hold the first project called L2_HelloWorld

Call the folder L2_HelloWorld

Make a new file called L2_HelloWorld.c by right clicking on the L2_HelloWorld folder and selecting New–>File

Give it the name L2_HelloWorld.c

Make a new file called makefile.mk by right clicking on the L2_HelloWorld directory and selecting New->File

and giving it the name makefile.mk

Add some code to the L2_HelloWorld.c

#include "wiced.h"
#include "sparcommon.h"
#include "wiced_platform.h"
#include "wiced_rtos.h"
#include "wiced_hal_gpio.h"
#include "wiced_bt_trace.h"

APPLICATION_START()
{
    wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_PUART);

    WICED_BT_TRACE("Hello, World\n");
    while(1)
    {

        WICED_BT_TRACE("Setting 0\n");
        wiced_hal_gpio_set_pin_output(WICED_GPIO_PIN_LED_2,0);
        wiced_rtos_delay_milliseconds(500,KEEP_THREAD_ACTIVE );
        WICED_BT_TRACE("Setting 1\n");
        wiced_hal_gpio_set_pin_output(WICED_GPIO_PIN_LED_2,1);
        wiced_rtos_delay_milliseconds(500,KEEP_THREAD_ACTIVE );
    }
}

Add the secret incantation to the makefile.mk

#
# Lesson 2 - Hello, World
#
APP_SRC +=  L2_HelloWorld.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE

Create a make target

The make target has a VERY specific format.  It is:

directory.directory.appname-platform download

In our case we have all of our projects in a directory called “wiced_bt_class”.  Then we have a directory called “L2_HelloWorld” which holds the exact project.  And our platform name is “CYW920719Q40EVB_01”

Connect the Development Kit To Your Computer

When you plug in your development kit, it will USB enumerate a TWO serial ports.  One of the serial ports (the first one) is called the “WICED HCI UART”.  The second serial port is called the “WICED Peripheral UART” (this is often abbreviated “PUART”)

One of the key things that the WICED HCI UART is used as is a UART to download new code to the bootloader.

The PUART is used as a general purpose serial port.  When we call this function it causes all of our “WICED_BT_TRACE” outputs to go to the the PUART.

    wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_PUART);

You can see these two UARTs on a PC by running the device manager.

You can see COM17 is the “WICED HCI UART” and COM18 is the “WICED Peripheral UART”

On my Mac I use the program “Serial” which I downloaded from the App Store.

When I run Serial and then to open a Port

You can see the two UARTs.

In order to see the output I will connect to the port with the settings

• 115200 Baud
• 8-n-1 (Data bits, Parity, Stop Bits)

With my PC I typically use Putty (remember it was COM18 from the screen above)

On the Mac program serial you can configure it with Terminal->Settings

Program your Development Kit

In the Make Target window you should see a bunch of “targets”.  You probably have a bunch more targets, which came in your installation of WICED Studio by default, but I deleted a bunch of them so I could just see the ones that I created.

To build and program your project, double click the make target we made before.

When you look in the console you should see something like this:

And when you look at your serial terminal you will see this:

And you should also see the blinking LED!!!

Start the Bootloader

If you get this message there are three posibilites

1. The kit isn’t plugged in
2. The driver didn’t install properly
3. The bootloader wont start

Check the first two… and if that doesnt work then what this means is that the bootloader is not listening on the WICED HCI UART.  In order to fix this you need to press reset and hold down the button called “Recover”.  Then release the reset, then release the recover button.  What does this do?  Simple, when the chip comes out of reset, if the recover button is pressed, the chip starts the bootloader instead of the main application.

Here is a picture of the bottom corner of the board.  The button circled in Green is the “Recover”.  The button in Red is “Reset” and the Blue surrounds the LED circuit.

The two LEDs are labeled LED1 and LED2.  LED2 is the Red one, LED1 is the Green one.  The dip switches circled in Blue connect or disconnect the LEDs from the CYW20719.  In my case you can see (barely) that the switch is set to On.  Both of these LEDs are active LOW (0 turns them on)

Cypress has a great debugger built into PSOC Creator which fully supports all the ARM Serial Wire Debug protocols such as breakpoints, single step, memory, register viewing etc. However, when you are running a boot loader the debugger does not work! Why not? Because with a boot loader there are two applications resident in PSOC4: The boot loader and application. This is not supported by Cypress implementation of SWD.

Where does this leave you, the intrepid code developer, when debugging a boot loader project? Personally, I have used all kinds of methods: debug UART interface, debug I2C interface, bang out states on pins, debug Bluetooth interface … and on and on. You get the idea. All these methods burn a communications interface and require extra pins on the chip. Sometimes that’s not possible.

The issue recently came to a head when a customer very nearly in production experienced a boot loader failure. One system out of a few thousand was “bricked” when they tried to field  update in the lab. Their pinout is frozen, they can’t add new hardware so how do we look inside PSOC4 and see what’s going on?

I woke up at 2 AM and thought “Ah Ha! SWV!” (Yes, I Am A Geek) Serial Wire View is an ARM native debug protocol that let’s you XRAY the insides of any ARM MCU with the right interface. SWV is a protocol which runs on the SWD pins (clock and data) but also needs the Serial Wire Output (SWO) pin. Cypress left the SWO pin and associated IP off of PSOC4 to save die cost, foiling my great idea. Brief interlude to drink and bang head on desk.

Fortunately, I don’t give up easily. At least my subconscious does not. Woke up the next night thinking “Ah Ha!” again. Wife was mildly annoyed, but tolerates my idiosyncrasies.

Cypress has a nice software UART transmitter implementation. I shamelessly stole it, modified for my purposes and created a custom component. (It’s pretty easy to do this by the way) Baud rate was modified to 230 KBps and the output pin forced to a specific pin with a control file.

Once the component is in place, you can use its _DView_Printf( ) API call to display any debug data. Here is an example:

More about that output pin. Cypress sells a tool for programming and debugging PSOC called CY8CKIT-002, aka MiniProg3. The programming connector consists of VDD, GND, reset, SWD clock and SWD data as shown below.

Since we can’t use SWD protocol for debugging anyway, we can change the pins from SWD to normal GPIO. The pins still function for programming. By default they are in SWD mode as shown.

Going to the system tab of the .CYDWR file, we can change them to GPIO.

Once we do that, the pins look like this. Here’s the trick. We now assign the TX output of our DTView component to pin 3[2], which is available  on the SWD programming header, pin 5.

Can you see where we are going with this? Printf( ) data is now coming out of PSOC4 on pin 3[2], easily accessible on our debug header. This is where MiniProg3 comes in. It can actually receive data as a 230 KBps RX UART on its XRES pin. Weird, right? By building a simple interface cable we can get the data from your debug header into MiniProg3.

MiniProg3 XRES —— SWD HEADER pin 5

MiniProg3   GND —— SWD HEADER pin 2

However, MiniProg3 does not show up as a COM port on your PC, so how do we the data? It needs to be accessed by a host application running the PP_COM API. This is documented under PSOC Programmer Component Object Model COM Interface Guide, Cypress specification 001-45209. If you installed PSOC Creator or Programmer, this document is actually on your PC under C:\Program Files (x86)\Cypress\Programmer\Documents. Engineers don’t like to read instructions. Amazing what you can find when you do.

I wrote a simple  console application which opens MiniProg3 using PP_COM, retrieves data from the serial RX pin via USB and displays it like a simple terminal program. Voila! You now have a serial debugger that works for any PSOC4 project using MiniProg3 as your USB to serial dongle.

Customer was really happy with this. We were able to immediately see his problem and fixed it in about 5 minutes.

Finally, here are all the source files

DTView Firmware : PSOC Creator example project and DTView component

DTViewer Binary : Installer for DTViewer console

ViewerSource : Complete source code for DTViewer console (Requires Visual Studio 2015)

That’s all. Have fun with the new debugging tool.

DTV

In the previous post I took you through the first part of the PSoC4 Boot Sequence.  I traced from the power on of the chip to the beginning of the “Reset()” function.  In this post I will trace the steps that were required to get the reset vector and stack pointer set and programmed into the flash of the PSoC4 at the right place.

We know that you program the chip with a hex file which is essentially a file with a list of addresses and values.  But how to you get a hex file?  And how do you get the Reset Vector and Stack Pointer into the hex file?  In order to create a hex file there are several steps required.

1. Compile C –> Assembly Listing File then Assemble listing –> Objectfiles
2. Link object files –> into ELF file
3. Convert ELF –> Hex file

PSoC4 Boot Sequence: Compile and Assemble Program

Each C file in your project is turned into an ARM assembly language program by the compiler.  You can see the ARM assembly language programs in “.lst” files.  You can find your project listing files by clicking on the “Results” tab in the workplace explorer then selecting the “listing files” folder under your project.  In the screenshot below I am showing you the “Cm0Start.lst” which is the ARM assembly language file from the Cm0Start.c.  You will notice that there is one listing file for each of the C files in your project.

The next step in the process is for the Assembler to turns the listing files into object files.  Each object file has the hex bytes that represent your program and data.  It also defines which “section” that the code and data belong too.  The .0 also has a list of symbols that it doesn’t know the address of e.g. the address of functions and data in other files.  In order to see the object files you need to use the windows explorer (we don’t attach them to the workplace explorer)

PSoC4 Boot Sequence: Linker Configuration

The linker is responsible for:

1. Combining all of the .o files into one file
2. Assigning actual addresses for all of the symbols e.g. variables and functions

In order for the linker to do its job, it needs a linker script.  Cypress supports three toolchains: GCC, ARM MDK and IAR.  Each one of the toolchains has different syntax, form etc. for the linker script.  This is painful, but it is made worse by the fact that the linker script language is rather esoteric.  PSoC Creator makes a linker script for all three of the tool chains.  You can find those files called “cm0gcc.ld” (the GCC linker file), Cm0Iar.icf (the IAR linker file) and Cm0RealView.scat (the MDK linker file) in the workspace explorer under Generated_Source–>PSoC4–>cy_boot

There is quite a bit going on in the linker file.  In fact the GCC linker file for PSoC4M is 470 lines long.  However, there are two basic commands in the linker file.

The “Memory” command which defines the address and size of the different types of memory in the system.  Each block of memory is sometimes called a “region”, but the Linker words “region” and “section” and “segment” are used somewhat erratically in the parlance.  In this PSoC4M there is 128K of Flash that starts at address 0x00000000 and 16K of RAM which starts at address 0x20000000.  You can see the “Memory” command on lines 29-33 of the GCC linker script.

The second big command in the linker file is “SECTIONS”.  After the sections command there is a list of [input] section names and where they belong (aka their address).   When you look around on the internet you will find that sometimes the word “section” is used interchangeably with the word “segment”.  Unfortunately there does not appear to be a canonical definition of either of these words. There are three main section/segments

• bss – this section contains variables which should be initialized to zero before main starts
• data – this section contains variables which need to be initialized to some specific value
• text – this section contains your program

Here is a screenshot of the part of the GCC linker file that includes the definition of where the PSoC4 ARM exception vectors are located.  This starts on line 72 where the “SECTIONS” command is issued.

The section command defines the a list of sections and the address of the sections.  Inside of the linker there is an “address pointer” which keeps track the current address in the system.  As it loads sections into the program it increments the address pointer so that it knows the final address of symbols.

In the above listing you see on line 87 that a section called “.text” belongs starting at address “appl_start”.  The linker code on lines 75–>80 is used to support bootloading programs with multiple application.  However, in this case we have only one application and no bootloader.  As a result nothing is loaded and “appl_start” is set to 0x00000000 which is also known as the first location in Flash.  Line 92 tells the linker to put the code in the section “*.romvectors” next.  Now we need to find the code that is marked in some .c file as belonging to the section “romvectors”.  I will come back to the linker script in a later article.

Cm0Start.c the Heart of the PSoC4 Boot Sequence

After digging through the beginning of the linker script and putting a breakpoint on the reset vector we know that the vector table is in a section named “romvectors” and we know that the 2nd entry in the table is the address of the function “Reset()”.  So that leaves us with the question:  Where are the “romvectors” defined?  After using the PSoC Creator search functionality I find this block of code.

That nested mess of #defines and #ifdefs is a bit intimidating… but it was all put there to support the three different compilers.  If you boil it down, the first thing you will see is line 462 tells the compiler to put the next block of code into the “.romvectors” section.  Bingo! that is exactly what we were looking for.  Then on line 464 you can see that we define an array of type “cysisraddress”.  It turns out that “cyisraddress” is just a function pointer.  OK.

Now dig a little bit more and you can see that line 467 defines the address of the initial stack pointer as CY_SYS_INITIAL_STACK_POINTER.  This address is the last location in the RAM.  Then on line 471 we put the address of the Reset() function, then we put in two entries for the NMI and hard fault handers.  The “IntDefaultHandler” is an infinite while(1){} which hangs the processor.  This function is also in the Cm0Start.c file.

Stack Pointer

Earlier I said “.. the address of the initial stack pointer.  This address is the last location in the RAM.”  How does that get to be?  Well if you hover over CY_SYS_INITIAL_STACK_POINTER you will find that it is a #define for the symbol “__cy_stack”.  Then when you look in the linker script you will find:

You can also see that the end of the heap is defined as the address of __cy_stack – 0x800.   The 0x800 must be the size of the stack… and it is… you define it in on the system resources tab of the “design wide resources”

The final thing to look at with regards to the stack is linker file definition of the stack (and heap).  On line 258 you can see that the stack starts at the address __cystack – 0x800.  This address is also known as the end of the RAM minus the size of the stack (remember that in ARM the stack builds down towards lower addresses)

Test1.map

The last link in the chain is the linker map file.  You can find that file in the Test1–>CortexM0–>ARM_GCC_541–>Debug–>Listing Files directory.  The map file is message output file of the linker.  You can see the final resting place of all of the symbols. In the screenshot below you can see that the “.romvectors” segment started at address 0x0 and ended at address 0x10.  This makes sense as there are 4x 4 byte addresses (stack pointer, reset vector, NMI vector, Hard Fault vector)

And the stack landed at 0x200038000 and ends at 0x20004000 which makes sense as we have 16K of SRAM aka 0x4000 bytes.

In the next post we will follow through the “Reset()” function and the initialization of the BSS&Data section as well as the C-Standard library.

In the previous article I showed you all of the components of the Particle Photon Ecosystem.  All that is cool.  But what can you build?  I have written extensively about the Elkhorn Creek in my backyard, and the system that I built to monitor the water level.  As part of that series of articles I explained that I have a 4-20ma current loop that turns pressure into water level read here .  In this article I will:

• Attach the Photon to my Creek System Current Loop
• Write the Firmware in the Particle Cloud IDE to publish W
• Send events to the Particle Cloud & monitor
• Use Webhooks to send the data to ThingSpeak.com

Attach Particle Photon to Creek System

To interface to a 4-20mA current look you just attach it to a 51.1 ohm resistor to serve as a trans-impedence amplifier.  Here is the PSoC Creator schematic for the board:  Using this schematic, the system will generate a voltage between (51.1 Ohms * 4ma = 204.4mV) and (51.1Ohm * 20mA = 1022 mV).   This voltage can then be attached to an Analog To Digital Convertor, then converted digitally into a Pressure, then a water depth.

I decided that the easiest thing to do with the Particle Photon was to attach the pin A0 to the highside input.  This was easy as I put a loop on the Creek Board.  The loop is labeled “PRES”.  The picture is a bit ugly as I was standing in the dark in the rafters of my barn.  Sorry.

Particle Photon Firmware

When you look at the main loop of the firmware, lines 23-40 it does three things

• Reads the ADC voltage on Pin A0
• Applies an Infinite Impulse Response Filter (IIR) with coefficients of 7/8 and 1/8.  This is low pass filter.
• Turns the voltage into depth.  This is done by turning (4-20ma) into (0-15 psi) then PSI into Feet

Then, on lines 34-39, I use the system time to figure out if it is time to publish again.  I publish every “INTERVAL”.

In order to test the Particle Cloud interface to the Photon, I setup all of the intermediate calculation of depth as “Particle.variable”s which allows me to inspect them remotely.

uint32_t nextTime; // when do you want to publish the data again
const uint32_t INTERVAL = (5*60*1000); // every 5 minutes in milliseconds
const double  MVPERCOUNT = (3330.0/4096.0); // 3300mv and 2^12 counts
uint32_t current;
uint32_t filter=0;
double depth;
double percent;
double psi;
double voltage;
double percentTemp;

void setup() {
    nextTime =  millis() + INTERVAL;
    // setup variables so that they can be polled
    Particle.variable("filter",filter);
    Particle.variable("adc",current);
    Particle.variable("percent",percent);
    Particle.variable("voltage",voltage);
    Particle.variable("psi",psi);
    Particle.variable("depth",depth);
}

void loop() {
   
   char buff[128];
   
    current = analogRead(A0);
    filter = ((filter>>3) * 7) + (current>>3); // IIR Filter with 7/8 and 1/8 coeffecients
    voltage  = ((double)filter) * MVPERCOUNT; // Convert ADC to Milivolts
    percent = ( voltage - (51.1*4.0) ) / (51.1 * (20.0-4.0)); // 51.1 ohm resistor... 4-20ma 
    psi = percent * 15.0; // Range of pressure sensor
    depth = psi / 0.53; // Magic 0.53psi per foot

   if(millis() > nextTime)
   {
        sprintf(buff,"%.1f",depth);
        Particle.publish("CreekDepth",buff);
        nextTime = millis() + INTERVAL;
   }
}

Sending Events to the Particle Cloud & Monitor

Once I flashed the firmware with the very cool Over-The-Air Bootloader, I go to the Particle Console and click on my device.  As soon as I do that I see the “Particle.variable”s that I defined in the firmware.  One by one I press “get” and after a second the data is displayed on the screen.  I am not exactly sure how the exactly works, but it is cool.

After inspecting the variables, I go the Logs page and look to see what the events are.  You can see that every 5 minutes (about) there is an event called “CreekDepth” with a -0.0 or so. That is good as it means that the Particle Photon is publishing regularly.  The answer is 0.0 (or about 0.0) as the Elkhorn Creek if not doing anything right now.  The other events are part of the web hook that I setup (and will talk about in the next section).

Using WebHooks to send data to ThingSpeak.com

Unless I am missing something, the Particle Cloud does not store your actual data.  They do have a mechanism to take Events from your devices and trigger a “WebHook”.  This is basically a RESTFul API call to another cloud.

They call these “integrations” and you configure them on the Console.  When you press “Integrations” you end up with this screen which gives you the option of editing a current webhook or creating a new one.

When you click on “new integration” it gives you the option of connecting to Google, Microsoft Azure or Webhook.  I havent tried Google or Azure so for this article Ill stick with a Webhook.

I started with a WebHook to the ThingSpeak Cloud (because they show a nice example in the documentation).  ThingSpeak is run by the MathWorks people (same as Matlab).  They call ThingSpeak “an open IoT with Matlab Analytics”.  OK sounds cool.  In order to use it to collect and display data I start by creating a new account.  Then I click on the “New Channel” button to create an “Elkhorn Creek Depth” channel.  On this screen I say that there will be only one field “CreekDepth”.

In order to write data into this channel you need to have the API keys which give your Restful API call the authority to write into the database.  Press “API Keys” and you will see this screen.

Now that I have an active channel (and I know the channel number and API write key) I go back to the Particle Cloud Integrations tab and create a Webhook.

Each time the “CreekDepth” event occurs, the Particle Cloud will do an API call to the ThingSpeak cloud and insert the new data.  On the ThingSpeak Cloud there is a chart of the data, and a handy-dandy way to insert the chart into your webpage.  Here it is for the Elkhorn Creek showing the last 6 hours of data which is flat at the time of this writing, but maybe when you read this page it will be raining in Kentucky and you will see something interesting.

I guess at this point I have a number of questions which I will leave to the future:

• Exactly what is the form of the request made to the ThingSpeak cloud?
• What is the mapping between the event –> API Request
• What is the protocol for Particle.variables?
• How does the Microsoft integration work?
• How does the Google integration work?
• How do I save power on the Photon?

I suppose Ill leave these questions to future posts.  If you have other questions leave them as I comment and Ill take a crack at trying to figure them out.

Over the last few days I have spent some time with the Particle Photon and looking around at the Particle Cloud, the Development Kits, the Documentation and Development Tools.  Fundamentally, Particle has built a very ambitious end-to-end cloud development platform.  I think that they have everything necessary to built a complete IoT solution into your system.  Obviously, I like them because they use a Cypress 43362 WICED WiFi chip as the core of their solution, but the rest is cool as well.  Particle also offers a cellular connectivity solution using uBlox, but I didn’t try that.  In this article I will give you a brief introduction to all of the components of their ecosystem including:

• Particle Photon WiFi
• Particle Photon Development Kits
• Particle Photon Development Environment
• Particle Photon Support Tools
• Documentation
• Particle Cloud Console

To develop with Particle you write your firmware in C++ with an Arduino library clone (many/most? of the APIs and libraries that you know and love are ported into the system).  The libraries also include a bunch of APIs for transferring actions and data to/from the cloud.  Once you have written the firmware you can flash you board either directly through the USB port or through the Cloud over-the-air bootloader (which works great)

Particle Photon WiFi

Particle makes two modules, called P0 ($10) and P1, ($12) which you can build into your system.  Both are FCC certified modules that use the Cypress 43362 WICED WiFi chip which is 2.4GHz 802.11a/b/g/n paired (unfortunately) with a STM MCU to run WICED & the Photon Environment.  Both of the modules are PCB circuit boards with QFN style pads on the bottom that let you solder them into your system.  The P0 is smaller (11mm x 12mm) but needs an antenna, and P1 is a bit bigger (28mm x 20mm) but has a PCB Antenna and SMA connector.  Here is a picture which I borrowed from the Particle Website.  The P0 is on the right, the P1 is in the middle, then on the left is a development kit with the P0 soldered into it.

Particle Photon Development Kits

Photon makes essentially one basic development board (shown above on the left) as well as a bunch of different support boards and package deals.  The basic development kit is $19 and has a Photon P0, an antenna, an SMA connector for an external antenna, two buttons (reset and setup), one user LED, a USB programming/power connector and 100 mil center pins with the P0 pins broken out.  One very cool feature of the board is that the breakout pins are castellated on the side of the board so that you could solder it directly into your product.

One of the boards that I ended up using was a (now obsolete) SparkFun kit that has a Photon P1 soldered into an Arduino footprint board:

Here is a screenshot of many of the development kit packages you can buy directly from Photon:

In addition there are several other makers of support boards including SparkFun, Adafruit and SeeedStudio.

Adafruit:

SeeedStudio:

Particle Photon Development Environment

Particle offers two integrated development environments, one web based and one computer client based on Atom.  Both are approximately Arduino clones… and both work very well.

The web based environment includes a code editor, compiler, over-the-air flash utility. and library utility.  Here is screenshot of one of the programs that I was working on.

And the desktop environment, which works on Windows, Mac and Linux, is very well integrated and “feels” just like the web environment.  I was amazed that as soon as I installed the tool it was connected to the Particle Cloud and to my devices.  I created a very simple blink the led program.  After I pressed the lightning bolt… 15 seconds later my board was bootloaded over the air.  Here is a screenshot from my Mac.

Particle Photon Support Tools

There are two sets of command line tools that you can use to interact with the Photons, dfu-util and the Particle-cli.

The first is “dfu-util”  which I didn’t know anything about until I started using the Photons.  DFU-UTIL is a USB bootloader host that allows you to update sections of the Photons firmware.  When I took my boards out of the box they had very old system firmware and things were not connecting correctly.  I ended up having to download new system firmware and then install it on the boards.  The instructions were on this website.

The second tool, called the Particle Command Line Interface is also really cool.   Once you install it you can upgrade firmware, send commands, read and write data, call functions etc on your devices.

Documentation

The bottom line is the documentation is outstanding, something that is a rare and wonderful thing in the business.  You can find it on their website.  Here is a screenshot of the first page.

Particle Cloud

An IoT device isn’t worth much unless it is integrated with the cloud.  Particle provides a bunch of things in their cloud.  In addition they give you the ability to drive data and events into other clouds.  With the Particle Cloud you can

1. From the cloud, read and write data from devices
2. Push and retrieve data from your device to the cloud
3. You can manage and provision devices
4. You can flash new firmware OTA to your devices

There is a free tier for makers and experiments which includes up to about 25 devices and 250K transactions per month.  Beyond that they have several subscription levels.  In the screen shot below you can see my two devices (one called “Red-board” and one called “test1”).  With this interface I can query the device and run “functions” which are like remote procedure calls.

In the console log you can see all of the events pertaining to your device.  In the screenshot below you can see that I changed the state of the button a bunch of times on the “Red-board”.  You can also see where the “test1” board was reset and re-attached to the network.

In the next Particle post I will make something…. what?  Im not sure yet.  But Ill think of something.

I have been building up pieces of code that are going to allow me to show the PSoC Analog CoProcessor –> WICED WiFi –> Amazon IoT –> WICED WiFi –> Secret New Chip –> Robot Arm.   In the previous two articles (part1, part2) I have shown you how to build most of the WICED firmware.  In this article I am going to focus on the PSoC Analog CoProcessor firmware (but if you look real close you can see the secret new chip’s development kit).

In the picture below you can see the red shield board.  This is a shield with the PSoC Analog CoProcessor plus a bunch of sensors that show the power of that chip.  The shield also includes 4x CapSense Buttons which I am going to use to set the position of the Robot Arm.  The PSoC will serve as a front end companion to the WICED WiFi Development Kit.  They will communicate via I2C with the PSoC acting as an I2C Slave and the WICED WiFi as a master.  Here is a picture of the all of parts minus Amazon.com’s cloud.

PSoC Analog CoProcessor

The PSoC Analog CoProcessor has the new Cypress CapSense block that gives you a bunch of new features, including enough measurement range to measure a capacitative humidity sensor (which you can see in the upper left hand part of the board).  For this demonstration I am just going to use the 4 CapSense buttons.  They will serve as the user interface for the Robot Arm.  The 4 buttons will set 4 different positions, 20%,40%,60%,80%.  I will be talking in much more detail about this shield in coming posts (later next month)

PSoC Analog CoProcessor Schematic

The PSoC Creator schematic is pretty straight forward.  I use the EZI2C slave to provide communication for the WICED board.  There are 4x LEDs that sit right next to the CapSense buttons,  and there are the 4x CapSense buttons.  The only slightly odd duck is the Bootloadable component which I use because when I designed the shield I did not put a programmer on it.  The BootLoadable allows me to me to load new firmware into the PSoC via the I2C interface.  Here is the PSoC Creator Schematic:

The CapSense configuration just specifies the use of 4x CapSense buttons that are automatically tuned by the Cypress magic.

The last step in configuring the schematic is to assign all of the pins to the correct locations.

PSoC Analog CoProcessor Firmware

One of the great things about all of this process is how easy the firmware is to write.

• Line 3 declares a buffer that will be used to relay the position information to the WICED board.  I start the position at 50%
• Lines 8-9 start the EZI2C which starts up the EZI2C protocol and tells it to read from the “position” variable
• Lines 10-11 gets the CapSense going

Inside of the infinite while(1) loop, I read from the CapSense and do the right thing

• Lines 17-22 reads the CapSense status
• Lines 24-27 set the correct position based on which buttons are pressed (notice that if no button is pressed then the position stays the same)
• Line 29 turns on the Bootloader if B0 & B3 are pressed

Testing the PSoC Analog CoProcessor System

The easiest way to test the system is to use the Bridge Control Panel which comes as part of the PSoC Creator installation.  It lets me read the value from the EZ2IC buffer to make sure that the CapSense buttons are doing the right thing.  The command language is pretty simple.  You can see in the editor window that I typed “W42 0 R 42 X p;”  Everytime I press “enter” it sends the I2C commands:

• Send an I2C start
• write the 7-bit I2C address 0x42
• write a 0
• send a restart
• read from address 0x42
• read one byte
• send a stop

You can see that I pressed each button and indeed got 20,40,60,80 (assuming you can convert hex to decimal… but trust me)

In the next article I will modify the WICED Publisher to poll the PSoC Analog CoProcessor and then publish the current state.

Summary

In the previous post I told you that I immediately blew away the factory firmware on the TSoC4L board.  I’m like that sometimes :-).  In this post I am going to take you through the entire process of getting and reprogramming the factory firmware, then finding and debugging a PSoC4 clock problem.  The rest of this post is:

1. Getting the correct firmware back on the TSoC4L Board
2. Running into a bug in the beta version of the firmware
3. Using the debugger to find the bug
4. Explaining the functionality of Low Frequency Clocks and the Watch Dog Timer
5. The Pattern Agents bug fix

Factory Firmware

Getting things going again starts with “git”ing the firmware.  This can be done by “git clone git@github.com:PatternAgents/TSOC_PSoC4L.git”.  Once you have the repo cloned you will find a bunch of good stuff including:

1. datasheets: All the datasheets
2. documentation: The PatternAgents documentation (quick start)
3. drivers: The windows USB <-> UART drivers
4. eagleUp: JPG renderings of the PCB
5. firmware: The PSoC Creator Project
6. hardware: gerbers, boms etc
7. images: renderings of the board, photos of the board etc
8. revisions: old revisions of the Eagle project files
9. The Eagle PCB Project including schematic and layout

When you open the PSoC Creator Workspace you will find two projects

1. A USB Bootloader – called “USBFS_Bootloader”
2. The TSoC RSVP Firmware – called “rspvsis_4l_typ”

The system is supposed to

1. Start the USB HID bootloader (so you could get new firmware).  Wait for 10 seconds for a bootloader host to start then if it doesnt … then start
2. The RSVP Firmware

When you plug in the board you will see the TSoC4L enumerate as “Cypress ThingSoc Bootloader”.  Then, after 10 seconds, you should see it reboot, then enumerate as “Cypress USB UART”.  But, this was not happening for me.  Why?  I wasn’t sure.  The first thing that I did was add a blinking LED circuit that looked like this:

But the LED was not blinking.  That meant that the firmware was not even getting to main i.e. it was hanging BEFORE main in the PSoC boot code.  But where and why?

Using the Debugger to Find the Bug

How do you figure out where the system is stuck if you can’t even use the “blinking LED” or “printf” debug?  Simple.  Use the debugger.  Start by programming the PSoC with your firmware.  Then click “Debug->Attach to running target”.

The debugger will start.  Then you will be able to press the “Pause” button. which will take you to a screen that looks like this:

The chip is stuck on line 234.  What does line 234 do?  That is a busy wait loop.  It is waiting for the Watch Dog Control Register to clear.  To explain that, I will need to take you through the PSoC4 Low Frequency Clocks.  First you should notice that the file we are in is named “cyfitter_cfg.c”.  What is this file?  If you look at the top, this is what PSoC Creator says.

This means that the “cyfitter_cfg.c” file is synthesized by PSoC Creator when you do a build based on what you configured when you setup your project.  This file contains a bunch of the startup code including the code that gets the clock systems going.  Line 234 is inside of a function called “ClockSetup”.  All of this code is called BEFORE you get to main().

The PSoC4 Clock(s)

To explain why we are stuck there you first need to double click on the “Clocks” tab in the Design Wide Resources.  When you do that it will take you to this screen which contains a bunch of information about the clocking system in the PSoC.

In the screen above, you can see that there are three Timers in the Watch Dog Timer system (WDT) that are clocked (i.e. have a Source Clock of) by the Low Frequency Clock (LFCLK).  The LFCLK has its source as the Watch Crystal Oscillator (WCO).  If you double click the WCO line it will take you to a screen that is much easier to see what is going on, specifically the “Configure System Clocks” screen:

In the screen above you can see that the LFCLK has two choices of oscillator sources, the “ILO” or the “WCO”.  ILO stands for Internal Low Speed Oscillator.  The ILO is a fairly inaccurate (+- 60%) RC oscillator that is built inside of the chip.   It is designed to be very low power which is why it is so inaccurate.  If you need a more accurate oscillator, then you should use an external oscillator, specifically a Watch Crystal Oscillator or WCO.  A WCO is a 32.768KHz crystal oscillator.  These watch crystal oscillators give you very precise clocks that can be used to drive real time clocks accurately.

The next thing to see is there are three Watch Dog Timers (WDT) numbered 0-2.  These times are driven by the “LFCLK”.  Here is a picture from the PSoC Technical Reference Manual.

So what is the “CYREG_WDT_CONTROL”?  You can find that by looking in the PSoC4 Registers TRM.

The busy wait loop is waiting for bits 19,11,3 to be cleared.  Those bits are “WDT_RESETx”  They become 0 when the three WDT timers are cleared which happens “several LFCLK cycles” after the reset.  As a reminder, here is that block of code:

This still leaves us with the question, “What is the problem?”.  If you look on the back of the ThingSoC4L board you will see there is no Crystal populated on this board. (the blank footprint on the right side of the back).  The WCO is an optional feature from Pattern Agents.  If you need the more accurate timing, you need to solder on your own Crystal.

If there is no WCO crystal, then the WDT timer reset will never happen because LFCLK isn’t doing anything.  And, the busy wait loop will never end.  Mystery solved.

The Pattern Agents Bug Fix

To fix the startup problem, the Pattern Agents guys changed the clock configuration to

1. Turn off the WDTs
2. Use the ILO as the source of the LFCLK

You can find all of the projects in the TSoC Series at my GitHub ThingSoC repository git@github.com:iotexpert/ThingSoC.git

I start this process by copying the CreekHistory java object into the “getCreek” part of my project.  I then modify the main batch Java program, called “CreekServer” to understand the CreekHistory object.

Then I add a new function “createHtml” to the CreekHistory object.  This function creates the webpage with the current information on it.  Basically

1. A table of the last three hours [line 221-235]
2. Link to the current chart [line 237]
3. Link to the floods charts [line 237/238]

I then add the “Current” command to the “runi2c” batch program.

This program is run every 2 minutes by the crontab on the Raspberry Pi.  I picked 2 minutes because that is a good bit longer than each job takes to run in total.   Notice that I check to see if the jobs are already running and quit the “runi2c” job if the chart creation process is already going on.

At this point I have (at least) several things which are ugly

1. I don’t have a good back up system
2. I duplicate the “CreekHistory” object in the JSP as well as the “getCreek”
3. I duplicate the “readProperties” method into a bunch of different objects
4. I have 5Vs (I think) on the I2C pins of the Raspberry Pi, which I don’t understand why this isn’t a problem
5. I need to get the PSoC4 Bootloader Host going on the Raspberry Pi

The purpose of the meeting was to introduce the PSoC team to WICED and then talk about the future roadmap for those products.  Obviously I can’t talk to much about the 2nd part… well actually the only thing I can say is that it will be amazing as we will be able to offer PSoC with the power of WICED.

What I can talk about is the first part.  So, I thought that I would show you one of the things that we did with WICED.  First of all, WICED (Wireless Internet Connectivity for Embedded Devices) is the brand name that Cypress uses to describe all of the WiFi, Zigbee and Bluetooth chips and modules that were acquired from Broadcom/Avago.  The other thing we call WICED is the WICED SDK which is used to mean Eclipse plus all of the tools (programer, plugins etc) plus the software library that is used to build products using the WICED chips and modules.

In the world of programming the first example is always “hello world”.  In the world of MCUs the first example is always “blinking led”.  It turns out that the first example in WiFi is “scan” to show that you can see all of the WiFi networks around you.   The purpose of all of these examples is to prove that all of the tools can do their thing.

To start with they gave me this devkit, the BCM94343WWCD1_1  

The first thing to do is install WICED 3.7.  When you start WICED you will see a screen like this:

For the purposes of the first design there are two important things to see on this screen.  First on the left side is the project explorer.  It has all of the guts of WICED.  As part of the installation we provide you a bunch of “apps”.  These apps range from simple examples (in the snip folder) to full fledged production quality applications (in the demo folder)

• demo – full fledged applications
• snip – short example projects
• test – tools for debugging and testing wifi
• waf – WICED Application Framework support (like an OTA Bootloader)
• wwd – low level driver examples

The example that I want to build is “scan”  specifically “scan.c”.  That can be found in the apps/snip/scan folder.  In this screenshot you can see that I opened “scan.c”

The next thing that you need to do is build a “make target”.  The WICED team built a makefile that can seemingly do everything.  The makefile uses the name of the make target to setup all of the options required to do the make.  If you look on the right side of the screen you can see the currently existing targets:

The easiest way to make a new target is to copy/paste a currently existing target.  Then you can right click on the new target and edit it to get things setup correctly.  The target name defines:

• snip – the directory
• scan – the subdirectory will the files (scan.c and scan.mk)
• BCM94343WWCD1 – the name of the devkit (you can see it on the picture of the devkit)
• download run – instructions to go ahead a boatload and start the app running

Next, I plug in the devkit.  When it attachs, the devkit will enumerate as two USB devices

• WICED USB JTAG Port
• A serial port (in this case on COM12)

After I plug in the kit I run Putty and attach to COM12 at 115200 baud

And finally, double click the make target to build, download and run.  After it starts, the Putty screen fills up with all of the WiFI networks that are around me.

All of that was pretty easy to get going.  Next lets see if I can actually do something.  Last week I showed the guys the Elkhorn Creek Water Level monitoring project and I told them that by the end of this week I would put one of their devkits into that system, so the next several posts will be about that process. (I hope)

Ill try to build this App to be as simple as possible.   Here is what the (single) screen looks like in three different state (nothing pressed, button0 pressed, led0 on):

This App is built up with four files

1. ViewController.swift: an object which controls the screen (button clicks)
2. BluetoothNeighborhood.swift: an object which controls the Bluetooth in the phone and represents the CY8CKIT021 board (the Model)
3. globals.swift: Defines the NSNotifications that can be sent
4. Main.storyboard: The screen layout

The code will do the following:

1. When the ViewController (VC) starts it will instantiate a BluetoothNeighborhood (BN) object
2. VC: Tell the BN to start the bluetooth central in the phone
3. BN: Scan for BLE Peripherals that are advertising the CY8CKIT-021 Service UUID
4. BN: When it hears the peripheral with the correct UUID then connect
5. BN: Read the state of the button0 and led0 then send an NSNotification
6. BN: Turn on the notify for button0 (to cause the PRoC to send an NSNotification when there are changes)
7. VC: update the screen when it gets the NSNotification from (5)
8. VC: If the LED0 switch on the screen is switched then tell the BN to write to the PRoC
9. BN: If the button0 is changed then send an NSNotification to the VC
10. VC: If there is an NSNotification (9) of a button0 change then update the screen
11. VC: If the bootloader button is pressed tell the BN to write the bootloader characteristic
12. BN: If there is a disconnect event then send an NSNotification to the VC to disable the GUI elements and start scanning again (step 3)

ViewController.swift

The viewDidLoad method runs when the Apps starts and loads the first screen.  This method

1. Initializes the BluetoothNeighborhood object
2. Tell it to start the bluetooth scanning
3. Disables the UI buttons
4. Then registers with the NSNotificationCenter that it wants to hear the 4 possible messages that the model can send
   1. Connect: enable the buttons
   2. Disconnect: disable the buttons
   3. UpdateLED: reflect the current state of the LED on the screen
   4. UpdateButton: reflect the current state of the button on the screen

//
//  ViewController.swift
//  Example10
//
// Project: Example10
// Kit: CY8CKIT-021 Sheild
// Baseboard: CY8CKit-44 PSoC4M
//
//  This file contains the viewcontroller for the single view application.
//  Basically when it loads you startup and connect to the bleboard
//  then display the state of things... or let the user flip the switch
//
 
import UIKit
 
class ViewController: UIViewController {
 
    var bleLand : BlueToothNeighborhood!
 
    override func viewDidLoad() {
        super.viewDidLoad()
 
        // bleLand-BlueToothNeighborhood is the model.  It is capable of finding
        // a CY8CKIT021 and connecting to it. It can also read/write etc
        bleLand = BlueToothNeighborhood()
        bleLand.startUpCentralManager()
 
        // start with the switch disabled.  it will turn on once there is a connection
        led0switch.userInteractionEnabled = false
        bootLoaderButton.userInteractionEnabled = false
 
 
        // The global structure CY8CKITNotifications defines the different notificateions
        // that can come from the bleLand model.  Basically a connection/disconnection or
        // and update of the Led0 or Button0 State
 
        // If you get a complete connection then turn on the buttons to start working
        NSNotificationCenter.defaultCenter().addObserverForName(CY8CKIT021Notifications.ConnectionComplete, object: nil, queue: NSOperationQueue.mainQueue()) { _ in
            self.led0switch.userInteractionEnabled = true
            self.bootLoaderButton.userInteractionEnabled = true
        }
 
        // if you get disconnected then turn off the buttons
        NSNotificationCenter.defaultCenter().addObserverForName(CY8CKIT021Notifications.DisconnectedDevice, object: nil, queue: NSOperationQueue.mainQueue()) { _ in
                self.led0switch.userInteractionEnabled = false
                self.bootLoaderButton.userInteractionEnabled = false
            }
 
        // The we got feedback from the model about the state of the button0
        NSNotificationCenter.defaultCenter().addObserverForName(CY8CKIT021Notifications.UpdatedButton0, object: nil, queue: NSOperationQueue.mainQueue()) { _ in self.button0.selected = self.bleLand.button0State }
 
        // The we got feedback from the model about the state of the led0
        NSNotificationCenter.defaultCenter().addObserverForName(CY8CKIT021Notifications.UpdateLed0, object: nil, queue: NSOperationQueue.mainQueue()) { _ in self.updateLed0() }
 
    }

The GUI part of the code just acts when the button/switch is pressed to send messages to the model.  These methods are linked to the GUI elements on the main.storyboard

    // This function grabs the current button0 state from the model and sets the button
    // to indicate it is either being pressed or not
    func updateButton0()
    {
        self.button0.selected = self.bleLand.button0State
    }
 
    // This functiong rabs the current led0 state from the model and then flips the 
    // switch the right way
    func updateLed0()
    {
        led0switch.on = bleLand.led0State
    }
 
    @IBOutlet weak var button0: UIButton!
    @IBOutlet weak var led0switch: UISwitch!
 
    // When the user flips the switch you need to write the updated value to the model
    @IBAction func led0SwitchAction(sender: UISwitch) {
 
            bleLand.writeLed0Characteristic(sender.on)
    }
 
    // If the user presses the bootload button then send the bootload command
    // this will cause and immediate BLE disconnect... etc
    @IBOutlet weak var bootLoaderButton: UIButton!
    @IBAction func startBootLoader(sender: AnyObject) {
        bleLand.startBootloader()
    }

BluetoothNeighborhood

This file contains all of the code that interacts with the CY8CKIT021 board.  The first block of code defines a structure with a list of the UUIDs that we need to search for.  These are defined in the Bluetooth Component Customizer from the PRoC firmware.

// BlueToothNeighborhood.swift
//
// Project: Example10
// Kit: CY8CKIT-021 Sheild
// Baseboard: CY8CKit-44 PSoC4M
//
// This file contains the model for the CY8CKIT021 board with 1 LED0 and 1 Button 0
//
 
import CoreBluetooth
 
 
// This structure conatains the UUIDS for the services and characteristics on the board
// it MUST match what you defined in the creator BLE Configuration Wizard
private struct BLEParameters {
    static let CY8CKIT021Service = CBUUID(string: "00000000-0000-1000-8000-00805F9B3400")
    static let bootloadCharactersticUUID = CBUUID(string:"00000000-0000-1000-8000-00805F9B3401")
    static let ledCharactersticUUID = CBUUID(string:"00000000-0000-1000-8000-00805F9B3402")
    static let buttonCharactersticUUID = CBUUID(string:"00000000-0000-1000-8000-00805F9B3404")
 
}

The next block of code

// The model for the board
// The BlueToothNeighborhood has BOTH the board model and the Bluetooth model.  This
// makes the code slightly simpler to explain but is a bit weird architectururally
class BlueToothNeighborhood: NSObject, CBCentralManagerDelegate, CBPeripheralDelegate  {
 
    private var centralManager : CBCentralManager!
    private var CY8CKIT021Board : CBPeripheral?
    private var CY8CKIT021Service : CBService!
    private var led0Characteristic : CBCharacteristic!
    private var button0Characteristic : CBCharacteristic!
    private var bootloadCharacteristic : CBCharacteristic!
 
    // This function is called by the main view controller to get things going
    func startUpCentralManager() {
        centralManager = CBCentralManager(delegate: self, queue: nil)
    }
 
    // This is the bluetooth delegate function
    @objc func centralManagerDidUpdateState(central: CBCentralManager) {
        switch (central.state) {
        case .PoweredOff: break
        case .PoweredOn:
            print("Bluetooth is on - Starting scan")
            // start scanning for a device that we can talk to
            centralManager.scanForPeripheralsWithServices([BLEParameters.CY8CKIT021Service], options: [CBCentralManagerScanOptionAllowDuplicatesKey:false])
 
        case .Resetting: break
        case .Unauthorized: break
        case .Unknown:break
        case .Unsupported:break
        }
    }
 
    // This delegate function is called by the bluetooth when it finds a device
    // that matches our UUID that we told it when we started the scan
    func centralManager(central: CBCentralManager, didDiscoverPeripheral peripheral: CBPeripheral, advertisementData: [String : AnyObject], RSSI: NSNumber)
    {
        // if you already are connected to a device ignore this one
        if CY8CKIT021Board == nil {
            print("Found a new Periphal advertising CY8CKIT021 Service")
            CY8CKIT021Board = peripheral
            centralManager.stopScan()
            centralManager.connectPeripheral(CY8CKIT021Board!, options: nil)
        }
    }
 
    // This delegate is called when a device connection is complete
    func centralManager(central: CBCentralManager, didConnectPeripheral peripheral: CBPeripheral) {
        print("Connection complete \(CY8CKIT021Board) \(peripheral)")
        CY8CKIT021Board!.delegate = self
        CY8CKIT021Board!.discoverServices(nil)
    }
 
    // This delegate is called after the service discovery is complete
    func peripheral(peripheral: CBPeripheral, didDiscoverServices error: NSError?) {
        print("discovered services")
        for service in peripheral.services! {
            print("Found service \(service)")
            if service.UUID == BLEParameters.CY8CKIT021Service {
                CY8CKIT021Service = service // as! CBService
            }
        }
        CY8CKIT021Board!.discoverCharacteristics(nil, forService: CY8CKIT021Service)
    }
 
 
    // This delegate is called when the characteristic discovery is complete
    func peripheral(peripheral: CBPeripheral, didDiscoverCharacteristicsForService service: CBService, error: NSError?) {
        for characteristic in service.characteristics!
        {
 
            print("Found characteristic \(characteristic)")
            switch characteristic.UUID {
            case BLEParameters.buttonCharactersticUUID: button0Characteristic = characteristic
            case BLEParameters.ledCharactersticUUID: led0Characteristic = characteristic
            case BLEParameters.bootloadCharactersticUUID: bootloadCharacteristic = characteristic
            default: break
            }
        }
 
        // You have a complete connection... so find out the current state of the LED0
        // and Button.. then notify the viewcontroller that things are rolling
 
        // read the led0 characteristic to find out its current state
        CY8CKIT021Board?.readValueForCharacteristic(led0Characteristic)
 
        // read the button0 characteristic to find out its current state
        CY8CKIT021Board?.readValueForCharacteristic(button0Characteristic)
 
        CY8CKIT021Board!.setNotifyValue(true, forCharacteristic: button0Characteristic)
        NSNotificationCenter.defaultCenter().postNotificationName(CY8CKIT021Notifications.ConnectionComplete, object: nil)
    }
 
    // disconnected device - start scanning again
    func centralManager(central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: NSError?) {
        print("Disconnected \(peripheral)")
        CY8CKIT021Board = nil
        NSNotificationCenter.defaultCenter().postNotificationName(CY8CKIT021Notifications.DisconnectedDevice, object: nil)
        centralManager.scanForPeripheralsWithServices([BLEParameters.CY8CKIT021Service], options: [CBCentralManagerScanOptionAllowDuplicatesKey:false])
 
    }

The last block of code is responsible for interacting with the board

// start the bootloader...this will cause an immediate disconnect by the board
    func startBootloader()
    {
        var val: UInt8 = 1 // it doesnt matter the value... any write will cause the bootloader to start
        let ns = NSData(bytes: &val, length: sizeof(UInt8))
        CY8CKIT021Board!.writeValue(ns, forCharacteristic: bootloadCharacteristic, type: CBCharacteristicWriteType.WithResponse)
    }
 
 
    // a helper function to write the the device
    func writeLed0Characteristic(state: Bool)
    {
        var val : Int8
        if(state)
        {
            val = 1
        }
        else
        {
            val = 0
        }
        let ns = NSData(bytes: &val, length: sizeof(Int8))
        CY8CKIT021Board!.writeValue(ns, forCharacteristic: led0Characteristic, type: CBCharacteristicWriteType.WithResponse)
    }
 
    // this is the model of the board
    var button0State : Bool = false 
    var led0State : Bool = false // assume that it is off
 
    // This delegate function is called when an updated value is received from the Bluetooth Stack
    func peripheral(peripheral: CBPeripheral, didUpdateValueForCharacteristic characteristic: CBCharacteristic, error: NSError?) {
        if characteristic == button0Characteristic {
            var out: UInt8 = 0
            characteristic.value!.getBytes(&out, length:sizeof(UInt8))
            if(out == 0)
            {
                button0State = false
            }
            else
            {
                button0State = true
            }
            NSNotificationCenter.defaultCenter().postNotificationName(CY8CKIT021Notifications.UpdatedButton0, object: nil)
        }
 
        if characteristic == led0Characteristic {
            var out: NSInteger = 0
            characteristic.value!.getBytes(&out, length:sizeof(UInt8))
            if(out == 0)
            {
                led0State = false
            }
            else
            {
                led0State = true
            }
            NSNotificationCenter.defaultCenter().postNotificationName(CY8CKIT021Notifications.UpdateLed0, object: nil)
        }
    }

In the next post Ill show you how to build the Android App.

• LED0: which can be turned on/off from the from the Android and iOS App
• Button0: which will be displayed as on/off on the Android and iOS App
• Bootload: you will be able to trigger the bootloader from the baseboard or by writing into the BLE Bootload characteristic
• The blue LED attached to the PRoC will blink when advertising and be solid when connected

All of this firmware is available as Example10a (for the PRoC) and Example10b for the PSoC4200m in the firmware directory on github.com/iotexpert/CY8CKIT-021

Example 10a: The PRoC Firmware

The schematic for this project has two pages.  The first page has everything except for the bootloadble.

The second page of the schematic has the bootloadable.  This allows me to “disable” that page if I am not using the Bootloader

The BLE component has the “CY8CKIT021” service with three characteristics one for LED0, Button and Bootload,  The Button has a notify CCCD setup.  All three are uint8s.

This program is broken up into three functions

• updateGattDB: A helper function that can take data as a void* and write it into the correct place in the GattDB.  For example when the app changes the LED0 Characteristic you need to write that update into the GattDB.  This function is generic which will support the same logic on a bunch of different characteristic (for instance when I put in all of the other characteristics LED0/1, Button0/1, Pot, …)
• BleCallBack: This function  processes the BLE Events
  • Stack on or disconnect: start advertising and start blinking
  • Write of characterstic from Central: store the written value into the GattDB and do something
  • Connect: update the GattDB and turn on the LED
• main: This function is very simple and forms the main loop of the program.
  • Start the components
  • If there is a remote from the 4200M side then update the GattDB

First, the updateGattDB helper function.

// updateGattDB() -  
//
// Arguments: 
//  uint8* val  - a pointer to the bytes that need to be writted into the GATTDB
//  int size - the number of bytes that need to be written into the GATTDB
//  uint8 notify - if the NOTIFY is on then send a notification
//  CYBLE_GATT_DB_ATTR_HANDLE_T handle - a handle to the entry in the gatt table
//  uint8 flags - a request 
//   
// This is a helper function that will update the GATT database with a value.  It update the field of
// the "CYBLE_GATT_DB_ATTR_HANDLE_T"
 
void updateGattDB(uint8 *val,int size,uint8 notify, CYBLE_GATT_DB_ATTR_HANDLE_T handle,uint8 flags)
{
 
    // this little block of code doesnt make me happy... 
    switch(CyBle_GetState())
    {
        case CYBLE_STATE_ADVERTISING:
            return;
        case CYBLE_STATE_DISCONNECTED:
            return;
        case CYBLE_STATE_STOPPED:
            return;
        case CYBLE_STATE_CONNECTED:
            break;
        case CYBLE_STATE_INITIALIZING:
            return;
    }
    //update the GATT Database
    CYBLE_GATTS_HANDLE_VALUE_NTF_T 	tempHandle;
    tempHandle.attrHandle = handle;
  	tempHandle.value.val = val;
    tempHandle.value.len = size;
    CYBLE_GATT_ERR_CODE_T ret = CyBle_GattsWriteAttributeValue(&tempHandle,0,&cyBle_connHandle,flags);
    if(ret != CYBLE_GATT_ERR_NONE) // this is really not a good place to be.
    {
        return;
 
        CYASSERT(0);
        while(1);
    }
    // if peer initiated then write response.
    if(flags == CYBLE_GATT_DB_PEER_INITIATED)
        CyBle_GattsWriteRsp(cyBle_connHandle);
    else if(notify) // If notify & local initiated 
    {
        CyBle_GattsNotification(cyBle_connHandle,&tempHandle);
    }    
}

The next block of code is the BleCallback.  One cool thing that PSoC Creator does is give you the ability to #ifndef to remove code when a schematic page is disabled.  In the code below when I have “disabled” the Bootloadable schematic page it will remove that block of code from my firmware.

/***************************************************************
 * Function to handle the BLE stack
 **************************************************************/
void BleCallBack(uint32 event, void* eventParam)
{
    CYBLE_GATTS_WRITE_REQ_PARAM_T *wrReqParam;
    switch(event)
    {
        /* if there is a disconnect or the stack just turned on from a reset then start the advertising and turn on the LED blinking */
        case CYBLE_EVT_STACK_ON:
        case CYBLE_EVT_GAP_DEVICE_DISCONNECTED:
            CyBle_GappStartAdvertisement(CYBLE_ADVERTISING_FAST);
            PWM_Start();
            memset(&notifyFlags,0,sizeof(notifyFlags));
        break;       
 
        case CYBLE_EVT_GAP_DEVICE_CONNECTED:           
            PWM_Stop();
            updateGattDB(&BLEIOT_local.led0,sizeof(BLEIOT_local.led0),notifyFlags.led0,CYBLE_CY8CKIT021_LED0_CHAR_HANDLE,CYBLE_GATT_DB_LOCALLY_INITIATED);
            updateGattDB(&BLEIOT_local.button0,sizeof(BLEIOT_local.button0),notifyFlags.button0,CYBLE_CY8CKIT021_BUTTON0_CHAR_HANDLE,CYBLE_GATT_DB_LOCALLY_INITIATED);
        break;
 
        case CYBLE_EVT_GATTS_WRITE_REQ:
            wrReqParam = (CYBLE_GATTS_WRITE_REQ_PARAM_T *) eventParam;
           // Bootload
            #ifndef BootLoadable__DISABLED
            if(wrReqParam->handleValPair.attrHandle == CYBLE_CY8CKIT021_BOOTLOAD_CHAR_HANDLE)
            {
                if(wrReqParam->handleValPair.value.val[0]) Bootloadable_Load();
 
            }
            #endif
 
            // LED0
            if(wrReqParam->handleValPair.attrHandle == CYBLE_CY8CKIT021_LED0_CHAR_HANDLE)
            {
                BLEIOT_updateLed0(wrReqParam->handleValPair.value.val[0]);
                updateGattDB(wrReqParam->handleValPair.value.val,1,notifyFlags.led0,CYBLE_CY8CKIT021_LED0_CHAR_HANDLE,CYBLE_GATT_DB_PEER_INITIATED);
            }
 
            if(wrReqParam->handleValPair.attrHandle == CYBLE_CY8CKIT021_LED0_CCCD_DESC_HANDLE)
            {
                notifyFlags.led0 = wrReqParam->handleValPair.value.val[0];
                CyBle_GattsWriteRsp(cyBle_connHandle);
            }
 
            // BUTTON 0
            if(wrReqParam->handleValPair.attrHandle == CYBLE_CY8CKIT021_BUTTON0_CCCD_DESC_HANDLE)
            {
                notifyFlags.button0 = wrReqParam->handleValPair.value.val[0];
                CyBle_GattsWriteRsp(cyBle_connHandle);
            }
        break;  
 
        default:
        break;
    }
}

Finally the last block of code is the main loop

int main()
{
    CyGlobalIntEnable;
    BLEIOT_Start();
 
    EZI2C_Start();
    EZI2C_EzI2CSetBuffer1(sizeof(BLEIOT_local),1,(uint8 *)&BLEIOT_local);
 
    CyBle_Start(BleCallBack);
 
    for(;;)
    {
 
        #ifndef BootLoadable__DISABLED
        // if they write into the BLEIOT_local.bootload (from EzI2C)
        if(BLEIOT_getDirtyFlags() & BLEIOT_FLAG_BOOTLOAD || BLEIOT_local.bootload)
        {
            // enter the bootloader
            Bootloadable_Load();
        }
 
        #endif
 
        if(BLEIOT_getDirtyFlags() & BLEIOT_FLAG_LED0)
        {
            BLEIOT_updateLed0(BLEIOT_remote.led0);
            updateGattDB(&BLEIOT_local.led0,sizeof(BLEIOT_local.led0),notifyFlags.led0,CYBLE_CY8CKIT021_LED0_CHAR_HANDLE,CYBLE_GATT_DB_LOCALLY_INITIATED);
        }
 
        if(BLEIOT_getDirtyFlags() & BLEIOT_FLAG_BUTTON0)
        {
            BLEIOT_updateButton0(BLEIOT_remote.button0);
            updateGattDB(&BLEIOT_local.button0,sizeof(BLEIOT_local.button0),notifyFlags.button0,CYBLE_CY8CKIT021_BUTTON0_CHAR_HANDLE,CYBLE_GATT_DB_LOCALLY_INITIATED);
        }
 
        CyBle_ProcessEvents();
        CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP);
    }
}

PSoC FIRMWARE

To make this project work I built the simplest firmware that I can think of for the PSoC4200M.  The schematic has only the BLEIOT, CapSense and the LED.

The firmware just

• Starts the components
• If the capsense is not busy then it updates the Button0 state if it has changed then rescans
• If the PRoC side writes the LED0 then it updates the state.

// Project: Example10b - PSoC
// Kit: CY8CKIT-021 Sheild
// Baseboard: CY8CKit-44 PSoC4M
//
// This project demonstrates the simplest connection to the PRoC and BLE
// It updates the LED0 based on writes from the PRoC side
// It sends out updates to the PRoC based on button processes
#include <project.h>
 
int main()
{
    CyGlobalIntEnable;
 
    BLEIOT_Start();
    CapSense_Start();
    CapSense_InitializeEnabledBaselines();
    CapSense_ScanEnabledWidgets();
 
    for(;;)
    {
        if(!CapSense_IsBusy())
        {
            uint8 b0=CapSense_CheckIsWidgetActive(CapSense_BUTTON0__BTN);
            if(b0 != BLEIOT_local.button0) // if the state has changed then send an update
                BLEIOT_updateButton0(b0);
            CapSense_UpdateEnabledBaselines();
            CapSense_ScanEnabledWidgets();
        }
 
        if(BLEIOT_getDirtyFlags() &amp; BLEIOT_FLAG_LED0)  // if the PRoC side send an update, write it
        {
            BLEIOT_updateLed0(BLEIOT_remote.led0);
            led0_Write(!BLEIOT_local.led0); // the led is active low
        }
    }
}
</project.h>

Debugging using CySmart

After I created all of the code and bootloaded it into the PRoC I used CySmart to debug it.  Once the board is reset I can see the blinking blue LED that is connected to the PRoC.   When I start CySmart I can see the “C021” board (that is the name I gave the device in the Gap settings:

When I connect to the device and explore the Gatt Database I can see the three characteristics (Boatload, LED0 and Button0).  You can recognize them from the UUIDs that I configured in the component.

When I write a 1 into the LED0 characteristic the Green LED0 lights up.

When I turn on notification for the Button0 characteristic and then touch the button I can see it turn back and forth from 0/1

Now that everything seems to be working Ill move onto the iPhone App in the next post.

On the PSoC side it will:

• Read the Capsense Button0.  If it is pressed it will send a “boatload” command to the PRoC
• Read the Capsense Button1.  Each time it is pressed it will toggle the PRoC blue LED by sending alternating On/Off
• Read the remote LED0 update and turn on/off the LED0 based on the remote command

On the PRoC side it will:

• Alternate sending a 1/0 every 500ms to the “led0” on the PSoC side
• If the Capsense Button 0 is changed from the PSoC side it will turn the Blue LED On/Off
• If it get a Bootload it will enter the bootloader

These projects are available as Example9 in the CY8CKIT-021 workspace that is in the firmware directory on github at github.com/iotexpert/CY8CKIT-021

PSoC

After creating a new schematic for PSoC 4200m, the next thing that I do is make a dependency to the components in the BLEInterface project.  This gives me access to the BLEIOT component.

When I go to the component catalog I see the “IOT” and in that tab I find the  IOT Tab with the BLEIOT component.

Now I add components for CapSense and the LED to get the final schematic.

Now assign the Pins in the cydwr.

And finally the code:

// Project: Example9b-PSoC-BLEIOT-Test
// Kit: CY8CKIT-021 Sheild
// Baseboard: CY8CKit-44 PSoC4M
//
// This project demonstrates using the BLEIOT component
// If the other side writes the LED then update it
// If the user presses button 0 then send an bootload command
// If the user presses button 1 then send an update to the button
 
#include <project.h>
 
int main()
{
    CyGlobalIntEnable; 
    CapSense_Start();
    CapSense_InitializeEnabledBaselines();
    CapSense_ScanEnabledWidgets();
 
    BLEIOT_Start();
 
    for(;;)
    {
        if(!CapSense_IsBusy())
        {
            uint8 b0 = CapSense_CheckIsWidgetActive(CapSense_BUTTON0__BTN);
            uint8 b1 = CapSense_CheckIsWidgetActive(CapSense_BUTTON1__BTN);
 
            if(b0)
                BLEIOT_updateBootload(1); // send the bootload command
 
            if(b1 != BLEIOT_local.button1) // if the button state has changed send it
                BLEIOT_updateButton1(b1);
 
            CapSense_UpdateEnabledBaselines();
            CapSense_ScanEnabledWidgets();
        }
 
        if(BLEIOT_getDirtyFlags() &amp; BLEIOT_FLAG_LED0) // other side wrote LED0, update state
        {
            BLEIOT_updateLed0(BLEIOT_local.led0); // update local state
            led0_Write(!BLEIOT_remote.led0); // the LED is active low
        }
    }
}
</project.h>

PRoC

Unfortunately it is prohibited to create custom components for PRoC BLE devices.  So, the first thing that I do after creating the project is to copy over BLEIOT_BLEIOT.c and BLEIOT_BLEIOT.h from the generated source directory of the PSoC project.  Yes I understand that this is a bit of a lame thing to do, but there it is:

cd Example9a-ProC-BLEIOT-Test.cydsn/
cp ../Example9b-PSoC-BLEIOT-Test.cydsn/Generated_Source/PSoC4/BLEIOT_BLEIOT.* .

One you have the files in the correct directory you need to add them to the project by right clicking on the “header files” in the workspace explorer and “add existing” then adding the BLEIOT_BLEIOT.h.  You also should do the same with “source files” and BLEIOT_BLEIOT.c

Finally you need to add #include “BLEIOT_BLEIOT.h” to the top of BLEIOT_BLEIOT.c

After that I finish the schematic.  First, add a UART Component to the schematic and call it BLEIOT_UART (so that it will match the code that was generated in the other project).  Then add the bootloadable and the blue LED pin.  Don’t forget to configure the Bootloadable to link to the bootloader just like Example 8.  Also you need to configure the UART to have a 32 byte software buffer.

Then assign the pins:

Finally the main.c

// Project: Example9b-PRoC-BLEIOT-Test
// Kit: CY8CKIT-021 Sheild
// Baseboard: CY8CKit-44 PSoC4M
//
// This project should be bootloaded into the PRoC.  It demonstrates using the BLEIOT
// component.
//
// Using the systick, send an update to led0 every 500ms
// If the other side writes to Bootload... then start the bootloader
// If the other side writes to the button1... then display that on the blue led
#include <project.h>
#include "BLEIOT_BLEIOT.h"
 
int countMs =0;
 
// This is the ISR for the systick
void sendLedUpdate()
{
    if(countMs++&lt;500) // count 500ms
        return;
    countMs = 0;
    BLEIOT_updateLed0(!BLEIOT_local.led0);
}
 
int main()
{
 
    CyGlobalIntEnable; 
    CyDelay(100);
    BLEIOT_Start();
 
    CySysTickStart(); // start the systick and register our call back
    CySysTickSetCallback(0,sendLedUpdate);
 
    for(;;)
    {
 
        if(BLEIOT_getDirtyFlags() &amp; BLEIOT_FLAG_BOOTLOAD)
            Bootloadable_Load();
 
        if(BLEIOT_getDirtyFlags() &amp; BLEIOT_FLAG_BUTTON1)
        {
            BLEIOT_updateButton1(BLEIOT_remote.button1);
            blue_Write(!BLEIOT_local.button1);
        }
    }
}
</project.h>

As always these projects are available in the firmware directory at http://github.com/iotexpert/CY8CKIT-021

In the next post Ill show you the BLE Firmware.