Wednesday, July 6, 2016

Nuttx Traceable Builds

With a Nuttx.org / https://github.com/nuttx   derived software build I find myself on a steep learning curve, a new OS that is evolving, and finding software issue(s) - mostly mine :).

The very nature of software development.

Nuttx covers a lot of different processor families and processors within those families  ~ all with a uniquely created .config to define a specific build.

A lot of options, and not [many|any]  test setups. Very easy to delete that .config while building features.

While there is a lot of functionality and leading edge stuff-  when hitting  an issue it very much  feels like the bleeding edge.

Of course if its my application software that has the issue - I can solve it and update the build:). If it appears a  nuttx software its a challenge learning it, and all those layers and configuration parms. How is it supposed to work ?

So how to provide a definitive reference build, that I can come back to, or anybody else on the net can easily access when an issue comes up.?  Or if a minor issue, I can capture the description in a bug description, and move on. Standard stability testing philosophy.


git on bitbucket is powerful, and if the following files are changed and a pre-processor  mknx.sh run then a definitive snapshsot is captured and displayable with "nsh> uname -a"  .

This is a work in progress. So from "nsh> uname -a" it expands as follows:

NuttX 17.6 nxd47wk_wkd47tst1_20160712_2203 arm stm32f4discovery

Hopefully mostly self explanatory

<work_directory>_<branch>_<date>   <arch> <board>

<work_directory> nxd47wk - which in my terminology is nx STM32F4(07)discovery boad
<branch> wk_nxd47_wk
<date>  YYYYMMDD_HHMM

So building for stm32f4discovery on my networked Ubuntu machine (I ssh from windows)
$cd ~/git
$mkdir nxd47wk
$cd  nxd47wk
$git clone git@bitbucket.org:neilh20/anuttx.git nuttx

$git clone git@bitbucket.org:neilh20/nuttapps.git apps
$cd nuttx
$cd tools
$ ./configure.sh stm32f4discovery/nsh
$ cd ..
git checkout -b wkd47tst1
~/git/nxd47wk/nuttx (wkd47tst1)]$

edit .gitignore -->   remove /.config  /.Make.defs

edit include/nuttx/.gitignore --> remove config.h & version.h

$make menuconfigs 
Build Setup--> Build Host Platform (Linux)
System TypeàSTM32 Periperal Support [ ] OTG FS - disable CONFIG_STM32_OTGFS

<Save>

and then build - I manually update the Nuttx build# in mknx.sh

$mknx.sh
download to the target
$stwr
then in the TTY window ( I use Tera Term )
nsh>
NuttShell (NSH) NuttX-17.6
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160712_2203 arm stm32f4discovery

nsh>
So I have a build, lets provide a mechanism that can enable it to be duplicated somewhere else in the cyber world - like another directory.
Back on Ubuntu (an example)
~/git/nxd47wk/nuttx (wkd47tst1)]$ git commit -a -m "first nxtst17.6_nxd47wk_wkd47tst1_20160712_2203"

$git tag nxd47wk_wkd47tst1_20160712_2221 
$git push origin  wkd47tst1

now in another terminal window to my ubuntu machine I can duplicate that build (technically anywhere else in a nuttx linux environment with tools setup)
<New SSH term>
$mkdir nxd47tsta
$cd nxd47tsta
$git clone git@bitbucket.org:neilh20/anuttx.git nuttx

$git clone git@bitbucket.org:neilh20/nuttapps.git apps
$cd nuttx
$git checkout wkd47tst1  
$make
$stwr
and switching to the TTY connected with STM32F4(07)discovery 
- I get exactly the same build info

NuttShell (NSH) NuttX-17.6
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160712_2221  arm stm32f4discovery
nsh>

            ~!~    It worked    ~!~:)

------------------------------------
where mknx.sh is in your ~/bin

#!/bin/bash
#  make with uptodate tag - uname -a
#chmod 755
function get_branch() {
      git branch --no-color | grep -E '^\*' | awk '{print $2}' \
        || echo "default_value"
      # or
      # git symbolic-ref --short -q HEAD || echo "default_value";
}
build_num=$(date +%Y%m%d_%H%M)
#echo $(__git_ps1)
branch_name=`get_branch`;
#repo_tree=${PWD##*/}
repo_tree=$(pwd | cut -d'/' -f5)
#echo "$repo_tree"
blabel="$repo_tree""_$branch_name""_$build_num"
echo "Building $blabel"
tools/version.sh -v 17.6 -b "$blabel" .version
make

------------------
similarly I have an alias stwr to ~/bin/st-flash-wr.sh

#!/bin/bash
#chmod 755
bin_file="nuttx.bin"
if [ "$1" != "" ]; then
    #echo "Using file $1"
    bin_file=$1
fi
echo "st-flash write $bin_file 0x8000000"
st-flash write $bin_file 0x8000000
------
160713: This blog updated for a changed format nxd47wk_wkd47tst1_20160712_2203 





Tuesday, May 31, 2016

Building the App example/alarms

Configuring a nuttx/app is done with "make menuconfig"
I find myself churning through the options trying to find dependencies to subsystems to turn them on.
The top level readme does help - however the general directions are to do it through the menuconfigs and the following README.txt describes it in terms of #defines.
https://bitbucket.org/nuttx/apps/src/master/examples/README.txt
So this is how I enable the subsystem for my test board olimex-STM32-H307 with TTY on Uart2
On my build machine - Ubuntu 15.10
cd tools
./configure.sh olimex-stm32-h407/nsh   
cd ..
make menuconfig
Requires RTOS FeaturesàRTOS Hooksà[*] Custom board/driver initialization 
Requires, Drivers -->Timer Driver Support àRTC Driver Support


.
Debug options
* Enable Debug Features
* Enable Debug Verbose Output
* RTC Debug Output
* Stack Colouration
* Generate Debug Symbols

Application Configurationà Examples
* RTC Alarm driver example (with defaults)





App Config à NSH LibàDisable Individual cmds-->
[] Disable date   # turn off disable

If on a board that is missing the 32KHz clock, stm32F4discovery board,
 then the RTC can function with another clock
 System Type àRTC clock source  LSI or HSI. They don't survive reset for some reason.

make clean

make
and then download it over the ST-LINK.

The output with RTC debugging enabled - using the initial power on time, looks like this

Ideally needs to set up date first but will work without it eg
nsh> date -s "JULY 06 13:45:00 2016"

nsh> alarm 15
alarm_daemon started
alarm_daemon: Running
Oprtc_dumpregs: *** Reading Time:
rtc_dumpregs:       TR: 00003532
rtc_dumpregs:       DR: 00002101
rtc_dumpregs:       CR: 00001100
rtc_dumpregs:      ISR: 00000127
rtc_dumpregs:     PRER: 007f00ff
rtc_dumpregs:     WUTR: 0000ffff
rtc_dumpregs:   CALIBR: 00000000
rtc_dumpregs:   ALRMAR: 80003333
rtc_dumpregs:   ALRMBR: 00000000
rtc_dumpregs:   SHIFTR: 00000000
rtc_dumpregs:     TSTR: 00000000
rtc_dumpregs:     TSDR: 00000000
rtc_dumpregs:    TSSSR: 00000000
rtc_dumpregs:     CALR: 00000000
rtc_dumpregs:    TAFCR: 00000000
rtc_dumpregs: ALRMASSR: 00000000
rtc_dumpregs: ALRMBSSR: 00000000
rtc_dumpregs: MAGICREG: facefeee
rtc_dumpregs: EXTI (RTSR FTSR ISR EVT): 1011
rtc_dumptime: Returning:
rtc_dumptime:   tm_sec: 00000020
rtc_dumptime:   tm_min: 00000023
rtc_dumptime:  tm_hour: 00000000
rtc_dumptime:  tm_mday: 00000001
rtc_dumptime:   tm_mon: 00000000
rtc_dumptime:  tm_year: 00000064
rtc_dumptime: New alarm time:
rtc_dumptime:   tm_sec: 00000030
rtc_dumptime:   tm_min: 00000023
rtc_dumptime:  tm_hour: 00000000
rtc_dumptime:  tm_mday: 00000001
rtc_dumptime:   tm_mon: 00000000
rtc_dumptime:  tm_year: 00000064
irtc_dumpregs: *** Set AlarmA:
rtc_dumpregs:       TR: 00003532
rtc_dumpregs:       DR: 00002101
rtc_dumpregs:       CR: 00001100
rtc_dumpregs:      ISR: 00000027
rtc_dumpregs:     PRER: 007f00ff
rtc_dumpregs:     WUTR: 0000ffff
rtc_dumpregs:   CALIBR: 00000000
rtc_dumpregs:   ALRMAR: 80003548
rtc_dumpregs:   ALRMBR: 00000000
rtc_dumpregs:   SHIFTR: 00000000
rtc_dumpregs:     TSTR: 00000000
rtc_dumpregs:     TSDR: 00000000
rtc_dumpregs:    TSSSR: 00000000
rtc_dumpregs:     CALR: 00000000
rtc_dumpregs:    TAFCR: 00000000
rtc_dumpregs: ALRMASSR: 00000000
rtc_dumpregs: ALRMBSSR: 00000000
rtc_dumpregs: MAGICREG: facefeee
rtc_dumpregs: EXTI (RTSR FTSR ISR EVT): 1011
ng /dev/rtc0
rtchw_set_alrmar:   TR: 00003532 ALRMAR: 80003548
Alarm set in 15 seconds
nsh>

(then when the alarm goes off)

rtc_dumpregs: *** Reading Time:
rtc_dumpregs:       TR: 00003548
rtc_dumpregs:       DR: 00002101
rtc_dumpregs:       CR: 00001100
rtc_dumpregs:      ISR: 00000127
rtc_dumpregs:     PRER: 007f00ff
rtc_dumpregs:     WUTR: 0000ffff
rtc_dumpregs:   CALIBR: 00000000
rtc_dumpregs:   ALRMAR: 80003548
rtc_dumpregs:   ALRMBR: 00000000
rtc_dumpregs:   SHIFTR: 00000000
rtc_dumpregs:     TSTR: 00000000
rtc_dumpregs:     TSDR: 00000000
rtc_dumpregs:    TSSSR: 00000000
rtc_dumpregs:     CALR: 00000000
rtc_dumpregs:    TAFCR: 00000000
rtc_dumpregs: ALRMASSR: 00000000
rtc_dumpregs: ALRMBSSR: 00000000
rtc_dumpregs: MAGICREG: facefeee
rtc_dumpregs: EXTI (RTSR FTSR ISR EVT): 1011
rtc_dumptime: Returning:
rtc_dumptime:   tm_sec: 00000030
rtc_dumptime:   tm_min: 00000023
rtc_dumptime:  tm_hour: 00000000
rtc_dumptime:  tm_mday: 00000001
rtc_dumptime:   tm_mon: 00000000
rtc_dumptime:  tm_year: 00000064
alarm_demon: alarm 0 received

Saturday, May 28, 2016

How to download nuttx for a Feature Branched Workflow

This is a series of blogs (my self documentation) on using Nuttx in a branched workflow.
Hopefully its of use to others.
This assumes you already have a viable build environment on your local machine.
This assumes you have already forked the nuttx repo's on bitbucket
Ideally your fork is sycned to a release tag - but that is advanced code management for another discussion.
Now you need to download the repos to a local machine  before they can be build.
There are many workpractises that can accomplish this - so I'm sharing the one I've evolved.
The target is to be eventually do a "polished" Pull Request back into the  main nuttx. There is a fierce guardian of the repo - so while a users main effort might be creating the code, possibly if like me quite messily, the activity of submitting back to the nuttx repos of working code can be a process in itself.
So as per the Feature Branched Workflow guidelines I consider creating one local instance of nuttx for working on - with a branch usually starting with "work..."  and then when submitting it creating another local nuttx instance got staging and polishing the code ... with a branch possibly beginning "pr.."
Nuttx can be built for a number of processors or starting configurations, I find it useful to create my local nuttx instance with a defined naming scheme

I use a postfix nxZZ for each directory,  as I found a need for different instances of Nuttx as the development progress
nxtipXXX - direct bitbucket/nuttx with target build
nxoh4wk - nuttx Olimex-STM32-h407 Work tree 
nxoh4sg - ditto stage tree
nxnkl25<xx> - nuttx  NXP FRDM-KL25 work/stage
nxnk64<xx>  - nuttx NXP FRDM-K64 work/stage

So assuming the target environment is Olimx-STM32-h407 I create two directories 
$ cd git
mkdir nxtipoh4   #my top level directory for pure nuttx code from tip built for Olimex-STM32-h407
mkdir nxoh4wk

cd nxoh4wk
#I've forked to the specific repos below
git clone git@bitbucket.org:<user>/anuttx.git nuttx
git clone git@bitbucket.org:<user>/nuttapps.git apps
#if first time on machine using make menuconfig - need to set up Kconfigs)
git clone https://bitbucket.org/nuttx/tools.git tools

#end first time Kconfigs

cd nuttx
  
$ tools/version.sh -b 160405_1103 -v 7.15 .version
make distclean

cd  tools
#use a starting config
./configure.sh olimex-stm32-h407/nsh

cd ..

source setenv_xx.sh (if first time)

make menuconfig #ensure host is correct, save and then exit to use latest format

make #test build, should work and be tested before continuing
(cable to serial port, teraTerm 19200 to serial port)

#next create the working feature branched workflow environment of your choice
git checkout -b work_featurebranchAA
cd ../apps
git checkout -b work_featurebranchAA

# now can edit in either nuttx or apps and it will be tracked.

#Optionally an instance can be created for the tip - and differences between the forked branch can be seen using meld or something similar.

cd ../nxtipoh4
git clone git@bitbucket.org:nuttx/nuttx.git nuttx
git clone git@bitbucket.org:nuttx/apps.git apps

# then build - see above

tutorial: bitbucket setup Feature Branched Workflow for nuttx (single git repository)

This is a series of blogs (my self documentation) on using Nuttx in a branched workflow.
Hopefully its of some use to others.

"Nuttx OS" on bitbucket for the beginner has a two git module configuration - bitbucket.org/nuttx/nttuxt and bitbucket.org/nuttx/apps The "apps" may be replaced by a custom configuration later.
My development environment is Ubuntu 15.10, with Meld to do differencing. 
Meld required Ubunutu 15.10
The editing is done in Eclipse Mars on Windows10 over the network to Ubuntu. I login in remotely to the Ubuntu machine to compile.

Some references

To start, sign-in to bitbucket.org with your own account , then clone the following into your <userSpace> on bitbucket
I use a prefix ZZ as you might want to experiment with different instances of Nuttx as the development progress
bitbucket.org/patacongo/nuttx  to ZZNuttX   Description: <your plans for the fork>
bitbucket.org/nuttx/apps             ZZnuttapps Description: <your plans for an apps>

Next article:  how to download the code to your local machine.

Monday, April 11, 2016

Previous posts superseded

The previous posts on multiple repositories for Nuttx have superseded, as three core repos have been made one.
For a nuttx apps writer it is now effectively two repositories
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/11665

I'll provide updates as I redo my repositories

Monday, March 28, 2016

branched development merge for Nuttx 15.7

With a recent update of Nuttx 15.7
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/11496
https://sourceforge.net/projects/nuttx/files/nuttx/nuttx-7.15/

I needed to merge the udpates into my bitbucket.org fork.
https://bitbucket.org/nuttx/ - previously I had forked from here, and now need to merge those updates into it.
Nuttx has 4 repositories - that all need to be individually updated.
There may be a script to do this - but right now bitbucket offers a button to sync the fork with the upstream. Its positioned on the far right and only exists if this fork is behind.



For _nuttx fork


Press the sync now - then repeat with  forks  _configs (upstream is called nuttx/boards)


_arch

 and apps.


Now on the build machine - in this case an Ubuntu I step into my development  git directory "git/nwwk2"
and then step through apps  nuttx   nuttx/configs & nuttix/arch to update all the modules.
My development branch is "work-modbus".

A little trick I learn't, that as branching is easy/quick, and to be able to easily manage (not commit if necessary) the master merge,  I create a temporary branch "work-modbus-merge" and do all the work/conflict resolution on that first.
When complete its an easy step to merge "work-modbus-merge" into "work-modbus"
git checkout master
git update   # this brings in the udpate
git checkout work-modbus
git checkout -b work-modbus-merge
git merge master   #this does the actual merging from the master
… review new code - in this case no conflicts
git checkout work-modbus
git merge work-modbus-merge
git branch -d work-modbus-merge  #deletes the -merge branch
git merge master  #should be no items
git status  #should say uptodate
git commit -m "merged with Nuttx 7.15 "
git push origin work-modbus    # final upstream update to my 

Then this step is repeated for nuttx, _configs, _arch

Enjoy the merge - when it works its very easy.!!!



Sunday, March 27, 2016

tutorial: Branched workflow setup

This is a series of blogs (my self documentation) on using Nuttx in a branched workflow.
Hopefully its of some use to others.
This starts from the beginning and works through the commands to a built image

Nuttx.org  has a git submodule configuration that adds a layer of complexity to manage the submodules in  a branched workflow environment.
My development environment is Ubuntu 15.10, with Meld to do differencing. 
Meld required Ubunutu 15.10
The editing is done in Eclipse Mars on Windows8 over the network to Ubuntu. I login in remotely to the Ubuntu machine to compile.

Some references

To start sign into bitbucket.org , then clone the following into your <userSpace> on bitbucket
I use a prefix ZZ as you might want to experiment with different instances of Nuttx as the development progress
bitbucket.org/patacongo/nuttx  to ZZ_NuttX   Description: <your plans for the fork>
bitbucket.org/nuttx/apps             ZZ_nuttapps Description: <your plans for an apps>
bitbucket.org/nuttx/arch              ZZ_nuttx-arch Description: Required as part of nuttx
bitbucket.org/nuttx/boards         ZZ_nuttx-config “Nuttx boards definitions”


Then on local machine (mine Ubuntu15.10)
(either setup SSH or use the https form instead of git@bitbucket.org:.... )

cd git
mkdir nxYY    #my top level dir - YY userdefined eg nxwkA
cd nxYY

git clone git@bitbucket.org:<user>/ZZ_nuttapps.git  apps
git clone git@bitbucket.org:<user>/ZZ_nuttx.git nuttx
cd  nuttx
git remote –v (origin should be above)

#
#first time through 
echo "/configs/*" >> .gitignore
echo "/arch/*" >> .gitignore

git add  .gitignore
git commit -m "changed submodule arch configs to directory"
git push origin master   OR if fails or first time on branch   $git push origin <branch-name>

rm -rf arch
rm -rf configs

git clone git@bitbucket.org:<user>/ZZ_nuttx-configs.git  configs
git clone git@bitbucket.org:<user>/ZZ_nuttx-arch.git  arch
git status #shows arch and configs but git ignores any action on them 

#
#optionally should be able to do the following for submodules Documentation 
#- but doesn't work, some hidden submodule meta data still lying around
git submodule init 
#(has error "no submodule mapping found in .gitmodules for path 'arch'"??)
git submodule update  #populates

make distclean
cd  tools
#one of following
$ ./configure.sh stm32f429i-disco/nsh
$ ./configure.sh olimex-stm32-h407/nsh


cd ..
make menuconfig #Step into "Build Setup: ensure host is correct, save, exit to use latest format
#optionally, specify version info
tools/version.sh -v <major.minor> 

make #test build, should work and be tested before continuing

# Do the following for changes to any one of four "projects"
# nuttx   nuttx/arch nuttx/config apps
#eg for nuttx/arch (repeat for other projects as needed)

cd apps
git branch develop  #baseline for future: only first time through

git checkout -b work-<descriptive name>  #new branch eg work-modbusm
git status
<<make changes, build and test>>
git status eg
git add .
git commit -m "sensible comment"
git push origin work-<descriptive name> 

# On Bitbucket.org/<user> check commit is as expected.