Error: jtag status contains invalid mode value – communication failure = SOLVED!

This issue bugged me a long time, finally I solved it this evening. Debugging code on my PIP-Watch using my ST-LINK-v2 JTAG debugger was very painful because the debugger software — OpenOCD and GDB — kept failing randomly during debug sessions with a rather cryptic message:

Error: jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms

I scratched my head, updated firmware in ST-Link, looked at JTAG/SWDIO signals using a scope… But nothing helped.

Finally I found this message in a discussion forum. The problem is in the low-power mode! When CPU core clock is halted the debugger connection fails and debug session is halted.

I am using low-power mode to halt CPU clock when OS is idle – in vApplicationIdleHook() function I have the __WFI() – wait for interrupt – intrinsic function.

The solution is either to entirely disable low-power modes, or allow low-power debugging in the DBGMCU_CR register:

1
DBGMCU_Config(DBGMCU_SLEEP | DBGMCU_STOP | DBGMCU_STANDBY, ENABLE);
DBGMCU_Config(DBGMCU_SLEEP | DBGMCU_STOP | DBGMCU_STANDBY, ENABLE);

This code must be executed during CPU initialization before any low-power mode is first activated. After this, debugger connections will be kept even in sleep, standby and stop modes. The problem is gone!

Processor Low-power Optimizations in PIP-Watch

Processor Power

The PIP-Watch is a battery-powered device that will be continuously on, hence the average power consumption is one of the most important engineering aspects.

In this post I will go through two simple steps of optimizing CPU power – sleep modes and lowering the clock frequency. In a next separate post we will look into Bluetooth module power.

Continue reading “Processor Low-power Optimizations in PIP-Watch”

PIP-Watch Boards & Assembly

The printed circuit boards for PIP-Watch Zero came from Pragoboard fab on Friday 12 Sept. I ordered three pieces because the cost is practically identical as for two or one.

PIP-Watch Zero: Pristine PCBs from fab
PIP-Watch Zero: Pristine PCBs from fab

On Saturday I assembled one board, and on Sunday I tested it and started working on firmware. I had some problems with PLL in the microcontroller  – the CPU hard-resetted the instant the PLL  was enabled. Eventually I found a bad solder joint on one of the CPU’s power supply pins.

PIP-Watch Zero: Assembled board from the bottom
PIP-Watch Zero: Assembled board from the bottom
PIP-Watch Zero: Top PCB side, unfolded.
PIP-Watch Zero: Top PCB side, unfolded.

So far I tested the CPU & JTAG, the eInk EPD display, Bluetooth modem access (but not the BT communication itself), and LEDs. I had issues with bad solder joints (both shorts and cold joints) because the PCB footprint for the CPU (the LQFP64 package) was apparently designed for the reflow process, and it is not suitable for hand soldering. Silly KiCAD libraries!

PIP-Watch Zero: Assembly

 

Measuring crystal frequencies:

SAMSUNG SAMSUNG

PIP-Watch “Zero” – Schematic, BOM, and Layout

Schematic [PDF], BOM, and PCB layout for my PIP-Watch “Zero” was completed during this week. Layout data was sent to a local PCB fab – pragoboard.cz. The board should be ready and shipped during the next week.

The PCB is is 80mm*35mm. The top side is dedicated to the EPD display, battery (underneath the display), 3 push-buttons and 4 LEDs. The bottom side carries all the main electronics – processor, bluetooth modem, display driver, and power source.

All design files are in the project repository.

PIP-Watch Zero - Layout top side
PIP-Watch Zero – Layout top side
pipzero-hw02-layout-bottom
PIP-Watch Zero – Layout bottom side

Framebuffer Drawing with u8glib [VIDEO]

GDE021A1 is a graphics display with a resolution 172×72 pixels, each pixel is 2 bits deep (4 shades of grey). The display has an internal controller SSD1606 with a framebuffer. The framebuffer size is 172*72*2/8=3096 Bytes. When the display is powered up, the system processor sends initialization sequence that first sets up controller’s internal registers (the controller SSD1606 is fairly generic) and then sends new framebuffer content. The display controller then autonomously pushes the framebuffer contents to the physical screen.

The display controller can be configured to orient the framebuffer almost any way. I configured it into a landscape mode, with the X-axis going right and the Y-axis down, as shown on the photo.

Continue reading “Framebuffer Drawing with u8glib [VIDEO]”

EPD Display Working!

Today I have managed to get the GDE021A1 ePaper display (EPD) working! I used my minimal EPD-Driver board, which implements a flat-flex cable connector and a booster circuit for the display. The booster generates high voltages needed for display operation (around +-25V). The display is driven by STM32F101 Cortex-M3 CPU, mounted on a universal PCB. The picture below depicts my workbench setup (click to see a full-size image):

EPD Driver Prototype-workbench view with captions
EPD Driver Prototype-workbench view with captions

Continue reading “EPD Display Working!”

Li-On Battery Charging (and Discharging)

In my PIP-Watch project I will use a Li-On battery to provide power. Li-On batteries are easy to use in hobby projects: they are light, small, with high capacity, and they come in variety of sizes. Most (not all) Li-On batteries have nominal voltage 3.7V, hence you can directly power your standard 3.3V digital logic directly, using only a simple low-drop linear regulator (e.g. LD59015).

For my first experiments I chose Nokia BL-4C Li-On battery. It’s nominal voltage is 3.7V, charging (maximal) voltage is 4.2V, the capacity is 860mAh.

Continue reading “Li-On Battery Charging (and Discharging)”

Bluetoothing to Android Tablet

Today I tried pairing my UART-to-Bluetooth adapter to a Nexus 7 tablet to see how it works. On the tablet I used BlueTerm, an open-source terminal emulator for communicating with any serial device using a bluetooth serial adapter.

I connected my Bluetooth adapter through a USB/UART adapter to a PC. On the PC in a terminal emulator the following sequence of commands is sent to the BT adapter:

///
at*agln="PIP-Watch",0
at*agfp="1234",0
at*addm

The three slashes are an escape sequence to put the adapter into the AT-mode. Then we set BT device name and a PIN. Finally we exit the AT-mode, entering data mode. The adapter now awaits BT connections.

On a tablet or phone we search for BT devices in the vicinity. The BT module should appear in the list, and we pair the tablet with it. Android may ask for a PIN number, which is 1234. After pairing it is possible to connect to the adapter using, for instance, the BlueTerm app in android.

On a slightly separate note, I also tried creating my first Android app. I just followed a tutorial on developer.android.com and everything worked just fine, even thou I am running ‘bleeding-edge’ Fedora 20 on the PC. The only problem was with access permissions to an android device in Linux. The adb (android debug server) reported error “(?????? no permissions)”, but this post on stackoverflow.com solves the issue.

Links: