Sigrok is Awesome!

Just today I reviewed the sigrok project and found that they currently support my RIGOL DS1102E oscilloscope.  This is great, I wondered if that included protocol decoding as well.  I build the code from the latest git clones for each of the sub-projects that I needed, and went off to work trying this out.  I didn't take screenshots of the first few times I connected to the scope, as they just worked and I was more interested in getting to the protocol decoding.  I fired up my copy of CrossWorks for Arm and started writing some simple code to send data to a UART.  You can see this in the screenshot below.

UART Code for the first test.

Once I had that done, I flashed the firmware to a small Cortex-M0 development board I have and connect it to USB TTL serial converter.  The data was sent to my development workstation and I saw it in a screen session.  Next, I hooked up the oscilloscope probes to the proper micro-controller pins and connected to the oscilloscope with pulseview.  The screenshot below shows the traces, and the protocol being decoded!

UART signals decoded.

I also took a combined screenshot of how I was actually working with pulseview and CrossStudio at the same time.  Sometimes, people find that interesting.

Working with pulseview and CrossStudio.

I recorded a video of me working with pulseview and CrossStudio as I change code and view the firmware output.

Well, Until the next time.

Power Supply In Action...

My friend Heshem thought it would be a great idea to show the power supply in action.  Here it is! There is also a first look at my prototype board for connecting the ESP8266 - 01 WiFi module to my development board.

Here is a quick look at my workbench prior to clean up:

Slightly messy workbench

Here is a close up look at that prototype connection board:

Board without WiFi module connected

Well, until next time.

Fixed Power Supply Distraction

I recently realized that I was spending time and money rebuilding 5.0  and 3.3 volt dc power supplies for prototypes a lot.  Thinking about this for a few days, I designed and built a new fixed power supply with 2 channels (5.0 and 3.3 volts dc).  As is typical for me, I didn't capture all the pictures I wish that I had.  However, I do have quite a few, and two videos.

Here are the pictures I have of cutting the front face plate:

Some of the parts laid out, with the cutting template on the face plate.

Up close of the template on the face plate.

About to drill channel 1's on / off switch hole in the face plate.

Test fitting components into the face plate.

Shot of my new drill press that I used to cut the face plate.

The face plate with almost all of the holes (final version has mode button).

After fitting most of the components, and drilling and filling the case with the power supply components, I took a video.  I remembered I didn't have pictures of building the modular power supply channels.

Today, I was able to finish this up (including the code on the Arduino nano) and make it usable.  Here are the pictures I have of the final unit.

The back of the unit shows the fuse and power button.

The back of the unit with the fuse installed and power button turned on.

The front of the unit.

The normal mode of the unit.

The summation mode of the unit.

The maximum mode of the unit.

The unit with both channels powered on.

Lastly, I took a video to demo the features I built into the power supply.

Here is the list of interesting / cool things I did while building / programming this power supply.

• I averaged the samples in order to lower the effect of noise on the readings.
• I over-sampled the channels to taking the 10-bit ADC up to a 12-bit ADC for more accuracy.
• I used a hardware debounce circuit for the button, so the firmware didn't waste time on that.
• I designed the firmware to run continuously, so it samples as fast as possible.
• I minimized the amount of ram I used down to 38% of the available 2048 bytes of ram.
• Optimized the display driver, which allows refreshing the LCD without clearing it's ram.

Well, until next time.  Now, back to the previous research project I was working on.

FreeRTOS Tasks in Eclipse

I have been working with FreeRTOS for a while and finally decided to figure out how to properly get Eclipse to show the tasks as threads.  It is quite useful to know what other tasks are doing when you are debugging problems in your firmware.  This is a matter of enabling features within OpenOCD by changing configuration files for your target.  This post will center around configuring this for STMicroelectronics chips.  The first thing I would like to show is a working Eclipse/OpenOCD/GDB debug setup.

Non RTOS based Debug Setup Part 1

The above picture shows the normal setup I was using, a single configuration file for my target board.

The next picture shows the settings I used, to stop in main.

Non RTOS based Debug Setup Part 2

The contents of that file is below:

## This is the Test Rom Board
## Core429I Board
## STM32F429IGT6 ARM Cortex-M4
## Use the STLINK V2 Debug Probe
source [find interface/stlink-v2.cfg]

## This is setup with Serial Wire Debug
set WORKAREASIZE 0x20000
transport select hla_swd

## Use Generic STM32F4x chip setup support
source [find target/stm32f4x.cfg]

## Reset (software only reset)
reset_config srst_only srst_nogate

## Boost Adapter speed to 4 MHz
adapter_khz 4000

## Configure SWO/SWV
## System Core Clock 180 MHz
## Baud Rate 2 Mbaud/s
tpiu config internal debug.log uart off 180000000 2000000

The results of all of this configuration are shown below in the debugging screenshot:

Non RTOS Debugging Session

As you can see, there is a single thread.  This only allows me to see the exact spot in the code that I have currently stopped.  I would much rather be able to see what other tasks were running at the same time, and where they were in their execution at the exact moment the debugger halted everything.

In order for this to work, as the manual describes, we have to change the configuration file for the target to support using RTOS features.  Since I am using the STM32F4 series chips, I copied the stm32f4x.cfg file from /usr/share/openocd/scripts/target/stm32f4x.cfg to my utility directory in my code repository.  Once this file was copied I modified it to use the RTOS auto discovery, as shown below:

Modifying the stm32f4x.cfg file for RTOS debugging

I have highlighted the added text to enable auto discovery of RTOS usage.  The next thing I did was add a file called FreeRTOS_openocd.c to my project, the contents of this file are below:

/*

 * Since at least FreeRTOS V7.5.3 uxTopUsedPriority is no longer

 * present in the kernel, so it has to be supplied by other means for

 * OpenOCD's threads awareness.

 *

 * Add this file to your project, and, if you're using --gc-sections,

 * ``--undefined=uxTopUsedPriority'' (or

 * ``-Wl,--undefined=uxTopUsedPriority'' when using gcc for final

 * linking) to your LDFLAGS; same with all the other symbols you need.

 */

#include "FreeRTOS.h"

#ifdef __GNUC__

#define USED __attribute__((used))

#else

#define USED

#endif

const int USED uxTopUsedPriority = (configMAX_PRIORITIES -1);

Next, I modified my makefile to include a new linker option, which allows OpenOCD to work correctly with the RTOS features.  The linker option I added was:

-Wl,--undefined=uxTopUsedPriority

I rebuilt the entire project (make distclean; make all -j16) to rebuild all the modules.  I usually only do this when I need to rebuild standard peripheral libraries, FreeRTOS etc.  Usually, I only have to rebuild the application code I am working in.  

I then tested this by using OpenOCD and GDB from the command line to ensure that this worked, the steps are below:

1. run in a terminal: openocd -f interface/stlink-v2.cfg -f stm32f4x_RTOS.cfg
2. run in a terminal: arm-none-eabi-gdb build/debug/core4x9i.elf
3. execute the following commands inside the GDB session:
1. target remote localhost:3333
2. continue
3. Control-C
4. info threads

The first step is shown below

Running OpenOCD configured for RTOS debugging

The second step is shown in the following screenshot:

Connecting GDB to OpenOCD for RTOS debugging

The third step, which shows the threads feature working is below:

RTOS task info as threads in GDB

This is great, it's all working properly now.  Might as well set this up inside Eclipse so we can debug in an easier way.  

The first debug configuration page in Eclipse starts out with the proper files for starting OpenOCD as follows:

RTOS debug setup part 1

The second configuration page is below:

RTOS debug setup part 2

You may have noticed the change to the "Set breakpoint at" setting, this value has been changed to the first task that gets started: logger_task.  You need to do this, otherwise the debugger will become confused and not present you with the normal Eclipse debug experience.  This stems from the fact that it won't know about the tasks unless you allow them all to start, prior to hitting a break point.  I know, I know, there are times when you want to debug without the RTOS threads!  So keep two configurations, RTOS enabled and not.  This way you can debug start up as well as the RTOS tasks.

Either way, once you have this all completed and working, it should look like the debug session below:

RTOS debug session in Eclipse

Now, like me, you can have two debug configurations.  Have fun coding!

Useful Embedded System Log output

I put my previous project on hold recently, as I wanted to create a better way of logging system status in my embedded projects.  Luckily for me, the people who make vcdMaker already had a great way to do this.  In the video below, I got a bit more into detail about how I log the information.  Please visit the vcdMaker website and check out the videos, they are really good.  I hope that you find vcdMaker as useful as I do.

The log output is only as good as it's time stamp, so I wanted to ensure that my time stamp was good.  I usually run my SysTick handler at 1 kHz or 1 ms tick rate.  I enabled a general purpose input / output pin on the STM32F429 micro controller and had it toggle on and off.  I was able to verify with the Logic Analyzer and the Scope that the tick rate is indeed 1 kHz. You can see those screen captures below.

Logic Analyzer screen capture

Oscilloscope screen capture

My system clock and advanced high performance bus clocks are setup as 180 MHz.  The advanced peripheral bus 1 clock is set to 45 MHz, while the advanced peripheral bus 2 clock is set to 90 MHz.

This allows me to set USART 1 to 115200 baud, for now this is adequate.  I may need to speed this up in the future.  The USART Driver is called from the _write() system call, which allows me to use stdio printf function to print the messages to the USART.  

I created a little API to log messages:

log_signal_message(char* signalname, uint8_t signal_size, char* format, ...)

log_signal_event_message(char* signalname, char* format, ...)

log_message(eMessageType_t type, char* format, ...)

The messages logged by these functions are queued for the logger task to print to the USART.  The logger task is only 1 priority level higher than the idle task.  This allows the logger task to send messages without interfering with tasks that have higher priority.  The logger task uses a blocking call to receive from the queue, with a delay set to the maximum available.  The allows the task to only work when it must.  The video below gives some more information as well as a short demo of how I am using this setup.  Hopefully, you find this useful.

Debug Console

This is a quick post to show the debug console in my current project.  The project uses a STM32F4 Cortex M4 micro controller, and I have used Putty to connect to the debug out USART.