Month: January 2016

Flashing bin file to nucleo-L476RG

This command works!!!

/root/Desktop>st-flash –reset write Nucleo_blink_led_NUCLEO_L476RG.bin 0x8000000
2016-01-17T15:53:54 INFO src/stlink-common.c: Loading device parameters….
2016-01-17T15:53:54 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2016-01-17T15:53:54 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2016-01-17T15:53:54 INFO src/stlink-common.c: Attempting to write 16544 (0x40a0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004000 erased
2016-01-17T15:53:54 INFO src/stlink-common.c: Finished erasing 9 pages of 2048 (0x800) bytes
2016-01-17T15:53:54 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-01-17T15:53:54 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 16544
2016-01-17T15:53:55 INFO src/stlink-common.c: Starting verification of write complete
2016-01-17T15:53:55 INFO src/stlink-common.c: Flash written and verified! jolly good!

read count : 7

Nucleo STM32F103 dev board with built in STlinkV2-1 programmer


1. GNU ARM Tool Chain
2. IDE Eclipse
3. STmicro libraries
4. GDB Serve

1. GNU ARM Tool Chain
$ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
(if using 14.04 follow extras steps when adding PPA)
$ sudo apt-get update
$ sudo apt-get install gcc-arm-none-eabi
if 64bit, we need 32-bit libs
$ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0

2. Eclipse IDE & ARM plugin 
Verify Java version is 1.7 or newer
$ java -version
Choose IDE for C/C++ for 32 / 64 bit
Extract and run $ ./eclipse
Add c++ dev tools
Help → Install New Software > releases
Select ‘Luna’ eclipse release
Group by category > programming languages > C/C++ dev tools
Add ARM plugin
Help → Install New Software > releases

3. STmicro libraries 
template makefile compile environment:
git clone git://

4. GDB Server
GDB Server – debugging – ST link is not native compatible with Linux however, it’s been reverse engineered:
git clone git://
$ sudo apt-get install libusb-1.0
$ sudo apt-get install autoreconf
$ cd stlink
$ ./
$ ./configure
$ make
$ sudo cp 49-stlinkv2-1.rules /etc/udev/rules.d
$ sudo udevadm control –reload-rules
$ sudo udevadm trigger
$ sudo ./st-util

GUI – QSTLink2
$ sudo add-apt-repository ppa:fpoussin/ppa
$ sudo apt-get install qstlink2
To flash code to the board…

Binary Flash 
./st-flash write blinky.bin 0x8000000

ELF Executable Linkable Format
1. Start ST-link server on port 4242
$ ./st-util #check ST link is connected ok
$ ./st-util 4242 /dev/stlink
2. Start GDB and connect to ST-link server on port 4242
start an instance of arm-noneeabi-gdb
in a separate window and execute the following
$ arm-none-eabi-gdb BlinkingLights.elf
$(gdb) target extended-remote :4242
$(gdb) load
$(gdb) continue

Serial Output 
Nucleo board serial output can be viewed by opening serial port /dev/ttyACM0

Getting started wtih Eclipse
1. Select new C++ project for STMF10x project
2. Check through default options
3. select blinky example
4. in BlinkLed.h change port number to be ‘0’ for A and pin number to be 5 (on the necleo board the LED is on A5)
5. Click build
6. .elf file is now in the debug folder

read count : 7

I use this script to check all projects for outdated maven dependency

I use this script to check all projects for outdated maven dependency


find . -name "pom.xml" -maxdepth 2| while read a; do
	echo $a;
	#version=`cat $a | grep version|head -1|sed 's/<[^>]*>//' |sed 's/<\/[^>]*>//'`
	#groupId=`cat $a | grep groupId| head -1|sed 's/<[^>]*>//' |sed 's/<\/[^>]*>//'`
	cd `dirname $a`; mvn versions:display-dependency-updates;
	cd ..

read count : 1

My kernel crashed after changed from c to c++

My kernel crashed after changed from c to c++, for this bug, a variable value accidentally changed its value, i was not about to know which code changed it. In previous version of GKD, i can turn on the profiling feature to see which memory address has been accessed, but this is not enough because my bochs instrumentation stub haven’t record down which code(memory address) is accessed that memory address. So i enhanced GKD to display the “accessed-by” memory address, i quickly found out what code(s) accessed the crashed memory address.

gkd accessed by

After checking the kernal memory map produced by gcc, i found out my kernel is getting too large and goes beyong my defined area, so two memory areas are overlapping together. C++ is just too large if comparing to C, but i still want to make a pure object-oriented kernel. Lots of OS are using c to build, i think that is too old fashion. Its the time to use more modern language to build a kernel.

kernel eat beyong the limit

As i said, dwarf is really not a good format, it is hard to be interpret, it is also hard to emit dwarf by compiler, because easy to get wrong. objdump just dump the wrong line of c/c++ code, see below:

wrong source code decode

read count : 20

Buddhism & Coding

I think the starting point to match buddhism and coding is that: prove any logic is combine from more than one logic, so no logic can be independently exist.

read count : 7

Running peter-dwarf tutorial

This is the tutorial for running testing program for peter-dwarf, there are two programs inside the jar, first one is a command-line program to test peter-dwarf functions, the second one is a program with GUI.
1) Running the command line program

java -jar peter-dwarf-20160101.jar /Users/peter/NetBeansProjects/PeterI/kernel/kernel findFunction 0x1600300

This will print out the function name contain the address 0x1600300 in file “kernel”

java -jar peter-dwarf-20160101.jar /Users/peter/NetBeansProjects/PeterI/kernel/kernel findParameter 0x1600300

This will print out all parameter name and type of the address 0x1600300 in file “kernel”

2) Running the GUI program

java -cp peter-dwarf-20160101.jar com.peterdwarf.TestPeterDwarfJFrame

After the program is start, click “Open elf” button to open any 32 bits elf file. The dwarf informations will be display as a tree.

read count : 11

dwarf is too much for c++

One side effect about changing the kernel from c to c++ is that: in the kernel file, the number of dwarf information will increase dramatically from 1,000 to 1,550,000. This let the peter-dwarf parser work slowing to build a tree to display it (But the dwarf parsing still fast). I added the parameter in PeterDwarfPanel constructor to disable to display too much abbrev list in every compilation unit. This make GKD about to start in 5 seconds, before doing this, it take me 25 seconds to popup the GKD main screen.

dwarf too much for c++

read count : 37