Small Soldering, but not too small.

I had to use the microscope for these, but they were all done with chisel tip pencil iron.

SIOC8 / SOP8, marker for scale

Close Up with Microscope

Another SIOC8 / SOP8, marker for scale.

Close Up with Microscope

LQFP64, marker for scale.

Close Up with Microscope.

Eventual Carrier board for testing.

A Replacement for my HP 16500A

Recently I decided to upgrade some of my test equipment.  I purchased an Agilent / HP 16702B model analyzer mainframe.  This "new" analyzer can make use of several of the cards from my HP 16500C analyzer.  I cleaned off the outside of the analyzer and the touch screen with Windex.  The lower front corner of the mainframe chassis was bent, so I took it partially apart and bent the corner back.  Now the front panel sits properly on the chassis.  The picture below shows the analyzer after I got the corner fixed and panels back on.

Analyzers in the middle of switch out and repairs.

I put my 500 MHz oscilloscope and 500 MHz logic analyzer cards into the new analyzer, hooked up the keyboard and mouse and booted the analyzer.  As it turns out everything worked except the keyboard and mouse.  I had to modify the PS/2 controller board to add some resistors to make the keyboard and mouse work.  The pictures below show the board that I modified.

Original Board (solder in empty pads)

Solder cleaned out of empty pads.

PS/2 Pull-up Resistors (1 kΩ) Added.

After that modification, the keyboard and mouse worked great.  Now that the keyboard works, I could interrupt the boot process on the 16702B and change some configuration parameters.  The picture below shows the analyzer outputting it's screen to a nice 23 inch LED flat panel monitor.

Analyzer Mainframes all working again.

I was also able to find a way to enable all the options for this analyzer as long as I don't use it for commercial purposes.  This analyzer is way more complicated than the previous model, so I will need some time to adjust to it and be able to utilize all the features properly.  The pictures below are screen captures of me playing around with the analyzer.

Testing Scope using signal generator.

Testing logic analyzer and scope with uart data.

That's all for now, I need to finish routing a board I am working on.

HP 16500 C Hard Disk Upgrade

I decided to take the time to upgrade the hard drive in my HP 16500 C model mainframe test instrument.  I was able to find a very helpful information on a few sites. Such as the K04BB Wiki, OpenGPIB, KD8TBD's Blog, and Philip Pemberton's website.  This helped me decide to try the upgrade of the hard drive to a compact flash card.  I purchased a StarTech Adapter, BR &TD 256 Meg Compact Flash card, and a SanDisk 512 Meg Compact Flash card.  I also purchased a SD card to IDE adapter, to experiment and try.

After I unhooked the IDE drive and hooked up the SD card adapter the hard disk test failed on boot, as expected.

hard disk boot test failure.

The SD card adapter and SD card was recognized by the mainframe, but it timed out while trying to format.  You can (sort of) see that I have it hooked up in the picture below.  The fact that it tried to format the SD card as a drive was promising.  I really thought it might work, but it timed out, then locked up. Failure!  That's okay, I still had the Compact Flash card adapter to try out.

SD Card adapter experiment.

I unhooked the SD Card adapter and hooked up the Compact Flash card adapter.  

Compact Flash adapter experiment.

The mainframe recognized the "hard drive" again and this time actually formatted it!  Success!  Immediately I started copying over the Operating System files for the mainframe and the test files.  

Copying Files to Compact Flash "Hard Drive".

Once the files were all copied over, it was time to reboot the mainframe.  I removed the floppy disk that it booted the machine and reset the power button.  Just as I hoped, there was a passing hard drive test.  

Passing Hard Drive boot test.

The mainframe booted into the OS from the compact flash card, I ran all the tests and they passed.  Now all I had to do was tidy up the install of the compact flash adapter and button up the mainframe. 

Compact Flash Adapter installed.

Once the adapter was securely attached to the same location that the original hard drive was, I put all the covers back on.  This last picture is the HP 16500 C mainframe running off the new "hard drive" while the old hard drive is sitting next to it.  I never actually tested to see if the SanDisk Compact Flash card would format and work.

Mainframe with old hard drive out.

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!