Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Monday, May 1, 2017

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!






Saturday, March 25, 2017

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.



Saturday, November 26, 2016

ITM Setup for debugging in GNU ARM projects

I finally got around to setting up ITM (Instrumentation Trace Macrocell) based output for debugging.

The first thing I did was setup OpenOCD to handle the output from the processor.  I have included my configuration file for  OpenOCD 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 important part of this configuration file is the last section, denoted by the Configure SWO/SWV comment.  This is all explained very well in the OpenOCD documentation for tpiu config.  I modified my configuration to spit the ITM output to debug.log, you need to give the SysCoreClock frequency in Hertz, as well as specify the baud rate.

The next thing you need to do is implement at least the _write system call.  I have included my implementation of that method below:

int _write(int file, char *ptr, int len)
{
  REQUIRE(file);
  REQUIRE(ptr);

  ENSURE(len >= 0);

    int DataIdx;

    switch(file)
    {
    case STDOUT_FILENO:
    case STDERR_FILENO:

        for (DataIdx = 0; DataIdx < len; DataIdx++)
        {
            ITM_SendChar(*ptr++ &(uint32_t)0x01FF);
        }
        break;
    default:
    break;
    }

    return len;
}

If you are curious about the REQUIRE and ENSURE macros, you can find out about them here.  The linker options need to include the following to allow you to link against the nano c lib:

-lm --specs=nano.specs --specs=nosys.specs

In order to view the SWO/SWV output you need to use a viewer for the file, I am using swo-tracer that was written by Andrey Yurovsky.   I tested the whole setup and received a Hello World! out of my embedded code as shown below.




Saturday, March 5, 2016

Syntax files for UltraEdit on Linux

I wanted to make sure that the wordfiles used by UltraEdit on my workstation were up to date.
I am sort of lazy sometimes and really get tired of copying them from the website and placing them in the folder.

As it turns out IDM Computer Solutions uses github to handle the storage of it's wordfiles for UltraEdit, this is great.  On Linux, when you install UltraEdit the default wordfile directory is ~/.idm/uex/wordfile.

I went to the directory above the wordfile directory, ~/.idm/uex and removed the wordfile directory and then cloned the repository from IDM using the following command:
git clone https://github.com/IDMComputerSolutions/wordfiles.git.

Now, when I start up ultra edit it has all the syntax files available.  The real bonus now is that all I have to do is do is go to the wordfiles directory and do a git pull, to get the latest wordfiles.

Sunday, June 7, 2015

Linux Mint display resolution fix ( MAG 700P )

Don't you just hate it when you know that your LCD monitor can do some specific resolution, but  Xorg doesn't want to have any parts of it?

I do as well!  Here is a small fix that worked for me in relation to my MAG 700P LCD monitor.
First I found the correct mode line by running the following command:

cvt 1280 1024

This command will spit out the mode line for running a monitor at 1280 x 1024 @ 60 Hz:

# 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync


Now that I have the new mode line in hand, I can add it as a new mode to my current output device.

Test this information by running the following commands:

xrandr --newmode "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync
xrandr --addmode VGA1 1280x1024_60.00
xrandr --output VGA1 --mode 1280x1024_60.00


If all of these commands are successful, then we should see the display switch to 1280x1024 mode.

These commands were successful for me, so I added them to a .xprofile file in my user directory.

** Note this only changes to 1280x1024 for my user **

Now, this doesn't matter as I am the only user of this computer.

Screenshot: