Iwasz

UNI-T UT181A problems with charging and poor battery life. Proposed fix.

2022-03-25T00:00:00+01:00

TL;DR : Device couldn’t be charged to full. I replaced the voltage divider responsible for battery sensing. However more investigation, and everyday use is needed to fully evaluate this fix.

Symptoms

Near the end of the charging cycle, the power button flashes in red/green erratically. Screen shows 95% and 100% interchangeably.
After disconnecting the wall wart and switching to voltage measurement it shows only ~75%, even after 24h charging.
Single charge gives only about 10h of operation.
After a ~month on the shelf it does not turn back on (it somehow discharges even though turned off).

The lowest voltage my multimeter was able to work on was 7.55V which in my opinion is way to high. Below that it shuts down. I assumed that the critically low value should be around 3.3V * 2 = 6.6V (or even lower):

At the other hand, after full charge the battery shows 8V. I’m not sure what to think about it. If I were designing this, I would charge to 8.4V, but I haven’t seen the battery’s specs, so maybe it’s desirable. Then I discharged the battery using an active load, and it seems to be in great condition. If not the charger nor the battery, then the voltage measurement done by the MCU has to be wrong. After poking the PCB I’ve found the divider:

At 8V the original divider gave (measured) 2.16V (while it should output 2.253). So I replaced the resistors as so:

	R63	R64	out @ 8V in (theoretical)	out @ 8V in (measured)
original	392k	1M	2.253	2.16
replacement	35k7	82k5	2.362	?

Values were chosen mostly because I had those on hand (1%). It fixed the problem, but more investigation, and everyday use is needed to fully evaluate this fix.

Thoughts

Voltage sensing during charing and during normal operation is realized differently.

Samsung A70 not charging. Easy fix.

2021-11-11T00:00:00+01:00

I’m a total newbie when comes to cellphone repair, but the fix presented here worked like a charm and is relatively easy if you know how to solder. I’ve came across the solution on the iRepair channel on YT and below I post some photos from a microscope with a super brief explanation which the video lacks. First disassemble the phone and take a look at the “reference” image below.

The part that has failed in my case was the wide flat cable connecting the main board (PCB on the left) with the connector board visible on the right. Probably replacing the cable itself would work, but only if the sockets the cable is attached to are OK and we do not know that. In particular the line that fails is the positive voltage one, which (if I’m not mistaken) is directly connected to the USB-C socket VBUS pins. The Vdd connection is realized through the wide pin on the side of the FFC socket. Depicted below is how it looks on the main board side:

Scrape off the solder mask and solder a jumper wire:

Then do the same on the “connector board” (the one with the USB-C on it). I didn’t make better photos, to try to find the spot basing on the shape of the PCB and its traces. “connector board” prepared for soldering:

And here the same shot taken after soldering the wire:

And that’s it! Reconnect the FFC:

And voila! It works:

I’m definitely buying a new phone soon as this one caused so much trouble, but fixing it was fun nonetheless :D

Out Of Tree Zephyr RTOS module (driver)

2021-06-18T00:00:00+02:00

Sometimes it’s inconvenient to develop a driver for some peripheral or sensor in-tree. As far as I was able to research (bare with me, I’m relatively new to Zephyr), the Zephyr RTOS modules are the way to go in such situations. First, a bunch of links that pointed me in the right direction:

A thread stating that “it should not pose a problem, Nordic is doing just that”
The nRF Connect SDK: sdk-nrf the above link is referring to.
Stack overflow thread where a guy replied to himself. Even though this link covers the topic pretty much, I still stumbled upon some problems. See below.
Another out of tree approach but overall, this thread is inconclusive.
ZEPHYR_EXTRA_MODULES is mentioned here.
My module this post is about.
Acompanying test application to try things out.

My test module contains a driver for LSM6DS3 accelermoeter and gyroscope. This is an older version of LSM6DSL that is already supported by Zephyr, which makes my implementation as easy as changing one macro.

The current version of Zephyr as of today is 2.6.

The module

Explains what has been copied and what modified. Create the directory structure:

+drivers
  +sensor

+dts
  +bindings
    +sensor

+zephyr
CMakeLists.txt
Kconfig
README.md

Copy zephyr/drivers/sensor/lsm6dsl from the main Zephyr repo to drivers/sensor/lsm6ds3 in our directory.

Names

Change all the function, macro and file names from lsm6dsl to lsm6ds3. Remember about Kconfig and CMakeLists.txt

Change the macro LSM6DSL_VAL_WHO_AM_I from 0x6A to 0x69. This is the only “true” modification in the code.

Build system

Update / provide build system information. A module has to have a Kconfig and CMakeLists.txt in its root directory, so provide one. In my module, these files are as simple as:

Kconfig:

menu "My super zephyr module"

rsource "drivers/Kconfig"

endmenu

CMakeLists.txt:

add_subdirectory(drivers)

In the above files I point to the drivers directory, so there have to be Kconfig and CMakeLists.txt there as well:

drivers directory contains:

CMakeLists.txt : add_subdirectory_ifdef(CONFIG_SENSOR sensor)

Kconfig rsource "sensor/Kconfig"

sensor directory contains:

CMakeLists.txt : add_subdirectory_ifdef(CONFIG_LSM6DS3 lsm6ds3)

Kconfig : rsource "lsm6ds3/Kconfig"

You see the pattern.

Bindings

Copy st,lsm6dsl-i2c.yaml and st,lsm6dsl-spi.yaml bindings from Zephyr repo to our dts/bindings/sensor, and change the file names accordingly (don’t forget about the contents). Binding files are found automatically during the build.

module.yml

Lastly, provide the module description adding the zephyr/module.yml :

build:
  cmake: .
  kconfig: Kconfig
  settings:
    dts_root: .

Problems I’ve had

Zephyr build system isn’t very verbose (nor precise) when problems occur, so if you ever encounter errors like this:

cmake -B build -G Ninja -DBOARD=nucleo_h743zi -DBOARD_ROOT=. -DZEPHYR_EXTRA_MODULES=/home/iwasz/workspace/zephyr-modbus/my-zephyr-module .
Including boilerplate (Zephyr base): /home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /home/iwasz/workspace/zephyr-modbus/zephyr-inclinometer
-- Zephyr version: 2.6.0-rc3 (/home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr), build: v2.6.0-rc3
-- Found Python3: /usr/bin/python3.9 (found suitable exact version "3.9.4") found components: Interpreter 
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
CMake Error at /home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr/cmake/zephyr_module.cmake:61 (message):
  /home/iwasz/workspace/zephyr-modbus/my-zephyr-module, given in
  ZEPHYR_EXTRA_MODULES, is not a valid zephyr module

Call Stack (most recent call first):
  /home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr/cmake/app/boilerplate.cmake:183 (include)
  /home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/iwasz/workspace/zephyr-modbus/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!

It could mean that the module.yml is named incorrectly. In my case, I used yaml extension instead of yml.

After correcting the problem with module.yml, the app started and the analyzer showed that it does something on the I²C, but then it failed in drivers/sensor/lsm6ds3/lsm6ds3_trigger.c in the lsm6ds3_trigger_set function. The problematic code was:

if (!drv_data->gpio) {
        LOG_ERR ("triggers not supported");
        return -ENOTSUP;
}

Clearly, a problem with my overlay, but why? It seems the Zephyr build system did not see my binding files. As stated here the module.yml has to point at the binding files. The solution is to add:

settings:
    dts_root: .

The test application

Is here. The application is straightforward. I copied zephyr/samples/sensor/lsm6dsl. I added my custom overlay in the boards directory to configure what is connected and to which pins:

&i2c2 {
        pinctrl-0 = <&i2c2_scl_pb10 &i2c2_sda_pb11>;
        status = "okay";
        clock-frequency = <I2C_BITRATE_FAST>;

        lsm6ds3@6b {
                compatible = "st,lsm6ds3";
                reg = <0x6b>;
                irq-gpios = <&gpiod 11 GPIO_ACTIVE_HIGH>;
                label = "LSM6DS3";
        };
};

I modified the prj.conf to enable my implementation instead of theirs (again I changed from LSM6DSL to LSM6DS3).

Finally I changed some (but not all) names in the C code from LSM6DSL to LSM6DS3:

device_get_binding (DT_LABEL (DT_INST (0, st_lsm6ds3)))
CONFIG_LSM6DS3_TRIGGER

Build

After these modification I was left with:

The Zephyr itself (usual directory zephyrproject + SDK)
My application in my-zephyr-module-app.
My module in my-zephyr-module

To build this i simply have to :

cd my-zephyr-module-app
cmake -B build -G Ninja -DBOARD=nucleo_h743zi -DBOARD_ROOT=. -DZEPHYR_EXTRA_MODULES=/home/iwasz/workspace/zephyr-modbus/my-zephyr-module .
ninja -C build/
west flash

A follow-up

Sometimes it is convenient to have both the module and the application using it in one place. Thankfully there is an example in the Zephyr showing just that in zephyr/samples/application_development/out_of_tree_driver. Interestingly enough, when I tried to incorporate this example into one of my projects, I got an error during build:

[...]
In declaration of void hello_world_print 
Traceback (most recent call last):
  File "/home/iwasz/workspace/zephyrproject/zephyr/scripts/gen_syscalls.py", line 450, in <module>
    main()
  File "/home/iwasz/workspace/zephyrproject/zephyr/scripts/gen_syscalls.py", line 379, in main
    handler, inv, mrsh, sys_id, entry = analyze_fn(match_group)
  File "/home/iwasz/workspace/zephyrproject/zephyr/scripts/gen_syscalls.py", line 324, in analyze_fn
    func_type, func_name = typename_split(func)
  File "/home/iwasz/workspace/zephyrproject/zephyr/scripts/gen_syscalls.py", line 143, in typename_split
    raise SyscallParseException("Malformed system call invocation")
__main__.SyscallParseException: Malformed system call invocation
[6/178] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h, include/generated/otype-to-size.h
ninja: build stopped: subcommand failed.

The cause was that I modified the hello_world_driver.h, and saved it, which in turn fired the clang-format tool (which uses my system-wide configuration). And this action alone broke the build completely (namely the lack of a space character after the function name and before the opening bracket is causing the problem). The solution is either to surround the problematic bit in /* clang-format on/off */ guards:

/* clang-format off */
__syscall     void        hello_world_print(const struct device *dev);
static inline void z_impl_hello_world_print(const struct device *dev)
/* clang-format on */

Or to use the .clang-format file provided by Zephyr. I went with the second option and copied the mentioned file to the directory where my modules are. This way I can use my system-wide (and preferred) formatting for the user-space C++ code, and make the Zephyr build system happy at the same time.

TODO

Make vscode happy. The IDE is overwhelmed by the project split into 3 separate directories or I don’t know how to configure it. Let me know in the comments you whereabouts on this. Also I do not know (an I’ve tried) how to have the module included inside the application directory.

STM32F042 option bytes under Linux

2020-07-29T00:00:00+02:00

These are instructions that worked for me when faced with a problem of modifying option bytes in stm32f042. The thing I was trying to do was to turn off BOOT0 pin support (PB8 in my chip) which then would eliminate the need to pull it. Then I could use this pin for something else, for example as a CANbus canRx input.

A bunch of useful links:

Stack overflow question which put me on the right track.
Openocd manual
Reference manual of whatever chip you are using. The chapters of interest are entitled:
- 3.2.2 Flash program and erase operation
  - Unlocking the Flash memory
  - Option byte programming
- 4 Option byte
- A.2.5 Option byte unlocking sequence code example
- A.2.6 Option byte programming sequence code example
- A.2.7 Option byte erasing sequence code example

TL;DR

openocd -f /home/iwasz/local/share/openocd/scripts/interface/stlink.cfg -f /home/iwasz/local/share/openocd/scripts/target/stm32f0x.cfg -c 'init; mww 0x40022004 0x45670123; mww 0x40022004 0xCDEF89AB; mww 0x40022008 0x45670123; mww 0x40022008 0xCDEF89AB; mww 0x40022010 0x00000220; mww 0x40022010 0x00000260; mww 0x40022010 0x00000210; mwh 0x1ffff800 0x55AA; mwh 0x1ffff802 0x807f; mdw 0x1ffff800'

Preparation

Turn the power on. Run the openocd (mind the paths):

openocd -f /home/iwasz/local/share/openocd/scripts/interface/stlink.cfg -f /home/iwasz/local/share/openocd/scripts/target/stm32f0x.cfg 

Connect to the running openocd to get access to the interactive shell:

telnet localhost 4444

Verify that the FLASH_CR.LOCK is set, meaning that the entire flash is locked. Flash base address is : 0x40022000 which tells that FLASH_OPTKEYR address is 0x40022008 and FLASH_CR address is 0x40022010. Read FLASH_CR as so (00000080 means the LOCK flag is set):

mdw 0x40022010
0x40022010: 00000080 

Unlock the flash and option bytes

Unlock the flash directly performing the unlocking sequence on the FLASH_KEYR (0x40022004) register. The procedure is described in the Reference Manual in the chapter Flash program and erase operation, and also in the examples section as a source code snippet. You simply write two values to the same FLASH_KEYR register:

mww 0x40022004 0x45670123
mww 0x40022004 0xCDEF89AB

Reassure that the flash is unlocked. Read the FLASH_CR:

mdw 0x40022010
0x40022010: 00000000 

This means that flash is unlocked, and LOCK is 0 (and all other flags are 0 as well).

Unlock option bytes for writing (which is described in the reference manual as setting the OPTWRE bit in the FLASH_CR). The sequence is basically the same as in the previous step, with the only difference that this time we write the magic unlocking values to FLASH_OPTKEYR (0x40022008):

mww 0x40022008 0x45670123
mww 0x40022008 0xCDEF89AB
mdw 0x40022010           
0x40022010: 00000200 

Now instead 00000000 we see 00000200 which means that OPTWRE flag is set.

Clear the option bytes

Clear option bytes (they are stored in the FLASH after all). This is done by first setting FLASH_CR.OPTER (erase), and then FLASH_CR.STRT (start operation). Note that FLASH_CR.OPTWRE must be still set:

mww 0x40022010 0x00000220
mww 0x40022010 0x00000260

All (?) option bytes should now read 0xffffffff.

Modify the option byte

Enable programming by setting FLASH_CR.OPTPG:

mww 0x40022010 0x00000210
mdw 0x40022010
0x40022010: 00000210

Store a value (only half-words). In this example, I am modifying the User and read protection option byte (0x1FFFF800). In particular, I’m setting the BOOT_SEL flag.

What is described as a User and read protection option byte is in fact a 32bit word containing the user option byte [23:16] (and its “complement”), and the RDP option byte [7:0] (and its “complement”).

So wanting to change the BOOT_SEL we calculate, that the proper value of the user option byte [23:16] is 0x7f, and thus its “complement” byte (a negation) should be 0x80.

Also, I wanted to restore the RDP to its factory value, because it got lost for some reason.

# Set read protection option byte to 0xaa which denotes level 0 (the default) 
mwh 0x1ffff800 0x55AA
# Set BOOT_SEL to 1 to ignore BOOT0 pin. 
mwh 0x1ffff802 0x807f
# Verify
mdw 0x1ffff800

STM32 on Ubuntu Linux step by step

2018-11-06T00:00:00+01:00

This is a step by step tutorial on using STM32 (stm32f407vg to be precise) under Linux (Ubuntu 18.10) and other tools (QtCreator and CMake) that I use in my everyday work. In this article we will compile simple LED blinking program and run it on the STM32F4-DISCOVERY. There may be easier ways of accomplishing this though. Paragraph titles ending with an asterisk are optional.

First we will try to prepare a project which compiles simply in a terminal using make or ninja. This is very important for me because nowadays every µC vendor seems to provide its own shitty IDE, and their examples tend to compile only under those IDEs in nonstandard ways. This forces you to install and use stuff that you (or is it only me?) don’t like, not to mention that most of those tools run only under Windows. Then I’ll show you my favorite IDE which happens to be QtCreator, but any other IDE which can cope with CMake build system should do.

Source code for this article is here : https://github.com/iwasz/blinky01

Note : do not confuse [Stm32]CubeMX (a desktop configuration tool) and [Stm32]CubeF4 which is a SDK package.

Note to myself : virtualBox creates way too small disk images by default. I went with 10GB which proved to be too small after only 1 hour of tweaking. Resizing the VB disk is done via vboxmanage, reviving dead distro is done as usual by using LiveCD, and then you delete the partition using fdisk, create new in the place of the old with all options set to defaults, and then you use resize2fs.

Note to myself 2 : install virtual box guest extensions in the guest system for seamless clipboard operation. Install virtualbox-ext-pack in the host system for USB 2.0 forwarding, add yourself to the vboxusers group, read this.

Installing the tools

Stm32CubeMX

Install Ubuntu 18.10. I used VirtualBox running on Ubuntu 18.04 for this.

Make sure everything is up to date. Run apt update + upgrade, or use GUI Ubuntu provides.

We are going to use an excellent program ST provides called STM32CubeMX which lets us configure pins, clock sources and more. But above all it can generate some startup and config code which we’ll take as a base for our LED blinking application. So lets download it and remember to install Java first. I usually install Oracle’s Java JDK, but JRE of course will do as well (in this case it was jdk-11.0.1_linux-x64_bin.deb). I have no experience with other Java implementations like OpenJDK but I suspect, that it also will work as expected.

After jdk was installed I added java to the PATH in ~/.profile : PATH="/usr/lib/jvm/jdk-11.0.1/bin:$PATH"

Download Stm32CubeMX and unpack it (login required unfortunately). Run ./SetupSTM32CubeMX-4.27.0.linux . In my case (fresh Ubuntu) it said :

./SetupSTM32CubeMX-4.27.0.linux 
bash: ./SetupSTM32CubeMX-4.27.0.linux: No such file or directory

It is a very non-intuitive message, but it is because of 32 bit libraries missing. This post tells us what to do, and to my surprise it discourages from installing ia32-libs which I would normally do:

file SetupSTM32CubeMX-4.27.0.linux
SetupSTM32CubeMX-4.27.0.linux: ELF 32-bit LSB executable, Intel 80386, ......
sudo dpkg --add-architecture i386
sudo apt update
sudo apt-get install libc6:i386 libstdc++6:i386

Run the installer and verify, that CubeMX works.

QtCreator*

Everyone has his/her favorite IDE, but mine is QtCreator for various reasons which I’m not going to dive into, but Qt libraries are not one of them. I do not use Qt, I simply tried many IDE’s and QtCreator suits me the best. First let’s grab an installer.

https://download.qt.io/official_releases/qtcreator/ - those are the official releases.
https://download.qt.io/snapshots/qtcreator/ - and here are nightly builds. For this article I picked qt-creator-opensource-linux-x86_64-4.7.2.run and run it in the terminal and that’s it (login required).

Toolchain

The toolchain can be easily installed from Launchpad PPA, or can be compiled using excellent tool called crosstool-ng. Detailed instructions are in one of my previous posts. But for now lets use the easier way:

sudo add-apt-repository ppa:team-
gcc-arm-
embedded/
ppa
sudo apt-get update
sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib
sudo apt install cmake ninja

Other tools

sudo apt install mc openocd dos2unix gdb-multiarch

The project

Run Stm32CubeMX and start a new project. In the “Part Number Search” in the top left corner insert “stm32f407vg”. This is the model of a µC we will be using and which is mounted in the STM32F4-DISCOVERY, a popular evaluation board (you can get it from all major distributors, though findchips.com shows, that availability is not at its best right now).

Click on the blue link-like label in the search result table and start the project. The next thing you’ll see is a view of your microcontroller with all the peripherals and GPIOs initialized according to the board’s specs. This is because the board itself contains some neat stuff like accelerometer, digital to analog audio chip with amplifier, and so on. We are focused on PD12 - PD15 which are connected directly to LEDs.

Turn off USB support. It uses some additional files which makes compilation a little bit harder. Make sure that USB_OTG_FS Mode is set to “Disable” in the left pane. Also on the “Configuration” tab make sure, that USB middleware is not used.

Turn off other unnecessary peripherals like SPI, I2C, USARTs. The more the peripherals, the more source files from SDK we will have to compile, so in my project only SYS, RCC and of course GPIOs are configured. Please check my blinky.ioc in case of trouble or simply experiment with CubeMx’s output.

Then use “project -> Generate Code” in the main menu to generate the code. When asked about downloading the SDK called StmCubeF4 click YES, and appropriate SDK will be placed in the ~/STM32Cube/Repository. This is important as our code will depend on it (although the SDK can be separately downloaded from here). Here’s what the generated directory structure looks like on my computer:

./EWARM : 
some stuff for some proprietary IDE i guess.
./blinky.ioc : 
CubeMX project file.
./Middlewares
./Middlewares/ST : 
USB library which won't be of interest for us since we only want to blink LEDs.

./Drivers : 
Parts of the CubeF4 gets copied here. 
./Drivers/STM32F4xx_HAL_Driver : 
Peripheral library.
./Drivers/CMSIS : 
CMSIS Library is a low level code for interfacing with the CPU.

./Inc 
./Inc/stm32f4xx_it.h : IRQ handlers declarations used by our app. Not particularly useful.
./Inc/stm32f4xx_hal_conf.h : 
low level peripheral configuration based on CubeMX options.
./Inc/main.h : 
another unnecessary file.
./Src
./Src/system_stm32f4xx.c : 
Low level init routines run from the startup code before main.
./Src/stm32f4xx_it.c : 
IRQ handler definitions.
./Src/stm32f4xx_hal_msp.c : 
hi level peripheral configuration based on CubeMX options (GPIOs etc).
./Src/main.c

So as you can see pretty verbose output gets produced from CubeMX, but we are interested only in the *.h and *.c files. My favorite directory structure at the other hand looks like this one below (for completeness sake, the directory resides in ~/workspace/blinky but of course dir names are up to you). Create it, and copy generated sources into src directory as so:

./build : 
Compiled files goes here. Never commit this dir as it's contents are generated.
./stm32f407xx.cmake : 
The toolchain file, more on it later.
./src : 
Sources generated by the CubeMX. *.h and *.c together, but it's up to you.
./src/stm32f4xx_it.h
./src/system_stm32f4xx.c
./src/stm32f4xx_hal_conf.h
./src/stm32f4xx_it.c
./src/stm32f4xx_hal_msp.c
./src/main.h
./src/main.c
./CMakeLists.txt : 
The CMake file.

One can argue whether STM32F4xx_HAL_Driver and CMSIS should be inside our project tree or not. I prefer having all parts of SDK in some external directories simply because copying them into dozens of projects would be a waste and a pollution of the source tree. At the other hand though packaging all the necessary code into our project makes it self contained and easier to compile (no external deps. your choice). For this article I assume that SDK resides in the ~/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0 (the default for CubeMX). So now you have two files missing : stm32f407xx.cmake and CMakeLists.txt. The latter looks like this:

# This variable is used later to set a C/C++ macro which tells CubeF4 which µC to use. ST
# drivers, and other code is bloated with all sorts of macros, #defines and #ifdefs.
SET (DEVICE "STM32F407xx")

# This is a variable which is later used here and in the CMakeLists.txt. It simply tells
# where to find the SDK (CubeF4). Please change it accordingly if you have other 
# version of CubeF4 installed.
SET (CUBE_ROOT "$ENV{HOME}/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0")

# Startup code and linker script - more on it later.
SET (STARTUP_CODE "${CUBE_ROOT}/Projects/STM32F4-Discovery/Templates/SW4STM32/startup_stm32f407xx.s")
SET (LINKER_SCRIPT "${CUBE_ROOT}/Projects/STM32F4-Discovery/Templates/SW4STM32/STM32F4-Discovery/STM32F407VGTx_FLASH.ld")

# Magic settings. Without it CMake tries to run test programs on the host platform, which
# fails of course.
SET (CMAKE_SYSTEM_NAME Generic)
SET (CMAKE_SYSTEM_PROCESSOR arm)

# -mcpu tells which CPU to target obviously. -fdata-sections -ffunction-sections Tells GCC to.
# get rid of unused code in the output binary. -Wall produces verbose warnings.
SET(CMAKE_C_FLAGS "-mcpu=cortex-m4 -std=gnu99 -fdata-sections -ffunction-sections -Wall" CACHE INTERNAL "c compiler flags")

# Flags for g++ are used only when compliing C++ sources (*.cc, *.cpp etc). -std=c++17 Turns
# on all the C++17 goodies, -fno-rtti -fno-exceptions turns off rtti and exceptions.
SET(CMAKE_CXX_FLAGS "-mcpu=cortex-m4 -std=c++17 -fno-rtti -fno-exceptions -Wall -fdata-sections -ffunction-sections -MD -Wall" CACHE INTERNAL "cxx compiler flags")

# Those flags gets passed into the linker which is run by the GCC at he end of the process..
# -T tells the linker which LD script to use, -specs=nosys.specs sets the specs which most 
# notably tells the compiler to use libnosys.a which contains all the syscalls like _sbrk,
# _exit and much more. They are more like an interface between our program and operating system /
# bare metal system we are running it on. You can use rdimon.specs instead or write syscalls 
# yourself which for bare-metal isn't difficult. --gc-sections strips out unused code from 
#binaries I think.
SET (CMAKE_EXE_LINKER_FLAGS "-T ${LINKER_SCRIPT} -specs=nosys.specs -Wl,--gc-sections" CACHE INTERNAL "exe link flags")

# Some directories in the GCC tree.
INCLUDE_DIRECTORIES(${SUPPORT_FILES})
LINK_DIRECTORIES(${SUPPORT_FILES})

# Macro I wrote about in the first line.
ADD_DEFINITIONS(-D${DEVICE})

# Random include paths for CubeF4 peripheral drivers and CMSIS.
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/")
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/CMSIS/Device/ST/STM32F4xx/Include/")
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/CMSIS/Include/")

Few more words on the linker script (LD script) and the startup code. I won’t dive into detail to much, but LD script tells the linker how to assemble the final executable from all the object files that were compiled by a compiler. Basically for every .c or *cc file one object (.o or *.obj) file gets created (you can find them later inside build/CMakeFiles dir), and every of them is full of symbols stored in the “input” sections. LD script tells the linker what input symbols from which input sections should be copied into the “output” sections in the final executable (and much more; LD scripts are powerful).

Cortex-M4 CPU after powering up looks at memory address 0 which tells it where the stack starts. Then at the address 0x0000’0004 it checks where the reset IRQ routine is and runs it. Reset IRQ is the first of the many IRQ handlers which addresses reside in the IRQ vector defined in the startup (assembly file). Reset IRQ is called Reset_Handler in ST’s assembly startup code and does a few simple things:

Copies the .data section from flash to RAM. .data section contains global initialized variables.
Clears the .bss RAM section which contains uninitialized static variables.
Calls SystemInit which I mentioned previously (basic stuff like external memory controller maybe?)
Calls __libc_init_array which among other things that I’m unaware of calls C++ constructors.
Calls the main function.

Writing startup code and LD script is not trivial (although startup code can be written in C), so thankfully ST provided us with their own implementations which we can use. There is an excellent article on the subject for those who are interested. Go to the ~/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0 and issue a find :

find ~/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0/ -name startup_stm32f407xx.s /home/iwasz/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0/Projects/STM32F4-Discovery/Templates/SW4STM32/startup_stm32f407xx.s

There’s a lots of hits because the CubeF4 SDK is made so it can be used with all of STM evaluation boards which there are tons of. This file which we found though, seems to be prepared for our board (Stm32F4-DISCOVERY or sometimes Stm32F4-DISCO for short). Secondly, they provide projects for 3 or 4 major (in their opinion) IDEs. Files prepared for TrueStudio and SW4STM32 are the way to go as those are GCC based apparently (never used them).

For finding the LD script issue:

find ~/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0/ -name STM32F407*.ld /home/iwasz/STM32Cube/Repository/STM32Cube_FW_F4_V1.21.0/Projects/STM32F4-Discovery/Templates/SW4STM32/STM32F4-Discovery/STM32F407VGTx_FLASH.ld

Modify stm32f407xx.cmake according to your findings (STARTUP_CODE and LINKER_SCRIPT variables) though if you followed my instructions directly, you should be fine without modifications.

Next the CMakeLists.txt file. This is like Makefile but on the higher level of abstraction. Mine looks like this:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

PROJECT (blinky)

# Startup code is written by ST in assembly, so without this statement there are errors.
ENABLE_LANGUAGE (ASM-ATT)

INCLUDE_DIRECTORIES("src/")

# Resonator used in this project. Stm32F4-DISCO uses 8MHz crystal. I left this definition here
# in the CMakeLists.txt rather than the toolchain file, because it's project dependent, not
# "platform" dependent, where by platform I mean STM32F4.
ADD_DEFINITIONS (-DHSE_VALUE=8000000)

# All the sources goes here. Adding headers isn't obligatory, but since QtCreator treats CMakeLists.txt as
# its "project configuration" it simply makes header files appear in the source tree pane.
ADD_EXECUTABLE(${CMAKE_PROJECT_NAME}.elf
 "src/main.c"
 "src/main.h"
 "src/stm32f4xx_hal_conf.h"
 "src/stm32f4xx_hal_msp.c"
 "src/stm32f4xx_it.c"
 "src/stm32f4xx_it.h"
 "src/system_stm32f4xx"
)

# Workaround : splitting C and C++ code helps QtCreator parse header files correctly. Without it, QtCreator
# sometimes treats C++ as C and vice versa. EDIT : this comment was written when in the ADD_EXECUTABLE C++
# files were present.
add_library ("stm" STATIC
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_cortex.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_gpio.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_rcc.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_gpio.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_rcc.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_utils.c"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_cortex.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_gpio_ex.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_gpio.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_rcc_ex.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_rcc.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_cortex.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_gpio.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_rcc.h"
 "${CUBE_ROOT}/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_system.h"
 "${STARTUP_CODE}"
)

# This links both pieces together.
TARGET_LINK_LIBRARIES (${CMAKE_PROJECT_NAME}.elf -Wl,--whole-archive stm -Wl,--no-whole-archive)

FIND_PROGRAM (OPENOCD openocd)
ADD_CUSTOM_TARGET("upload" DEPENDS ${CMAKE_PROJECT_NAME}.elf COMMAND ${OPENOCD} -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg -c 'program ${CMAKE_PROJECT_NAME}.elf verify reset exit')

OK now that we are set, let`s create a build directory if it doesn’t exist yet, and build our project:

pwd
/home/iwasz/workspace/blinky
mkdir build
cd build
cmake -DCMAKE_CXX_COMPILER=arm-none-eabi-g++ \
    -DCMAKE_C_COMPILER=arm-none-eabi-gcc \
    -DCMAKE_TOOLCHAIN_FILE=../stm32f407xx.cmake -GNinja ..
ninja

If all went well, blinky.elf should appear in the build directory. Ninja isn’t mandatory (but its faster, more modern and jazzy), so if you omit -GNinja part, you will be left with classic Makefile and you would issue make instead of ninja at the end.

Feel free to post a comment in case of any trouble, we will sort it out.

Uploading

I don’t know why but, most of the Internet and books says “downloading” to describe the process of transmitting a binary firmware from host (PC) to the target (µC). I find it very confusing, because when a file is moved from a PC to some remote server, everybody calls it “uploading” not “downloading”.

Let’s modify our generated code, so it actually blinks. Locate the main loop in the main.c file (it will be empty), and place this inside, and recompile (simply issue ninja or make inside the build dir):

HAL_GPIO_WritePin(GPIOD, LD4_Pin|LD3_Pin|LD5_Pin|LD6_Pin, GPIO_PIN_RESET);
HAL_Delay (500);
HAL_GPIO_WritePin(GPIOD, LD4_Pin|LD3_Pin|LD5_Pin|LD6_Pin, GPIO_PIN_SET);
HAL_Delay (500);

In the “other tools” section we installed openocd, so lets use it now. Connect the STM32F4-DISCO, make sure that ST-LINK and JP1 jumpers are closed (the default), and :

cd build
ninja
openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg -c 'program blinky.elf verify reset exit'

If everything went OK, you should see like a two dozens of messages like :

adapter speed: 8000 kHz
** Programming Started **
auto erase enabled
Info : device id = 0x10016413
Info : flash size = 1024kbytes
[...]
** Programming Finished **
** Verify Started **
[...]
verified 7992 bytes in 0.104675s (74.561 KiB/s)

Let me know in case of any problems, we can work it out probably. Remember that I managed to flash the thing under Ubuntu 18.10 running inside Ubuntu 18.04, so it cannot be that difficult :D. Another way of flashing STM32s under Linux is by using Texane’s st-link, but I found openocd to be more reliable and universal.

Oh, and I added an “upload” target in the CMakeLists.txt, so you can simply do “ninja upload” instead of running openocd manually.

The QtCreator IDE*

Now that our project compiles and runs in a console we can integrate it with QtCreator (or other IDE). Run it, and open Help -> About plugins. Make sure, that BareMetal (experimental) plugin is active and restart the IDE when asked.

Now open Tools -> Options from the main menu.

In the Devices section go to Bare Metal tab and Add OpenOCD GDB server provider. Defaults are OK, don’t change anything.

Apply changes and move to the Devices tab. Add new Bare Metal Device, name it accordingly (I named it Stm32F4) and pick OpenOCD GDB Server provider we created in the previous step.

Go to Kits section, Compilers tab, and make sure GCC for ARM 32 got auto-detected. If it weren’t (because you installed some other GCC based toolchain in some non-standard place) add it there using the Add button.

Go to the Debuggers tab and add gdb-multiarch which we installed previously like so (remember to Apply after each modification):

Finally go to the Kits tab and add new. Pick a name (you can even add an icon), change Device type to Bare Metal Device, and pick proper one in the combo below it. In the Compiler combos pick the ones we created / found in the Compilers tab, and do the same with the Debugger combo.

Change CMake Configuration (last row) so it looks like this (those are the options we passed to the CMake using -D flag):

After all this effort you should be left with a new kit looking like that:

Now we can open our project. Delete old build directory to be sure old config doesn’t break anything and open the project by selecting CMakeLists.txt. If you don’t delete our old build directory created by hand in previous paragraphs, new “temporary” kit gets created and it can be used after some modifications, but we already have better one.

You will be presented with Configure Project window where you can pick a kit to be used. Uncheck the Desktop kit, and check our Stm32F4 one:

Click Configure project and hit Ctrl-B to verify that everything compiles.

Debugging in QtCreator*

It’s simple. Open a terminal, and run openocd like so:

openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg

This way GDB remote protocol server is started (not sure about the name), and “normal” GDB can communicate with it. Switch to QtCreator, hit F5 and that’s it! Hit Shift-F5 to pause program, and you will be presented with a call stack, variables, and so On. F10 is for stepping over, F11 for stepping into, and Shift-F11 for stepping out. Happy debugging.

BlueNRG-2-Android. Source code troubleshooting, bonding, and privacy

2018-08-01T00:00:00+02:00

The objective of the firmware presented in this article is to provide an example which would implement the following functionality:

After resetting the BlueNRG-2 (called the “device” or simply BlueNRG later on) it would make itself general discoverable and accept a connection from whatever connects first.
It would bond with this first connecting thing (called the “cellphone” later on) and allow it to connect and modify GATT characteristics exclusively.
No other central device (cellphone) would be allowed to modify device’s characteristics (or even connect).
This BlueNRG device would work with modern iOS and Android phones (it’s 2018 when I’m writing this).

My starting point was an example from STSW-BLUENRG1-DK version 3.0.0 named BLE_Security which resides in BlueNRG-1_2-DK-3.0.0/Project/BLE_Examples/BLE_Security/src/peripheral directory. This package comes as an executable if I remember correctly, but most of the ST’s execs run under wine (wine-3.6 (Ubuntu 3.6-1), Ubuntu version 18.04). So just after incorporating the example source code into my project, I was able to pair, bond, connect and read characteristics on the BlueNRG-2 using nRF connect app running on Android 8 on Huawei Honor 9. The problem arisen though, when I tried to disconnect, and then connect again. In such case, I would always get “GATT ERROR 0x85” in the nRF connect logs, and the only way to connect to the BlueNRG again was to reset it (it clears its security database, removing all bond information) and to remove bond information from the cellphone. After some time I posted a question on my ST forum, but not getting the answer I slowly figured out, that there is a problem with whitelist because when I turned “undirected connectable” without whitelist, everything worked OK. Let me explain. In the file BlueNRG-1_2-DK-3.0.0/Project/BLE_Examples/BLE_Security/src/peripheral/BLE_Security_Peripheral.c there is Make_Connection function which at first turn general discoverable :

ret = aci_gap_set_discoverable (ADV_IND, 0x100, 0x200, PUBLIC_ADDR, filter, sizeof (local_name), local_name, 0, NULL, 0, 0);

with filter ==NO_WHITE_LIST_USE and after bonding it turns undirected connectable like this :

ret = aci_gap_set_undirected_connectable(0x100,0x200,PUBLIC_ADDR, filter);

with filter == WHITE_LIST_FOR_ALL. The way I see this problem is, that modern cellphones use random private resolvable addresses which can change anytime, so it may happen that the address BlueNRG has on its whitelist is out of date. The solution is to turn on the controller privacy (introduced in so-called link-layer privacy 1.2 in BLE 4.2) which would resolve addresses in the link-layer tier thus allowing whitelisting. There are more reliable sources on the topic, but the way I understand it is that [I may be wrong here] on the 3rd stage of bonding peripheral and central exchange IRKs between each other (along with other information) and thus the peer device identity is stored in the BlueNRG. This peer device identity consists of peer’s device identity address (the “real” address which can be public or static random), the local IRK and peer’s IRK. This information is then passed to the controller letting it to resolve random private resolvable addresses from the peer (cellphone) or to “randomize / hide” its own address. [/I may be wrong here]

To turn the controller privacy on I modified aci_gap_init as so:

ret = aci_gap_init (GAP_PERIPHERAL_ROLE, 0x02, sizeof (deviceName), &service_handle, &dev_name_char_handle, &appearance_char_handle);

but it retured error BLE_STATUS_INVALID_PARAMS. The same goes if I wanted to turn “LE secure connections” instead of “legacy pairing” where I got BLE_ERROR_UNSUPPORTED_FEATURE.It turned out that I needed to modify stack_user_cfg.h and turn appropriate options on :

#define CONTROLLER_PRIVACY_ENABLED (1U)
#define SECURE_CONNECTIONS_ENABLED (1U)
#define CONTROLLER_MASTER_ENABLED (0U)
#define CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED (0U)

In addition I added stack_user_cfg.c and libcrypto.a to the source base, and was able to go past the aci_gap_init call. Next I wanted to turn on the “LE secure connections” which where introduced in BLE 4.2. This is some fancy option which modifies the way the bonding process goes and introduces even more security, yay. I did:

ret = aci_gap_set_authentication_requirement (BONDING, MITM_PROTECTION_NOT_REQUIRED, SC_IS_SUPPORTED, KEYPRESS_IS_NOT_SUPPORTED, 7, 16, USE_FIXED_PIN_FOR_PAIRING, 123456, STATIC_RANDOM_ADDR);`

and got BLE_STATUS_OUT_OF_MEMORY (0x48) when adding first (and only) custom GATT service. Turns out, that when SC is supported, there is another characteristic added to the Genaral Access service called Central Address Resolution characteristic. So I needed to fire the BLUENRG1_Wizard.exe and generate new header file with “privacy - controller” option turned on. This way ATT attributes number was increased by 1 and the out of memory error went away.

Next problem was that aci_gap_set_discoverable started to return BLE_STATUS_INVALID_PARAMS (0x42). It turns out, that when host or controller privacy is turned on, Own_Address_Type parameter can be only RESOLVABLE_PRIVATE_ADDR or NON_RESOLVABLE_PRIVATE_ADDR, and conversely when privacy is off, Own_Address_Type can be only PUBLIC_ADDR or STATIC_RANDOM_ADDR. So this way if you want the BlueNRG to resolve private resolvable addresses from the peer, you are also forced to use them on the NRG as well.

This way I was able to run the firmware without any errors, but my cellphone was unable to detect the device 99% of the time. It would occasionally detect it, but on very rare occasions. The problem was solved after… replacing 16MHz High-speed oscillator crystal with 32MHz one. I really do not know where this bug/feature is documented, because I was able to found it only in the Privacy_1_2_Slave_WhiteList.py script of the BlueNRG GUI application. After replacing the crystal, I made a change so HS_SPEED_XTAL macro would preprocess to 1 and SYSCLK_FREQ to 32000000.

And the last problem I had, which took me almost 2 days to fix was caused by (I think) improper capabilities setup:

ret = aci_gap_set_io_capability (IO_CAP_NO_INPUT_NO_OUTPUT);
ret = aci_gap_set_authentication_requirement (BONDING, MITM_PROTECTION_NOT_REQUIRED, SC_IS_SUPPORTED, KEYPRESS_IS_NOT_SUPPORTED, 7, 16, USE_FIXED_PIN_FOR_PAIRING, 123456, 
STATIC_RANDOM_ADDR);

I wanted to bond using the “Just-Works” scheme, but this particular set of calls above made pairing process behave very oddly. I was able to scan for my device (still using nRF connect), and to bond (… -> bond), but it would not appear on the “bonded” list as it usually happened:

And although I could connect to such oddly bonded device and even reconnect to id multiple times, what I could not achieve was to reconnect after devices disconnected by themselves due to signal loss (i.e. when a cellphone was carried away). In such case, when I brought my cellphone back and turned scanning on, my BlueNRG device would reappear in the “Scanned” list but with different address! Trying to connect to it would return GAT ERROR 0x3d in the nRF logs which means BLE_ERROR_CONNECTION_END_WITH_MIC_FAILURE (MIC is some little chunk of bytes added to the payload when privacy is turned on if I remember correctly). To fix this I had to do two things:

replace IO_CAP_NO_INPUT_NO_OUTPUT with IO_CAP_DISPLAY_ONLY.
reset the phone and find out, that “Bonding” list in the nRF connect was all of a sudden populated with ten or so instances of my BlueNRG device made that day during some of the tests. And then during pairing, I had to enter a PIN (123456), and after that I was able to do whatever I wanted, disconnect, go out of range, reconnect turn Bluetooth off and on, reset the phone and so on. All worked pretty fine.

Remarks / TODOs:

My peripheral’s (BlueNRG) name isn’t shown int the “Scanned” list in nRF connect, and I don’t know how to fix this.
I don’t know how to enable “Just Works” scheme.
Linux (Ubuntu 18.04) uses static random addresses, so the whole address resolving and privacy thing is not a problem.

Self balancing robot improvements

2018-01-16T00:00:00+01:00

I was dissatisfied with robot’s performance, so I experimented a lot with various aspects to improve it. But along the way, the robot, however simple in concept, proved to be a pretty complex system which depends on many factors that I didn’t anticipate. This variety of factors which altogether influence its movements make it very difficult to troubleshoot problems. So, now I’ll try to recall my adventures with it in order. Oh, and my objective (best case scenario) is to make it stable to the point it stands completely still. This is what I found the most difficult.

Better motors

I decided, my first set of motors (Dagu DG02S 48:1) have too low torque on low RPM (driven from DRV8835 H-Bridge again with PWM). The robot was able to stand, but wiggled (video in the previous post). So I changed them to JK28HS32 stepper motors, which proved to be even weaker. They simply have too low torque in all RPM range for the weight of my robot. More disadvantages:

Draws tons of current even when robot is stationary. This is because un-geared steppers (at least small ones) spin freely when unpowered and thus need current which hold them in position.
More complex electronics (1 H-bridge per motor instead of 1/2 per brushed one), and much more complex programming.
Intense vibration even in half stepping mode. And I used 200step ones. The solution for that would be to use smaller wheels with soft tires or implement micro stepping which would in turn reduce its incremental torque. Every time I use one of these steppers, and I dig into the subject I realize how difficult a stupid motor might get. So, not without disappointment I moved to another set of motors which happened to be Brushless DC Motor with Encoder 12V 159RPM from DFrobot (I found them on Aliexpress BTW). To my consternation it didn’t help much. Advantages of the newly mounted motors are its high torque, ease of interfacing (they have controller stuffed inside), but cons are:
They have quite some backlash.
They run on 12V, so I had to rework some of the electronics.
They might be a little bit faster, though at the end I was able to stabilize the thing pretty satisfactory.

To sum up : high-quality motors eliminate one point of failure and let you focus on different aspects if something is failing. My ideal motors, that I would like to have are:

Precise in terms of control. Wide range of RPMs i.e. able to spin super slow or quite fast with decent torque in all situations. What is a decant torque? Dunno. 2,4 kg*cm?
Fast. I would love to have 300RPM.
Minimal backlash.
Encoders built-in.
Not to mention power efficiency and ease of programming, but this is not the most important thing.

Surface

So then I finally decided, that I stop there with changing motors, and won’t replace them for the 4th time, but try to tune the PID and fiddle with the software. I replaced my fusion algorithm from simple complementary one to Madgwick, which open-source implementation is available online, and it is a part of a PhD thesis of some clever guy (Sebastian Madgwick). I cannot stress how far superior this algorithm is over my humble thing. But no luck with that neither. If I increased Kp and Ki it would oscillate vigorously (Kd was of not much help there), and when I decreased Kp and especially Ki, the robot would always drift away gaining speed and tipping over. Playing with the dreaded thing which would not stand at all, and wiggle as some drunk I recalled, that on many YT videos ( user upgrdman among my favorites on the subject) people was driving their robots on soft surfaces like carpets and that made me wonder. So I put my robot on a blanket and it helped a little. It reduced both oscillations and the drifting. I have a theory, that firm surface (and/or soft tires) first damps vibrations, but also when a tyre flattens under the weight, it somewhat blocks further movements. Hard tires do not have this effect and on hard surfaces, they spin every time the robot is only slightly out of its balance, where as on soft ones this slight error can be counteracted by a deformed wheel to some very small extent. Think of dry sand on the beach and big soft wheels, I think even when unpowered, the robot could have a chance to stand still in such an environment. So it thought about changing the wheels (and tires) because at that time I used pretty hard wheels from a hardware store (some furniture ones) and I ordered 70mm and 110mm squishy wheels for model aircraft. And then, while waiting for the wheels I made hasty decision to shorten the thing.

Length

Bear in mind, that I can be completely wrong here! As far as I understand, when you have a normal pendulum, the longer the string is, the faster will be the linear velocity of the pendulum bob. I assumed The same thing will be with inverted pendulum, thus the taller the robot, the bigger velocity of it top-end when tipping over. Thus, I concluded, the faster lower-end movements will be necessary to counteract the moving top. At that time I thought my motors are to slow, so It seemed to be a good idea to shorten the body. So I did that. And the improvement was negligible if at all. Also, from the pendulum frequency equation I knew, that shortening the length increases the pendulum frequency, so I understood that my algorithm must react faster from now on.

Mechanical issues

Then I realized, that the wheels got loose. I ordered a bunch of adapters and fixed them in place. Still no luck.

Scratching head and tuning PID

I couldn’t sleep but visualized my dangling robot. I tried to tune the PID controller a lot. And still, every time I increased Ki it oscillated, and when decreased it drifted away. Too much Ki and it oscillated left and right, and too much Kd and it oscillated but in like one direction. Like hiccup. Derivative term damps output when error decreases, so in theory, the robot should decelerate near sweet point and make a full stop but instead, it would stop for a moment (like millisecond moment), and start in the same direction, then stop and then again, all in sudden sequence.

nRF24L01+ distraction

I was frustrated and sick and tired, so decided to do something different, as a break from the main subject. I got into nRF24 code and telemetry. I wanted to make full telemetry for the project as YT user upgrdman did. I thought that it would help me to debug. Then I run into more problems, procrastinated a little bit more with refactoring my SPI library and so on. I had curious adventures with nRF though, but this is completely different story. I use an excellent application called KST2 for plotting the data. From the plots, I observed that the robot is drifting due to sudden integral peaks. It’s like the robot was balancing for a moment, and then the pitch plot would show a slight shift towards one direction, and just after that the integral part grew, robot started to move and tried to catch up, the i increased and increased, robot speed up, and then output saturated leading to a crash. The only thing which helped a little was to increase Ki (it amplified the reaction for integral, so robot drove faster, so was able to catch up and straighten), but it also increased oscillations.

Main loop frequency

In the act of desperation, not hoping for a change for better, I increased the main loop frequency from 100Hz to 1kHz. I could do that because I use very fast STM32F4 (compared to Arduinos and Atmegas that everybody seems to love so much) with a fpu. And that was it. It calmed the robot so much, that I could increase Ki to the values not possible before. Then I mounted the 110mm squishy wheels and it helped even more for the reasons described above, and because bigger wheels give more speed. That’s all for now, I’m a little bit tired of this project, but in the future I plan to:

Program encoders.
Program remote control (I bought myself a nice Devo 7E transmitter).
Experiment with all (or most) of the parameters I talked about. Height vs. loop frequency, various wheels and so on.

Self balancing robot first tests

2017-12-28T00:00:00+01:00

I have built a self-balancing robot, and here I want to post some notes regarding problems that I encountered. It was (as usual) more difficult than I anticipated, but I guess every hacker know this feeling.

Frame

The frame is made of 8mm aluminium pipes, 2 sheets of 2mm solid transparent polycarbonate, and aluminium angle bars. The pieces are screwed together with threaded rods and self-locking nuts. Making the frame was the easiest part, so I won’t write much about it.

Motors

Motors are labeled “Dagu DG02S 48:1”, and I am disappointed, because they have very low torque at low RPM, and are of a low quality I think (their low price also suggests that). The consequences are, that they are unable to move my robot gently and precisely, but instead, they start all of a sudden with a couple of RPMs. At very low PWM duty cycle they are unable to move wheels at all, even with no load. The lowest RPM I can get out of them is probably a couple of RPMs, which sounds OK, but I think, that many of my problems arise from them being unable to gently move the wheels a few millimeters forth and back. Such a gentle movement is in my opinion crucial for steady (nearly stationary) operation, that you have on certain YouTube videos. So next tests (if there will be any) will be performed with steppers or geared brushless motors. Oh, and there are no encoders either.

Electronics

If motors are the muscles, electronics are the brain. The mainboard is a STM32F4-DISCO and is connected to the battery via custom per-boards with connectors. On top of the robot, there is a single 16850 Samsung cell paired with cheap LiPo charger, and a switch. I chose it because it is a lot cheaper per mAh than those silverish ones. The battery sits inside a holder ordered on AliExpress. As of accelerometer and gyroscope, the super popular MPU 6050 does the job (also AliExpress). Motors are driven by Pololu DRV8835, and last but not least nRF24L01+ is used for connectivity with the robot, which is crucial to tune PID controller without dangling cables which would degrade stability, and make the center of mass unstable. Like shooting to a moving target.

Oh, and I wanted to control the robot using cheap CX-10 remote, but It failed. I based my code on deviation and other’s work, but after many hours I gave up. Then I’ve got Syma X5HW for Christmas, and with it’s remote I finally had success (after the first try, like 10 minutes of coding, not everyday something like this happens. But of course I only had to modify parameters for my CX-10 code). At first, I confused the binding channel number (I set 0 instead of 8), and I was still able to receive data, but only from approx 5 cm apart. Then after setting it correctly to channel 8 range increased dramatically.

Programming

https://github.com/iwasz/self-balancer
https://github.com/iwasz/libmicro With electronics and motors on its place, there comes programming, the most difficult part. First I made peripherals of the robot to work (Arduino library called i2cdevlib was very helpful), so I was able to read raw data from MPU 6050, send basic commands via nRF, and spin the motors. Then, the most challenging part was to implement:
pitch angle calculation ( http://www.starlino.com/imu_guide.html),
fusion of gyroscope and accelerometer data (this was helpful : http://www.pieter-jan.com/node/11
PID tuning (though implementing a PID is dead simple, tuning it is completely another story). Most helpful for me in this regard was probably the Wikipedia article on the PID controller. In my case, the most (positive) impact came from the integral part, where the D part seems to have minimal influence.

I’ll try to force myself to get into detail on the topics above, as I only scratched the surface.

Implementing zoom with moving pivot point using libclutter

2017-04-28T00:00:00+02:00

I’m making this post because I struggled with this functionality a lot! I was implementing it (to the extent I was happy with) in the course of 4 or even 5 days! Ok, first goes an animated gif which shows my desired zoom behavior (check out Inkscape, or other graphics programs, they all work the same in this regard):

Basically the idea is that, the center of the scale transformation is where the mouse pointer is on the screen, so the object under the cursor does not move while scaling, whereas other objects around it do. My first, and most obvious implementation (which didn’t work as expected) was as such:

/*
 * Point center is in screen coordinates. This is a where mouse pointer is on the screen.
 * The layout is : GtkWindow has ClutterStage which contains ClutterActor scaleLayer
 * (in this function named self), which contains those blue
 * circles you see on animated gif.
 *
 * ScaleLayer is simply a huge invisible plane which contains all the objects an user
 * interacts with. User can pan and zoom it as he whishes.
 */
void ScaleLayer::zoomOut (const Point &center)
{
        double scaleX, scaleY;
        // This gets our actual zoom factor.
        clutter_actor_get_scale (self, &scaleX, &scaleY);
        // We decrease the zoom factor since this is a zoomOut method.
        float newScale = scaleX / 1.1;

        float cx1, cy1;
        // Like I said 'center' is in screen coords, so we convert it to scaleLayer coords
        clutter_actor_transform_stage_point (self, center.x, center.y, &cx1, &cy1);

        float scaleLayerNW, scaleLayerNH;
        clutter_actor_get_size (self, &scaleLayerNW, &scaleLayerNH);
        // We set pivot_point
        clutter_actor_set_pivot_point (self, double(cx1) / scaleLayerNW, double(cy1) / scaleLayerNH);
        // And finalyy perform the scalling. Fair enough, isn't it?
        clutter_actor_set_scale (self, newScale, newScale);
}

Here is the outcome (wrong) of the above :

It is fine until you move the mouse cursor which changes the pivot point (center of the scale transformation) while scale is not == 1.0. I dunno why this happens. Apparently I do not understand affine transformations as well as I thought, or there is a bug in libclutter (I doubt it). The solution is to convert the pivot point from screen to scaleLayer coordinates before scaling (as I did), and again after scaling. The difference is in scaleLayer coordinates, so it must be converted back to screen coordinates, and the result can be used to cancel this offset you see on the second gif. Here is my current implementation:

void ScaleLayer::zoomIn (const Point &center)
{
        double x, y;
        clutter_actor_get_scale (self, &x, &y);

        if (x >= 10) {
                return;
        }

        double newScale = x * 1.1;

        if (newScale >= 10) {
                newScale = 10;
        }

        scale (center, newScale);
}

/*****************************************************************************/

void ScaleLayer::zoomOut (const Point &center)
{
        ClutterActor *stage = clutter_actor_get_parent (self);

        float stageW, stageH;
        clutter_actor_get_size (stage, &stageW, &stageH);

        float dim = std::max (stageW, stageH);
        double minScale = dim / SCALE_SURFACE_SIZE + 0.05;

        double scaleX, scaleY;
        clutter_actor_get_scale (self, &scaleX, &scaleY);

        if (scaleX <= minScale) { return; } scale (center, scaleX / 1.1); 
} 

/*****************************************************************************/ 

void ScaleLayer::scale (Point const &c, float newScale) { 
   Point center = c; float cx1, cy1; if (center == Point ()) { if (impl->lastCenter == Point ()) {
                        float stageW, stageH;
                        ClutterActor *stage = clutter_actor_get_parent (self);
                        clutter_actor_get_size (stage, &stageW, &stageH);
                        impl->lastCenter = Point (stageW / 2.0, stageH / 2.0);
                }

                center = impl->lastCenter;
        }
        else {
                impl->lastCenter = center;
        }

        clutter_actor_transform_stage_point (self, center.x, center.y, &cx1, &cy1);
        float scaleLayerNW, scaleLayerNH;
        clutter_actor_get_size (self, &scaleLayerNW, &scaleLayerNH);
        clutter_actor_set_pivot_point (self, double(cx1) / scaleLayerNW, double(cy1) / scaleLayerNH);
        clutter_actor_set_scale (self, newScale, newScale);

        // Idea taken from here : https://community.oracle.com/thread/1263955
        float cx2, cy2;
        clutter_actor_transform_stage_point (self, center.x, center.y, &cx2, &cy2);

        ClutterVertex vi1 = { 0, 0, 0 };
        ClutterVertex vo1;
        clutter_actor_apply_transform_to_point (self, &vi1, &vo1);

        ClutterVertex vi2 = { cx2 - cx1, cy2 - cy1, 0 };
        ClutterVertex vo2;
        clutter_actor_apply_transform_to_point (self, &vi2, &vo2);

        float mx = vo2.x - vo1.x;
        float my = vo2.y - vo1.y;

        clutter_actor_move_by (self, mx, my);
}

The whole project is here : https://github.com/iwasz/data-flow-gui Here’s the thread which pointed me in right direction : https://community.oracle.com/thread/1263955

Cross compilation with GCC & QtCreator for ARM Cortex M

2016-06-21T00:00:00+02:00

This post is outdated!! . Please see http://www.iwasz.pl/electronics/stm32-on-ubuntu-linux-step-by-step/ for more up to date instructions.

I used Eclipse CDT for years for C/C++ and was disappointed by its bulkiness, slowness, and memory usage. I did mostly embedded, and sometimes GTK+ desktop apps (even OpenGL once or twice). I looked for a replacement, tried dozen or more IDEs and editors, and finally found out the QtCreator (my main concerns were : great code navigation - eclipse often get confused wit serious, templated C++ code), great code completion, and CMake integration. I am satisfied for now (It’s been a year now), and I use it for all but Qt. But all of a sudden, wen a new version appeared, I came across a minor flaw in CMake builder, which reported an error like “Can’t link a test program”. Obviously it cannot because he used a host compiler instead of ARM one.

So in versions prior to 4.0.0 I used to configure my project with cmake like:

cd build
cmake ..
make

Then, from QtCreator, I simply compiled the project, and it worked flawlessly. But since QtCreator 4.0.0 it started to invoke cmake in every possible situation. Be it an IDE startup, or saving a CMakeLists.txt file. And it did it with -DCMAKE_CXX_COMPILER=xyz where “xyz” was a path configured in Tools -> Options -> Build & Run -> Compilers. If I run cmake manually, without this CMAKE_CXX_COMPILER variable set, everything was OK. I saw on the Internet, that many people had the same problem, and used QtCreator for embedded like I do ( see comments here).

So I decided, that instead of forcing QtCreator to stop invoking cmake, or invoking it with different parameters, I should fix my CMakeLists.txt so it would run as QtCreator want it. A solution I found was CMAKE_FORCE_C_COMPILER and CMAKE_FORCE_CXX_COMPILER documented here. My CMakeLists.txt looks like this:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

SET (CMAKE_VERBOSE_MAKEFILE OFF)
include (stm32.cmake)

PROJECT (robot1)

SET(USB_LIB "" CACHE STRING "")

INCLUDE_DIRECTORIES("src/")
LIST (APPEND APP_SOURCES "src/main.c")
LIST (APPEND APP_SOURCES "src/stm32f4xx_it.c")
LIST (APPEND APP_SOURCES "src/syscalls.c")
LIST (APPEND APP_SOURCES "src/system_stm32f0xx.c")
LIST (APPEND APP_SOURCES "src/config.h")
LIST (APPEND APP_SOURCES "src/stm32f0xx_hal_conf.h")

AUX_SOURCE_DIRECTORY ("${CUBE_ROOT}/Drivers/STM32F0xx_HAL_Driver/Src/" APP_SOURCES)
LIST (APPEND APP_SOURCES "${STARTUP_CODE}")

ADD_EXECUTABLE(${CMAKE_PROJECT_NAME}.elf ${APP_SOURCES})
ADD_CUSTOM_TARGET(${CMAKE_PROJECT_NAME}.bin ALL DEPENDS ${CMAKE_PROJECT_NAME}.elf COMMAND ${CMAKE_OBJCOPY} -Obinary ${CMAKE_PROJECT_NAME}.elf ${CMAKE_PROJECT_NAME}.bin)

FIND_PROGRAM (ST_FLASH st-flash)
ADD_CUSTOM_TARGET("upload" DEPENDS ${CMAKE_PROJECT_NAME}.elf COMMAND ${ST_FLASH} --reset write ${CMAKE_PROJECT_NAME}.bin 0x8000000)

And the “toolchain file” is like this:

SET (TOOLCHAIN_PREFIX "/home/iwasz/local/share/armcortexm0-unknown-eabi" CACHE STRING "")
SET (TARGET_TRIPLET "armcortexm0-unknown-eabi" CACHE STRING "")
SET (DEVICE "STM32F072xB")
SET (CUBE_ROOT "/home/iwasz/workspace/stm32cubef0")
SET (CRYSTAL_HZ 16000000)
SET (STARTUP_CODE "src/startup_stm32f072xb.s")
SET (LINKER_SCRIPT "${CMAKE_SOURCE_DIR}/src/STM32F072RB_FLASH.ld")
SET (TOOLCHAIN_BIN_DIR ${TOOLCHAIN_PREFIX}/bin)
SET (TOOLCHAIN_INC_DIR ${TOOLCHAIN_PREFIX}/${TARGET_TRIPLET}/include)
SET (TOOLCHAIN_LIB_DIR ${TOOLCHAIN_PREFIX}/${TARGET_TRIPLET}/lib)

INCLUDE(CMakeForceCompiler)
SET (CMAKE_SYSTEM_NAME Generic)
SET (CMAKE_SYSTEM_PROCESSOR arm)

CMAKE_FORCE_C_COMPILER ("${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-gcc" GNU)
CMAKE_FORCE_CXX_COMPILER ("${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-gcc" GNU)
SET (CMAKE_ASM_COMPILER "${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-as")
SET (CMAKE_ASM-ATT_COMPILER "${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-as")
SET (CMAKE_OBJCOPY ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-objcopy)
SET (CMAKE_OBJDUMP ${TOOLCHAIN_BIN_DIR}/${TARGET_TRIPLET}-objdump)
SET (CMAKE_C_FLAGS "-std=gnu99 -fdata-sections -ffunction-sections -Wall" CACHE INTERNAL "c compiler flags")
SET (CMAKE_CXX_FLAGS "-std=c++11 -Wall -fdata-sections -ffunction-sections -MD -Wall" CACHE INTERNAL "cxx compiler flags")
SET (CMAKE_EXE_LINKER_FLAGS "-T ${LINKER_SCRIPT} -Wl,--gc-sections" CACHE INTERNAL "exe link flags")
SET (CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
SET (CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")

INCLUDE_DIRECTORIES(${SUPPORT_FILES})
LINK_DIRECTORIES(${SUPPORT_FILES})
ADD_DEFINITIONS(-D${DEVICE})
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/STM32F0xx_HAL_Driver/Inc/")
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/CMSIS/Device/ST/STM32F0xx/Include/")
INCLUDE_DIRECTORIES("${CUBE_ROOT}/Drivers/CMSIS/Include/")

ENABLE_LANGUAGE (ASM-ATT)

Two most important changes were:

Using CMAKE_FORCE_CXX_COMPILER macro instead of simply setting CMAKE_CXX_COMPILER var.
Including the toolchain file (and thus setting / forcing the compiler) before PROJECT macro.

My configuration as of writing this:

Qt Creator 4.0.2, Based on Qt 5.7.0 (GCC 4.9.1 20140922 (Red Hat 4.9.1-10), 64 bit), Built on Jun 13 2016 01:05:36, From revision 47b4f2c738
Host system : Ubuntu 15.10, Linux ingram 4.2.0-38-generic #45-Ubuntu SMP Wed Jun 8 21:21:49 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Host GCC : gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Target GCC : armcortexm0-unknown-eabi-gcc (crosstool-NG crosstool-ng-1.21.0-74-g6ac93ed - iwasz) 5.2.0

BlueNRG + STM32F7-DISCO tests

2016-03-21T00:00:00+01:00

Tested 32bit cross-compiler from Launchpad, it worked OK, but binaries were much bigger, and debugger lacked Python support which is required by QtCreator which is an IDE of my choice (for all C/C++ development including embedded).

Made my own compiler with crosstool-NG (master from GIT). Used my own tutorial, which can be found somewhere over this blog.
Verified that a “hello world” / “blinky” program works. It did not, because I copied code for STM32F4, and I messed the clock configuration. Examples from STM32F7-cube helped.
I ported my project which aimed to bring my BlueNRG dev board to life. The project consists of a USB vendor-specific class for debugging (somewhat more advanced, and tuned for the purpose than simple CDC class), slightly adapted BlueNRG example code from ST (for Nucleo), and some glue code.
I switched to STM32F7-disco because I couldn’t get BlueNRG to work with STM32F4-disco. F7 has Arduino connector on the back, so I thought it’d be better than bunch of loosely connected wires which was required for F4. At that time I thought that there is something wrong with my wiring.
On STM32F7-disco BLE still would not work. I hooked up a logic analyzer, and noticed that MISO and CLK is silent. It turned up that I have to use an alternative CLK configuration on BlueNRG board which required to move 0R resistor from R10 to R11. Although it was small (0402), at first I had a problem desoldering it, probably because of the unleaded solder used. See image.

Next problem I had, was with SPI_CS pin. According to the BlueNRG-dev board docs, I wanted to use D8 pin (this is PI2 pin on STM32F7-disco), but it didn’t work. Glimpse on the schematics revealed that the SPI_CS is connected to A1, which is marked as “alternative” in the docs. So IMHO this is an error in the docs.
Final pin configuration that worked was:

// SPI Reset Pin
#define BNRG_SPI_RESET_PIN GPIO_PIN_3
#define BNRG_SPI_RESET_PORT GPIOI
// SCLK
#define BNRG_SPI_SCLK_PIN GPIO_PIN_1
#define BNRG_SPI_SCLK_PORT GPIOI
// MISO (Master Input Slave Output)
#define BNRG_SPI_MISO_PIN GPIO_PIN_14
#define BNRG_SPI_MISO_PORT GPIOB
// MOSI (Master Output Slave Input)
#define BNRG_SPI_MOSI_PIN GPIO_PIN_15
// NSS/CSN/CS
#define BNRG_SPI_CS_PIN GPIO_PIN_10
#define BNRG_SPI_CS_PORT GPIOF
// IRQ
#define BNRG_SPI_IRQ_PIN GPIO_PIN_0
// !!!
#define BNRG_SPI_IRQ_PULL GPIO_PULLDOWN
#define BNRG_SPI_IRQ_PORT GPIOA

Next thing that got me puzzled for quite a time was that after initial version query command, which seemed to work OK (I got some reasonably looking responses) the communication hanged. IRQ pin went high, and wouldn’t go low. So µC thought that there is data to read and was continuously reading and reading.
Only after I read in UM1755 User manual that IRQ goes HI when there is data from NRG to µC, and it goes HI-Z when there is no data, I double checked the schematics, and found that BlueNRG-dev board has no pull-down resistor in it. The ST example code I had also hadn’t have IRQ pin configured in pull-down state, so I wonder how this could work. Maybe Nucleo boards have pull-down resistor soldered there.
For now (after 3 or 4 nights, and I consider myself as quite experienced) I got this (see photo):

Quick update made the next day morning. My Linux computer is able to connect to the test project, and query it (right now it simply counts up):

Internet thermal printer part 2

2014-07-21T00:00:00+02:00

The printer I bought and described in the previous post really disappointed me. I didn’t spend some huge amount of time on that (say 3-4 evenings), but I dig into the subject so deep so I couldn’t help myself but do some more hacking. First of all I wanted to know if my cool looking, but quite useless printer can be used in some other way (i.e. the printing head) and whether that is the main board which is broken or the head itself. If the former was true, and the head was OK, I would try to communicate with the head and thus make something which would pretty much implement the whole printer main board that was broken. But if the head was broken, I couldn’t do anything but to abandon the project or find another printer. And it’s funny, because, as you may have seen at the end of my previous post, this is exactly I’ve written not to do. But I just love it. When the work you do all day every day is stupid and pointless, when you are constantly bothered with more and more irrelevant things, and after all day you are tired and discouraged, what would you do after arriving home (excluding household duties :D)? Grab a beer, sit and watch TV? Hell no! Grab a beer and tinker some more! It calms me down you know (unless I’m stuck for to long). The printer head used in my Intermec PW40 is a Seiko ( www.sii.co.jp) SII LTP3445 (datasheet here) and it is obsolete. New designs are encouraged to use LTPV445.

So what I did is that I soldered a bunch of wires to the main board to be able to speak directly to the printing head. The resulting wiring looks like that:

Then I grabbed signals with a logic analyzer and an oscilloscope to figure out what is malfunctioning (i.e. when the printer was operating). In my opinion, the main board is broken, because printing short strings like ‘A\r\n’ works OK, and all signals seems to be correct (i.e. 832 bits per row are transferred and quite a few rows are present). But when longer strings are submitted, the whole transmission appears to be corrupted at some point. Serial data burst is clearly shorter, like interrupted. Unfortunately I have made a screenshot of correct transmission (A\r\n), and don’t have the corrupted one now (and the board is not operational since I removed the FFC socket). Here’s the screen:

Above : a correct transmission to the thermal head issued by the original Intermec PW40 main board. Letter ‘A’ is being transmitted.

The next step was to wire up some circuitry to actually drive the head while it was still soldered to the original main board. I didn’t want to break it then, but later it ceased to be a priority :D My setup consists of:

Texas Instruments EK-TM4C123GXL as the main logic unit.
DRV8835 Dual Motor Driver Carrier from Pololu. It uses a DRV8835 chip from Texas Instruments.
Two CD40109B level shifters from Texas Instruments. Breadboard looks like this:

Above : the circuit. You can see that the printer is more or less intact i.e. the head is mounted on the main board and the plastic frame. Later on I decided to disconnect the head from the original main board.

Shifters are controlled with 3.3V and output 5V for the head’s logic. The whole contraption is powered from a laboratory power supply which was set to 5V with low current limit to prevent smoke and fire in case of errors in wiring on my side. The setup drawn about 0.1A when idle and 2.5A when feeding the paper. Driving the motor was pretty easy, I did stepper motor before, so I rather quickly caught up with this one. But the head took more time and at some (thankfully short) time I was stuck. First, the DST signal (DST is for power and thus temperature) circuitry on the main board is secured with some (I believe) TTL logic. The idea is that if the thermistor says to the µC that he head is overheating, the µC shuts the head down. This is the first protection mechanism programmed in software (BTW manual says that if overheat, the head may cause skin burns, smoke and even fire. It is a thermal one after all). But there is another protection mechanism done in hardware which shuts down the head if the software one malfunctions. I believe, that the two mechanisms are AND-ed by some TTLs. The protection mechanisms are pulling down the DST in case of trouble. In my case, when actually two logic circuits were connected to the head, this situation caused problems, because the original main board, which was not powered, pulled the DST down all time. The solution to this was to cut the trace and that was it (if not cut, the DST would stay low no mater what level I was trying to drive it. Oscilloscope shown only 100mV level changes, obviously to small to be useful).

Above : a transmission. A 12*8 pixel wide bar strip. 12 x 0xaa.

But still no luck after the DST problem was resolved, so I decided that something else on the original main board is interfering and I need to disconnect the head from it in sake of connecting to it directly. Didn’t have spare FFC socket though (Molex 25 pin 1.25 mm pitch rare and obsolete), so after obtaining a wrong one from Farnell (bought 1 mm pitch instead od 1.25 duh!) I soldered the wires directly to the FFC cable. Looks awful, but is rigid:

Still no luck! What the hell! Logic analyzer still happily shows correct bursts of data, so for the third time rewired the breadboard and checked levels with an oscilloscope. And curious thing revealed : all levels (shifted up) were 0-4V instead od 0-5V. I have completely no idea why? My power supply is a cheap one, but can 1 or 2 amps of load cause 1V drop? Must investigate further.

EDIT my cheap counterfeit Saleae logic analyzer must have somewhat low input impedance and it was it that caused significant voltage drop on logic signals. Disappointing. On the picture below you can see (far left) that only after increasing the voltage repeatedly, the printer started to print:

I’m excited!

Internet thermal printer

2014-07-11T00:00:00+02:00

What this project is intended to be:

A toy printer (for my son) with some light and sound signal connected to the Internet and accessible by some web interface. Anyone with password (basic auth configured in .htaccess) could send a graphic and/or text message to the printer which would immediately flash the light, beep the buzzer as well as print the message. Protocol to the printer (on the network level) : whatever a.k.a my own & super-simple.

~~What this project shall not become~~. EDIT: It evolved.. (note to myself because I tend to complicate things):

An over-engineered wireless CUPS compatible Postscript full featured printer which also makes coffee.

After deciding that I would try to make such a thing which took approx. 1 second after seeing Jim’s site I went to allegro.pl (local EBay. BTW we have ebay.com.pl here in Poland, but allegro seems to be winning the battle) and found something printer-ish alike and seemingly broken, with some parts missing. It is a Intermec PW40 mobile printer. Useful links I found on this printer:

Manuals - Intermec site (those are for PW50, but I assume they are compatible in some way).
Intermec community - they even have forum, and some community around the site. Photos after dismantling the thing:



Main Board	Main board mounted on the plastic frame.	Main board

Main board	Bottom view. Without the casing.	Printer from above without the casing.

The head. It is 2005 made I believe.	Thermal head sticker.	Thermal head closeup

7.2V Batteries, pretty dead.

The sticker is important because it has markings which informs you about certain resistance levels in the head. My head is a “C” type.

Looks like it uses ESC/P like Jim’s printer and 7.2V battery pack also. Looks promising (at least some standard language). Elements found on the main board of PW-40:

Toshiba TMP95C061BF : some 16 bit microcontroller. TLCS-900 family. No free C compiler available according to Wikipedia.
NEC D431000AGW : SRAM 1Mb
ST M29F040B : Flash 4Mb.
LinearTechnology LTC1384CG : this is what I was looking for : a RS232 transceiver.
CS8130 : IR transceiver.

I’ve written the LTC chip looks promising, because it connects the printer to the outside world, and gives a hint where to start hacking. It translates RS232 high voltage levels to TTL, but since I wanted to drive the printer directly from some µC I needed to bypass the LTC. After some research I determined what follows : RS 232 port (this with RJ socket) is connected to pins 14 (232 input) and 15 (232 output). Corresponding TTL pins are : pin 13 (logic output), and 12 (logic input). So as far as I am reasoning correctly :

Pin 13 is connected to the Toshiba’s RX pin.
Pin 12 is connected to the Toshiba’s TX pin.
The whole device can be powered from 12V supply (I read that somewhere).
Let’s try it! It seems to work. At least a PC and the printer are communicating. Wiring looks like this:

Costs so far:

Printer : 25PLN ($8).
10 rolls of thermal paper 20PLN ($7)

Intermec provides a CUPS driver for Linux which enables you to use their printer as regular printer in the OS. Apparently PW40 isn’t supported. I successfully compiled and installed the software, but printing a random text file gave me some gibberish. After that I tried to communicate with te printer in ESC/P language directly, but with no luck. I described my problems on the Intermec forums and still waiting for some reply. In short the problem is, that I don’t really know for sure if this is me doing something wrong, or the printer is broken (it was sold on auction as broken, but the seller couldn’t tell for sure if it is really broken or not). So after two evenings the situation looks that I am able to print only one character in a row. If I’m sending more than 1 character to print, it hangs. To make matters worse, my printer won’t print a self test page as it is described in the manual. It feeds paper a little and that’s all. At the other hand I found a datasheet of the printer head used in my printer, but using it directly would be a triumph of form over the content I’m afraid, and I don’t have enough time for that (i.e. making my own printer from scratch). But I’m overambitious you know, so who knows…

The any key

2014-06-09T00:00:00+02:00

…which in fact is an one button HID keyboard which you can reprogram to be any key or combination of keys you wish (open-source hardware and software). For starters here’s a bunch of links:

And a quick video (one blurry shoot):

At some point, after a few battles I bravely fought with STM32 I wanted to learn something new. I’ve been a few times on Texas Instrument’s site because I wanted to learn more about BeagleBone black and the Sitara CPU that sits on it and spotted the TIVA microcontrolers somewhere on the page. After quick research they looked very promising. It had all I needed that is : can be easily programmed with GCC stack under Linux, has affordable starting platform (they call them launchpads, and they cost $13 and $20 for TM4C123 and TM4C129 respectively) and, what is most important for me, they have well written peripheral libraries and documentation (i.e. at that time I could only rely on opinions from the Web, but after my first project I definitely can confirm that).

So I started a new simple project, which I previously tried to make with STMs and had countless problems with (here is the link). I’ve got EK-TM4C123GXL launchpad and it’s great. Somewhere in near future I’ll try to write another post which would explain how to start development on Linux with GCC toolchain with this board, but for now I can only assure you that getting started was as easy and quick as one evening (I used my own cross-compiler which is described in previous post here). The project aims to construct one button USB-HID keyboard which could be reprogrammed in such a way that pressing the button would send any key code user wishes or even combination of keys if necessary. I imagined, that it would be super cool to have something like that on my desk at work, and if someone comes by and interrupt me with my work, I would ostentatiously hit the big red button which stops the music in my headphones and ask : “what? once again?”. TI provides excellent peripheral library with many examples for many evaluation boards. Furthermore they have great USB library which is neatly divided in four tiers dependent on each other. On the very top is the highest level tier called the “Device Class API” which enables one to implement typical devices in just few lines of code (I mean simple HID, DFU, CDC etc.) ST does not have that! Device class API is great, but in fact quite inflexible. For example HID keyboard can have only one interface which is not enough if one wants to implement something more sophisticated. Here are instructions for designing HID a keyboard design with additional multimedia capabilities (which I wanted so bad). Microsoft recommends that there should be at least two USB interfaces in such a device. One should implement a ordinary keyboard compatible with BOOT interface, so such keyboard would be operational during system start up, when there is no OS support yet, and another one would implement the rest of desired keys such as play/pause, volume up, down and so on. I saw quite a few USB interface layouts conforming to this recommendations over the net, including my own keyboard connected to my computer as I write this, so I assume this is the right way to do this. And here is an example of USB interface layout as mentioned earlier. HID reports are also provided. So I moved to lower level tiers and it was not so simple. Here you can find all the code that is inside the button. All the magic is done in main.c which could be split in several smaller files, but who cares. Firstly there are USB descriptors. Standard and HID ones:

const tConfigSection *allConfigSections[] = {
        &configSection,
        &interfaceSection1,
        &hidKeyboardSection1,
        &endpointSection1,
        &interfaceSection2,
        &hideKeyboardSection2,
        &endpointSection2
};

Next you have callbacks. My code is heavily based on TI examples, but in some places it is simplified where no advanced functionality is needed. Custom requests are handled in onRequest where you can find bits responsible for sending and receiving configuration from the host (using another program running on a PC which is linked below). Configuration (i.e. what key combination should be sent to the host when “any-key” is pressed) is stored in eeprom (functions readEeprom and saveEeprom ). And of course in main function you can find the main loop with buttons polling and report sending. After connecting the device to a Linux PC it introduces itself as two interface HID device which is silently recognized by Linux (and not so silently by Windows which searches for some drivers for it). What distinguishes this HID keyboard from others is that it recognizes two additional control requests from the host PC which enables user to store and receive combination of keys this device sends when pressed. This requests are prepared in PC application which looks like this:

Every button on the main screen can be toggled (on the picture above the “play/pause” one is turned on) which immediately sends the configuration data which is stored in eeprom. After closing the host application (which then releases the USB device to the OS) button works as programmed, in situation depicted above behaving as a play/pause keyboard button. Play/pause was my initial intention and I am using it with this function right now, but friend of mine used in on presentation (as arrow down), and also I tested ctrl-alt-del, ctrl-shift-t (eclipse CDT open element), and power among others. Maximum simultaneously pressed keys which can be simulated is 8 for control ones (like ctrl, shift, alt etc) and 6 for regular ones.

So there you have it. Feel free to post questions etc. I am also wondering about a “mass production experiment” which would aim to make, say, 10 of those things (with cheaper micro of course!) and sell them on tindie (I have never sold anything made by myself yet). What do you think? Would you buy one of these? What would be reasonable price for this (it is only one button after all… + PC app). I made some very rough calculations and the total cost of one device (assuming production of 100 pcs) would be somewhere around $10, when using MSP430 as a µC and importing casings from China. Not to mention boxes to pack the stuff, soldering (probably in some kind of reflow oven) and sending it all together. So for now it seems overwhelming for me, but who knows.

And for something completely different : what happens when you connect a USB device with VBUS and GND shorted:

Jun  4 08:58:52 diora kernel: [  998.928731] hub 2-1:1.0: over-current condition on port 1
Jun  4 08:58:52 diora kernel: [  999.136827] hub 2-1:1.0: over-current condition on port 2

… and you can hear humming in headphones connected to the PC.

EDIT: User jancumps on the EEVBlog forums pointed out, that there is an ongoing indiegogo campaign for a similar idea. Looks quite the same as mine :D
EDIT2: Dave did a review of the “serious button” this design is not mine, it only looks the same :

http://www.youtube.com/watch?v=f2Tr8r2j8wQ&t=12m44s

EDIT3 (09/2014) : Another one on indiegogo with goal of $100k!

Toolchain for Cortex-M4/M0/M7

2014-05-27T00:00:00+02:00

Installation

EDIT : do not accidentally press ctrl-c. It exists menu-config immediately.

Important links:

http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

These are brief instructions for creating your own GCC based tool-chain for a Cortex-M4 microcontroller, heavily based on this post. I tried a few precompiled ones which I found on the Internet, but always wondered how to make one which would be configured specifically for my micro, not for “ARM” in general. Tool-chains generated by the following method was tested by me on ST STM32F407 and Texas Instruments TIVA-C TM4C123 (i.e. one tool-chain for these two µC since they both include the same CPU). My setup as I write this:

Host operating system : Ubuntu 14.04 - 16.10
Kernel : 3.13.0-24-generic - 4.8.0-30-generic
Few GB of free space on HD.

Making a toolchain is hard, therefore wise people over the net developed tools to simplify the process. Few years ago, when I attempted to build a GCC tool-chain I struggled with lack of information, complexity of the process, and variety of recipes, which all seemed were extremely complex, and in some point in the process I was struck with problem I couldn’t solve. Then I found crosstool-NG - it may seem funny, but all this stuff was new to me, and I was looking for the best way possible to finish the task, some “canonical” way of building a cross-compiler, and for me, crosstool-NG is exactly this. Lets grab the newest version from its website and follow the installation instructions (this step will build only the crosstool-NG itself, read the EDIT note below before doing this):

mkdir my-toolchain
cd my-toolchain

# Pay attention which version is the newest. As of writing this, the newest was
# 1.19.0, but at http://crosstool-ng.org/download/crosstool-ng/ the "header-file" 
# incorrectly indicated the 1.18.0 version
wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.19.0.tar.bz2

tar jxvf crosstool-ng-1.19.0.tar.bz2 
cd crosstool-ng-1.19.0/

# Resolve some dependencies. EDIT Ubuntu 15.04 wants libtool-bin as well.
sudo apt-get install bison flex gperf texinfo gawk libtool libtool-bin automake libncurses5-dev libexpat-dev help2man

# Provide a prefix to some destination which PATH points to.
./configure --prefix=/home/iwasz/local/
make
make install

EDIT (2016-12) It seems, that the newest official release available today is 1.22, which is more than year old. The older ct-ng is, the older GCC, and libraries it provides, which may cause a problems on newer systems. For example making a cross-gcc version 5.3 using ct-ng version 1.22 on Ubuntu 16.10 (which uses GCC 6.2) resulted in compilation error during GCC stage. Thus I think, that the best option is to start with development ct-ng from github repo. Instructions are here but basically you only need to:

git clone git@github.com:crosstool-ng/crosstool-ng.git
cd crosstool-ng
./bootstrap
./configure --prefix=/home/iwasz/local/
make
make install

Now we perform some setup. All features of our future tool-chain will be set during this step:

# cd back, so we are in "my-toolchain" directory again.
cd ..
mkdir staging
cd staging
ct-ng  menuconfig

The last command brings the following menu-config tool:

Paths and misc options

Try features marked as EXPERIMENTAL : Y
~~Prefix : ${HOME}/local/share/${CT_TARGET} . Provide a destination folder that suits your needs, give descriptive name if you plan to host more than one crosscompilers.~~
Number of parallel jobs : 8 (depends on host capabilities of course).
Uncheck “Render the toolchain read-only” (I find it annoying to have read only directory in my stuff, it’s problematic to delete it later, you have to chmod etc).
Check “Debug Crosstool-NG”, “Save intermediate steps”, and “gzip saved states” as described here.

Target options

Target Architecture : arm
~~(cortexm4) Suffix to the arch-part (breaks the build!)~~. EDIT : tried with this turned on in 1.21.0, and works.
~~Use the MMU : N~~

The following 3 options can be somewhat tricky because when you set “ Emit assembly for CPU”, the two other (being “Architecture level” and “ Tune for CPU”) will disappear. So either you set the first mentioned one or two other.

Architecture level (correspods to -march flag). For Cortex-M4 use armv7e-m+fp (armv7-m for older compilers, probably before GCC-4.9). Pay attention that every architecture type has its own additional parameters which can be obtained from the man page. In this case I used “+fp” which stands for “the single-precision VFPv4 floating-point instructions”, just to be sure that hard-fp assembly instructions are emmited. EDIT : armv6-m for Cortex-M0. You can always check it in the “programming manual” of every STM32 part in chapter entitled like “About the STM32 Cortex-M0 processor and core peripherals”
Tune for CPU (-mtune) : use cortex-m4 or wathever you are using. Check the man page.
Emit assembly for CPU (-mcpu). Use this instead of the two above if you preffer, but remember, that GCC will then try to automatically figure out what architecture and tune flags to use. The values are the same as for -mtune, so we can use cortex-m4 for Cortex-M4 (full list of available options can be found in GCC manual somewhere near -mcpu phrase). Or here.
Use specific FPU : fpv4-sp-d16. Cortex-M4 can have FPU, but not necessarily (with FPU it is called Cortex-M4F, and Cortex-M4 without). But the fact is I found this option somewhere over the net, and I am a little bit confused on the topic of FPU. For STM32H7 you would use fpv5-d16 for double precision and fpv5-sp-d16 for single precision.
Floating point : hardware (FPU). EDIT : M0 have no FPU.
Default instruction set mode (thumb).

Toolchain options.

Add some cool Toolchain ID string.
Set “Tuple’s vendor string” to none.

Operating System.

Set Target OS to bare-metal:

Binary utilities

Binary format: ELF
binutils version (2.22) - latest which is not marked as EXPERIMENTAL. EDIT just recently I went with 2.24 (EXPERIMENTAL), and everything seems to be OK.

C compiler

Show Linaro versions : Y
gcc version (linaro-4.8-2013.06-1)
C++ : Y

C-library

C library (newlib)
newlib version (2.0.0 (EXPERIMENTAL)) - the newest, and works OK.
Disable the syscalls supplied with newlib : Y - I provide my own syscalls in every program. BTW I had some problems when his option was checked (crt0 missing?)

Debuging

gdb : Y

Then descend into “GDB” menu and check and choose the newest from linaro, and set Enable python scripting to N (caused build problems for me) EDIT : qtcreator requires python support in GDB:

Exit menu-config (few times ESC, and save when prompted) and finally build the toolchain:

unset LD_LIBRARY_PATH 
ct-ng build
tail -f build.log # in another console (not necessary if debug options were set)

The build process takes some time (30-60 minutes), and if in some point for some reason the build fail, first place you check is the build.log file in staging directory (therefore I pasted this tail -f command earlier, but of course it does not matter how you display the file). For example, in my case, the crosstool-NG decided to fail with this:

... kilobytes, megabytes of logs ....
[ALL  ]    checking whether to use python... yes
[ALL  ]    checking for python... /usr/bin/python
[ALL  ]    checking for python2.7... no
[ERROR]    configure: error: python is missing or unusable
[ERROR]    make[2]: *** [configure-gdb] Error 1
[ALL  ]    make[2]: Leaving directory `/home/iwasz/Documents/my-toolchain/staging/.build/arm-unknown-eabi/build/build-gdb-cross'
[ERROR]    make[1]: *** [all] Error 2
[ALL  ]    make[1]: Leaving directory `/home/iwasz/Documents/my-toolchain/staging/.build/arm-unknown-eabi/build/build-gdb-cross'
[ERROR]  
[ERROR]  >>
[ERROR]  >>  Build failed in step 'Installing cross-gdb'
[ERROR]  >>        called in step '(top-level)'
[ERROR]  >>
[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR]  >>        called from: do_debug_gdb_build[scripts/build/debug/300-gdb.sh@170]
[ERROR]  >>        called from: do_debug[scripts/build/debug.sh@35]
[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@632]
[ERROR]  >>
[ERROR]  >>  For more info on this error, look at the file: 'build.log'
[ERROR]  >>  There is a list of known issues, some with workarounds, in:
[ERROR]  >>      '/home/iwasz/local/share/doc/crosstool-ng/ct-ng.1.19.0/B - Known issues.txt'
[ERROR]  
[ERROR]  (elapsed: 58:52.70)

I didn’t thought long on this one (apt-get install libpython2.7-dev maybe???), but disabled the python support for GDB (I modified the instructions accordingly, so hopefully you haven’t had the same error). But in case you had, you should resolve the error (maybe change the configuration using menuconfig, or resolve the problem in other ways, depending on the cause) and rerun ct-ng, or refer to this stack-overflow thread for more info on speeding up the process after build has failed.

Edit Feb 2015 : I recently made cross-compiler x86_64 -> i686 to be able to make 32bit binaries on 64bit box. Statically linked binaries made with it crashed with message:

FATAL: kernel too old

Following suggestions found here, I found that indeed, my binaries were (output of file command):

ELF 32-bit LSB  executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.15.4, not stripped

But my uname -a is:

Linux xxx 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The solution is to instruct crosstool-ng so it compile glibc/eglibc with older kernel support. Invoke ct-ng menuconfig and:

Go into “C-library”
Go into “Minimum supported kernel version (Specific kernel version) —>”
Check “(X) Specific kernel version”
“ESC ESC” and make sure that : “(2.6.9) Minimum kernel version to support”

EDIT (mar 2016). For the second time I encountered an error like this:

[ALL  ]    /usr/bin/install: cannot stat '.../.build/src/newlib-linaro-2.2.0-2015.01/libgloss/arm/linux.specs': No such file or directory

According to this, and especially this , the error is caused by some bug in newlib itself. User ‘ bhundven‘ sugested that suffix ‘hf’ to ‘eabi’ (making it ‘eabihf’) is causing problems, so I turned off ‘Target options —> append ‘hf’ to the tuple (EXPERIMENTAL)’, and it helped.

EDIT (Jul 2018). Toolchain for Cortex-M0 was successfully tested on BlueNRG-1 and BlueNRG-2 IC’s, and works just fine.

Special remarks for LPC812 (March 2020)

This µC has so tiny amount of RAM and flash, that normal version of newlib is to heavy for it and compiler made using above instructions would not be able to produce a simple hello-world program that would fit in 16k of flash.

A glimpse into one of CMakeLists.txt provided by NXP as an example, shows that they use nano.specs, which instruct GCC to use libc_nano.a and libg_nano.a (when -g) instead of their full counterparts. I have been unsuccessful assembling a toolchain which would include libraries with those exact names (I mean with nano suffixes) but I finally found a way to compile the lighter libraries that would fit on the LPC812 instead of the usual ones. So even if they have usual names like libc.a, they are smaller and lighter, just like libc_nano.a would be. Here are the options:

Here is the config file itself.
Here is a stack overflow quiestion that helped me.

STM32F407 DMA early tests

2014-01-13T00:00:00+01:00

Research notes. Useful links:

Frank’s site (very valuable stuff) : part 1, part 2, and part 3 (part 3 covers then undocumented bug in µCs which Frank found).
Wikipedia article for complete beginners like me.
Reference manual
Code for this article

DMA is a peripheral that can copy data between other peripherals and memory or between memory and memory. It used to be implemented in form of separate IC in early days, but in modern µCs it is of course integrated inside the single chip.

STM32 DMA peripherals are able to copy data from memory to peripheral, from peripheral to memory and from memory to the other place in memory (for example from RAM to FLASH as StdPeriph example shows). There are two DMA controllers : DMA1 and DMA2 and both have 8 streams. I see a stream as a some kind of physical, bi-directional connection between the DMA controller and some other peripheral. Those 16 streams cover all (most?) peripherals meaning that one stream is connected to more than one peripheral. For example if one is about to send data using USART1 he has to use exactly DMA2_Stream7, or if he wants to receive data from SPI3_RX he has to use DMA1_Stream0 or DMA1_Stream2, because apparently SPI3_RX is connected to both of those streams (see table 43 and 44 in reference manual of STM32F407).

DMA works automatically meaning that if there is some new data it will be copied without user code (and CPU) involved. It is possible thanks to channels, which I imagine as signals (like GUI signals if you know what I mean) connected between DMA controller and the peripheral (there is also something called “arbiter” between them). Peripheral can send a request (signal) to the DMA if it has new data, and DMA can then process it. At the same time DMA acknowledges it has got this new portion of data, and peripheral releases the request. Each stream can “listen” to its 8 channels, so there are 2 controllers * 8 streams * 8 channels = 128 configuration combinations, and that way every peripheral can have its own communication path with the DMA.

Streams have configurable priorities in case two or more streams request DMA controller attention. If two or more streams have the same priority, then stream with lower number wins. The bit of hardware called “arbiter” manages those priorities and decides which stream goes first.

So here comes the first DMA test I wrote (tested on STM32F407-DISCOVERY). It writes to USART1:

#include <stm32f4xx.h>
#include "logf.h"

/**
 * For printf, and USART1 in general.
 */
void initUsart (void)
{
        RCC_APB2PeriphClockCmd (RCC_APB2Periph_USART1, ENABLE);
        GPIO_InitTypeDef gpioInitStruct;

        RCC_AHB1PeriphClockCmd (RCC_AHB1Periph_GPIOB, ENABLE);
        gpioInitStruct.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7;
        gpioInitStruct.GPIO_Mode = GPIO_Mode_AF;
        gpioInitStruct.GPIO_Speed = GPIO_High_Speed;
        gpioInitStruct.GPIO_OType = GPIO_OType_PP;
        gpioInitStruct.GPIO_PuPd = GPIO_PuPd_UP;
        GPIO_Init (GPIOB, &gpioInitStruct);
        GPIO_PinAFConfig (GPIOB, GPIO_PinSource6, GPIO_AF_USART1); // TX
        GPIO_PinAFConfig (GPIOB, GPIO_PinSource7, GPIO_AF_USART1); // RX

        USART_InitTypeDef usartInitStruct;
        usartInitStruct.USART_BaudRate = 9600;
        usartInitStruct.USART_WordLength = USART_WordLength_8b;
        usartInitStruct.USART_StopBits = USART_StopBits_1;
        usartInitStruct.USART_Parity = USART_Parity_No;
        usartInitStruct.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
        usartInitStruct.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
        USART_Init (USART1, &usartInitStruct);
        USART_Cmd (USART1, ENABLE);
}

uint8_t myStrlen (char const *s)
{
        uint8_t len = 0;

        while (*s++) {
                ++len;
        }

        return len;
}

/**
 * Test1
 */
void initDma (char const *outputBuffer)
{
        /*
         * Reset DMA Stream registers (for debug purpose). For DMA2_Stream7 exmplanation read on.
         * It also disables the stream. Stream must be disabled prior configure it. Otherwise it can
         * misbehave.
         */
        DMA_DeInit (DMA2_Stream7);

        /*
         * Check if the DMA Stream is disabled before enabling it.
         * Note that this step is useful when the same Stream is used multiple times:
         * enabled, then disabled then re-enabled... In this case, the DMA Stream disable
         * will be effective only at the end of the ongoing data transfer and it will
         * not be possible to re-configure it before making sure that the Enable bit
         * has been cleared by hardware. If the Stream is used only once, this step might
         * be bypassed.
         */
        while (DMA_GetCmdStatus (DMA2_Stream7) != DISABLE) {
        }

        /* Configure the DMA stream. */
        DMA_InitTypeDef  dmaInitStructure;

        /*
         * Possible values for DMA_Channel are DMA_Channel_[0..7]. Refer to table 44 in reference manual
         * mentioned earlier. USART1_RX is communicate with DMA via streams 2 and 5 (both on channel 4).
         * USART1_TX uses stream7 / channel 4.
         */
        dmaInitStructure.DMA_Channel = DMA_Channel_4;

        /*
         * Possible values : DMA_DIR_PeripheralToMemory, DMA_DIR_MemoryToPeripheral,
         * DMA_DIR_MemoryToMemory.
         */
        dmaInitStructure.DMA_DIR = DMA_DIR_MemoryToPeripheral;

        /* Why DMA_PeripheralBaseAddr is of type uint32_t? Shouldn't it be void *? */
        dmaInitStructure.DMA_PeripheralBaseAddr = (uint32_t)&(USART1->DR);
        dmaInitStructure.DMA_Memory0BaseAddr = (uint32_t)outputBuffer;

        /*
         * Only valid values here are : DMA_PeripheralDataSize_Byte, DMA_PeripheralDataSize_HalfWord,
         * DMA_PeripheralDataSize_Word
         */
        dmaInitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte;

        /*
         * I guess, that for memory is is always good to use DMA_MemoryDataSize_Word (32bits), since this is
         * a 32 bit micro. But haven't checked that. But here I use Byte instead for easier  DMA_BufferSize
         * calculations.
         */
        dmaInitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;

        /*
         * Length of the data to be transferred by the DMA. Unit of this length is DMA_MemoryDataSize when
         * direction is from memory to peripheral or DMA_PeripheralDataSize otherwise. Since I set both
         * sizes to one byte, I simply put strlen here.
         */
        dmaInitStructure.DMA_BufferSize = myStrlen (outputBuffer);

        /*
         * DMA_PeripheralInc_Disable means to read or to write to the same location everytime.
         * DMA_MemoryInc_Enable would increase memory or peripheral location after each read/write.
         */
        dmaInitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable;
        dmaInitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable;

        /* DMA_Mode_Normal or DMA_Mode_Circular here. */
        dmaInitStructure.DMA_Mode = DMA_Mode_Normal;

        /* DMA_Priority_Low, DMA_Priority_Medium, DMA_Priority_High or DMA_Priority_VeryHigh */
        dmaInitStructure.DMA_Priority = DMA_Priority_VeryHigh;

        /* DMA_FIFOMode_Disable means direst mode, DMA_FIFOMode_Enable means FIFO mode. FIFO is good. */
        dmaInitStructure.DMA_FIFOMode = DMA_FIFOMode_Disable;

        /*
         * DMA_FIFOThreshold_1QuarterFull, DMA_FIFOThreshold_HalfFull, DMA_FIFOThreshold_3QuartersFull or
         * DMA_FIFOThreshold_Full.
         */
        dmaInitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;

        /*
         * Specifies whether to use single or busrt mode. If burst, then it specifies how much "beats"
         * to use. DMA_MemoryBurst_Single, DMA_MemoryBurst_INC4, DMA_MemoryBurst_INC8 or
         * DMA_MemoryBurst_INC16.
         */
        dmaInitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
        dmaInitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_Single;

        /* Configure DMA, but still leave it turned off. */
        DMA_Init (DMA2_Stream7, &dmaInitStructure);

        /* DMA_FlowCtrl_Memory, DMA_FlowCtrl_Peripheral */
        DMA_FlowControllerConfig (DMA2_Stream7, DMA_FlowCtrl_Memory);

        /* Enable DMA interrupts. */
        DMA_ITConfig (DMA2_Stream7, DMA_IT_TC | DMA_IT_HT | DMA_IT_TE | DMA_IT_DME | DMA_IT_FE, ENABLE);

/*--------------------------------------------------------------------------*/

        /* Enable the DMA Stream. */
        DMA_Cmd (DMA2_Stream7, ENABLE);

        /*
         * And check if the DMA Stream has been effectively enabled.
         * The DMA Stream Enable bit is cleared immediately by hardware if there is an
         * error in the configuration parameters and the transfer is no started (ie. when
         * wrong FIFO threshold is configured ...)
         */
        uint16_t timeout = 10000;
        while ((DMA_GetCmdStatus (DMA2_Stream7) != ENABLE) && (timeout-- > 0)) {
        }

        /* Check if a timeout condition occurred */
        if (timeout == 0) {
                /* Manage the error: to simplify the code enter an infinite loop */
                while (1) {
                }
        }
}

int main (void)
{
        /* This would be a function parameter or something like that. */
        char *outputBufferA = "Ala ma kota, a kot ma ale, to jest taki wierszyk z czytanki dla dzieci, ktora jest tylko w Polsce.\r\n";
        char *outputBufferB = "Wlazl kotek na plotek i mruga. Ladna to piosenka nie dluga. Nie dluga, nie krotka lecz w sam raz.\r\n";

        /*
         * Enable the peripheral clock for DMA2. I want to use DMA with USART1, so according to
         * table 44 in reference manual for STM32F407 (RM0090) this would be DMA2 peripheral.
         * Description in stm32f4xx_dma.c advises to do this as the first operarion.
         */

        /*
         * Spend two fu.king nights on this. Docs says to use RCC_AHB1PeriphResetCmd, but use
         * RCC_AHB1PeriphClockCmd instead!!!
         */
//        RCC_AHB1PeriphResetCmd (RCC_AHB1Periph_DMA2, ENABLE);
        RCC_AHB1PeriphClockCmd (RCC_AHB1Periph_DMA2, ENABLE);

/*--------------------------------------------------------------------------*/

        /*
         * Enable the USART1 device as usual.
         */
        initUsart ();
        logf("Init\r\n");

/*--------------------------------------------------------------------------*/

        initDma (outputBufferA);

        /*
         * The DMA stream is turned on now and waits for DMA requests. As far as I know, if this
         * were to be memory-to-memory transfer, it would start immedialtely without enabling any
         * channels. But for peripherals one has to enable the channel for requests. After following
         * statement, you should see data on serial console.
         *
         * This statement enables the DMA internals in USART (this stuff which communicates with the DMA
         * controller).
         */
        USART_DMACmd (USART1, USART_DMAReq_Tx, ENABLE);

        /* Waiting the end of Data transfer */
        while (USART_GetFlagStatus (USART1, USART_FLAG_TC) == RESET)
                ;

        while (DMA_GetFlagStatus (DMA2_Stream7, DMA_FLAG_TCIF7) == RESET)
                ;

        logf("It worked, and didn't hanged\r\n");

        /* Clear DMA Transfer Complete Flags */
        DMA_ClearFlag (DMA2_Stream7, DMA_FLAG_TCIF7);

        /* Th has to be initialized once again AFAIK to send another portion of data. */
        initDma (outputBufferB);

        /* Try to start it again */
        USART_DMACmd (USART1, USART_DMAReq_Tx, ENABLE);

        /* Waiting the end of Data transfer */
        while (USART_GetFlagStatus (USART1, USART_FLAG_TC) == RESET)
                ;

        logf("It workedagain\r\n");

        /* Infinite loop */
        while (1) {
        }
}

STM32F407-DISCOVERY SDIO tests.

2014-01-10T00:00:00+01:00

Started a new project (includes StdPeriph 1.3.0). Repository can be found here.
First commit makes it simply output a “Init” text on the debug console (i.e. on USART1).
Browsing StdPeriph. Seems that stm32f4xx_sdio.[ch] are very low level (I’ve read SD card spec version 2.0).
Higher level stuff seems to be in StdPeriph here:
Utilities/STM32_EVAL/STM324x7I_EVAL
Utilities/STM32_EVAL/STM3240_41_G_EVAL
Utilities/STM32_EVAL/STM324x9I_EVAL

But I don’t know why there is one version per dev-board. Looks like bad design to me at a first glance. Differences between those 3 files:

Lines 517/519 : Card presence is detected by different means (different pins are used on these boards). As far as I remember card presence detection is an optional feature, so maybe even it is not part of the standard. That would explain why different pins are used on the boards (I expect, that standard pins are laid out the same on …?).
Lines 1570/1572 different parameter passed to SDIO_ITConfig in function SD_WriteMultiBlocks. One dev-board uses SDIO_IT_RXOVERR and the other two use SDIO_IT_TXUNDERR (among others, this is a bitmask).
Copied STM324x9I_EVAL sdio routines to my source tree.
Included code from the SDIO example : Project/STM32F4xx_StdPeriph_Examples/SDIO/SDIO_uSDCard. Serial console went crazy and shows some gibberish, so I can’t see my debug messages, but card previously filled with random data now shows :

root@diora:~# hexdump -n 128 /dev/sdc 
0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000010 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
0000020 2120 2322 2524 2726 2928 2b2a 2d2c 2f2e
0000030 3130 3332 3534 3736 3938 3b3a 3d3c 3f3e
0000040 4140 4342 4544 4746 4948 4b4a 4d4c 4f4e
0000050 5150 5352 5554 5756 5958 5b5a 5d5c 5f5e
0000060 6160 6362 6564 6766 6968 6b6a 6d6c 6f6e
0000070 7170 7372 7574 7776 7978 7b7a 7d7c 7f7e
0000080

Looks less random to me.

I had problems with serial console attached to USART1 after upgrading StdPeriph from 1.1.0 to 1.3.0. Console would speak Chinese from now on, and logic analyzer shows “framing errors” when attached to the TX pin. There were two problems: in 1.1.0 in file stm32f4xx.h default HSE_VALUE definition was 8MHz. In 1.3.0 ST increased this to 25MHz. In addition in stm32f4xx_conf.h I had HSE_VALUE redefined, but later on I upgraded this file (got it from some example projest from StdPeriph from 1.3.0 version), and it lacked this re-definition. Thus µC thought it is running on 25MHz which in turn disrupted the transmission. This re-definition looks as follows:

#if defined  (HSE_VALUE)
/* Redefine the HSE value; it's equal to 8 MHz on the STM32F4-DISCOVERY Kit */
 #undef HSE_VALUE
 #define HSE_VALUE    ((uint32_t)8000000) 
#endif /* HSE_VALUE */

I am facing a similar problem to this. Program hangs after returning from interrupt routine(?) In fact I don’t really know what is happening… Program hangs in SD_WaitReadOperation after successfully returning from SD_ReadMultiBlocks. It idles in loop (or at first glance it looks like it is iterating the loop forever) which looks like this:

while ((DMAEndOfTransfer == 0x00) && (TransferEnd == 0) && (TransferError == SD_OK) && (timeout > 0)) {
    timeout--;
}

Normally after successful transfer either DMAEndOfTransfer or TransferEnd would turn 1, but seemingly none of this happened. The only place the TransferEnd is set is SDIO_IRQHandler, so I added logs to check if µC hits this routine. It does, and it even set TransferEnd to 1, but it never returns from it. Debugger says, that program hangs in some strange places like WWDG_IRQHandler.

The problem was caused by missing DMA handler routine, namely the DMA2_Stream3_IRQHandler. I made two mistakes. First, I assumed, that since I run the demo with SD_DMA_MODE turned off (undefined), and SD_POLLING_MODE turned on (#defined), the DMA routines are unnecessary. This is not the case, those handlers are required in either cases (that’s the way SDIO example is made). So I copied DMA_IRQ handler from the example, where its name was hidden behind the SD_SDIO_DMA_IRQHANDLER macro (but at that point I didn’t know this is a macro, and thought that this is a regular function name). So secondly, SD_SDIO_DMA_IRQHANDLER was undefined in my stm32fxxx_it.c, It simply was not visible in this translation unit, and I ended up with function named SD_SDIO_DMA_IRQHANDLER, but without proper DMA IRQ handler. So µC jumped to the default handler which had infinite loop in it, but for some reason GDB showed the other handler.

Here I made a tag of the code with first version that actually worked.
And here is regular repository of the project, I will be improving this for some time now.
http://blog.frankvh.com/2011/09/04/stm32f2xx-sdio-sd-card-interface/ - great post on the topic.

A chaotic post on HID keyboard. STM32F407 success, STM32F105 fail

2014-01-05T00:00:00+01:00

This is a quick dev-log post on my latest design, which was only partially successful. I have STM32F407-DISCOVERY board on which I successfully implemented a HID keyboard with only one keyboard. At first it reported that ‘a’ key was pressed every time user pressed the blue button, then, according to my plan I changed this to play/pause button, which can turn music on and of. It works under Linux and Windows (only ‘a’ version tested under win though). Then I decided to make a board for this and, since F407 is quite expensive, in fact too expensive for simple one-key keyboard, I decided to use something simpler. The slowest and cheapest µcros that support STM32_USB-Host-Device_Lib are those labeled as “connectivity line” i.e. STM32F105 and STM32F107. I’ve got myself two STM32F105R8T6 and made a board, which fits into a case I also bought. The case is labeled as “XB2-ES542” :

Eagle schematic and board are here, OSH Park shared projest is here. I assumed (incorrectly) that porting my program from F407 dev board to my custom board featuring different micro will be easy since they are quite similar. I was wrong. And I don’t have a dev board for F105 nor 107. Ok, but first things first. As I mentioned, program works on F407, so let me write down some random thoughts which emerged during the process of making this work:

Few facts about HID devices (that I learned)

All data exchanged resides in structures called reports. The host sends and receives data by sending and requesting reports in control or interrupt transfers. The report format is flexible and can handle just about any type of data, but each defined report has a fixed size. The device’s descriptors must include an interface descriptor that specifies the HID class, a HID descriptor, and an interrupt IN endpoint descriptor. The firmware must also contain a report descriptor that contains information about the contents of a HID’s reports.

So there are two additional descriptors when comparing to the ‘vendor specific’ device I made recently (there may be third, optional descriptor as well). First is HID class device descriptor and it specifies which other class descriptors are present (for example report descriptors or physical descriptors).

A HID can support one or more reports. The report descriptor specifies the size and contents of the data which this device generates. Physical descriptors at the other hand are optional pieces of data which describe the part(s) of human body used to operate the HID device. The HID class does not use subclasses to define most protocols. Instead, a HID class device identifies its data protocol and the type of data provided within its Report descriptor.

Here on page 53 you can find all key codes defined by the HID spec. Document “Device Class Definition for Human Interface Devices (HID) Version 1.11” on page 62 has very useful information regarding keyboard implementation. Especially crucial are those bits about when to send a data report: “The keyboard must send data reports at the Idle rate or when receiving a Get_Report request, even when there are no new key events.” I mixed up the rates and my HID keyboard acted unpredictable. Only after adjusting wait period for 4ms * idle rate things went OK.

Then I started to getting familiar with the report descriptors, but nah, the more I read HID specification the more I realized this is too much complexity, and too much effort than I wanted to put into this project. At first I was like, “OK let’s read the whole spec, it has 97 pages, I’ve read longer specs before, not a problem”. But hey, this was meant to be a simple, few evenings project, and this HID spec turned out to be surprisingly complex (I mean report descriptors in particular. When I came to Push and Pop items I refused to read further). The better and simpler way of accomplishing this project was to grab some descriptors from the net, and so I did:

Here I found usefulreport descriptor for regular keyboards (like qwerty ones). Other, special buttons are implemented by other means (other items in reports) as I noticed before.
Here are some interestingreport descriptors which looks like something I want to do (multimedia control). Seems to me, that all those volume, play/pause and other knobs are implenmented in some other means that regular keyboards are. There are different type of “usage” used i.e. regular keyboard has 0x09 0x06 (USAGE (Keyboard)), but in above document there is 0x09 0x01 (Usage (Consumer Control)) used.

There is also a tool on USB-IF page, which helps to assembly HID report descriptors, and I can confirm that it runs on Wine, but that is all I can say about it. I suppose you still have to know the specs, and know what you are doing while using this thing. Last but not least the source code which runs flawlessly on STM32F407-DISCO:

The source code for this project (works OK on STM32F407).

Failed attempt to port it to STM32F105

Then I started to move to my custom board depicted above, which I didn’t managed to accomplish. Actual status of the whole device (source code linked below, Eagle files above) is that, after connecting the USB, device initializes itself (i.e. USB stack gets initialized) then it gets quite a few reset requests (like 10) and then it hangs. Wireshark + usbmon shows “Malformed packet” when device tries to send the Device descriptor to host. Random notes from development:

Note : STM32F105 and 107 are called “connectivity line microprocessors”. It is useful to know that since there are many resources for STM32F1x out there which are tagged like “value line”, “connectivity line” etc.
I copied my previous project stm32f407-drama-button into new place in my SVN repository : stm32f105-drama-button.
I downloaded and unpacked STM32F10x_StdPeriph_Lib_V3.5.0 library from here. Main page for this micro is here. Current version of standard peripheral library for STM32F10x as of writing this is 3.5.0.
I replaced /STM32F4xx_StdPeriph_Driver with /STM32F10x_StdPeriph_Driver.
Replaced CMSIS folder. Removed Docs folder.
Made new toolchain with crosstool-ng fine tuned for Cortex-M3 µC.
Copied and modified stm32f105-crosstool.cmake.
StdPeriph comes with ld-scripts for various dev-boards. I figuret out that :
- STM3210B-EVAL has STM32F103VBT6 µC.
- STM3210C-EVAL has STM32F107VCT µC.
- STM3210E-EVAL has STM32F103ZGT6 µC.
So linker script for STM3210C-EVAL is best suited for me and will check it first. Have it copied and modified. In “drama button” project I use STM32F105R8T6 which has:
- 64kB of flash,
- 64kB of RAM
I copied stm32f10x_conf.h from examples into src. CMSIS uses it somehow and I think this is bad design. Lower level library depends on higher level header file?
Had trouble when used GCC-4.8.0 (linaro version made with ct-ng 1.19). Works fine with GCC-4.7.0 (linaro version prepared with ct-ng 1.18). Some strange assembler errors when compiling core_cm3.c file poped out. Here a guy in comments had similar issue, and someone told him to download fresh CMSIS library, because this provided with StdPeriph is old. I can believe that, because for example ST USB OTG library comes with StdPeriph bundled inside and it is also some old version. So my rule of thumb now is to collect newest versions of all the individual libraries, even when they are distributed together (i.e. OTG library virtually has everything required to compile the examples it provides, but now I throw it away and get fresh ones).

EDIT : when compiling with gcc-4.7.0 with heavy optimizations (-O3) the same assembler error emerges. Message is

/tmp/ccOfylWN.s: Assembler messages:
/tmp/ccOfylWN.s:646: Error: registers may not be the same -- `strexb r0,r0,[r1]'
/tmp/ccOfylWN.s:675: Error: registers may not be the same -- `strexh r0,r0,[r1]'

I downloaded and upgraded CMSIS from here : https://silver.arm.com/browse/CMSIS# (registration required). Upgraded from version 1.3.0 to 3.2.0. No *.c file this time, only header files.

When ported from STM32F407-DISCO to my custom STM32F105 board, program refused to operate. Kernel log says that:

Jan  3 00:08:09 diora kernel: [ 4993.895502] usb 7-2: new full-speed USB device number 4 using uhci_hcd
Jan  3 00:08:09 diora kernel: [ 4993.959542] hub 7-0:1.0: unable to enumerate USB device on port 2

And oscilloscope says, that… well… seems OK to me (compared for example to Wikipedia article on USB) :)

Debugger shows that program is running, It correctly invoke Reset_Handler, and then hits the main function.

Mistakes that I know I made:

I made a circuit with µC that I don’t have development board for (Assumed, that porting tested program from STMF407 to STMF105 will be easy. Wrong).
I screwed up a SWD port. Issues with signal integrity (probably due to lack of termination resistors?). This made debugging with GDB harder. It would hang, or disconnect at random points.
I forgot to add serial console output for STDOUT. Terrible mistake. I’ve wired that up, but board looks messy now.
Simple delay functions was dependent on optimization switches. And then, after about 10 evenings / nights I gave up and put this project on the shelf for some time.

Motorcycle black box. A quick update.

2013-06-30T00:00:00+02:00

Just a quick update for those who are interested if this project is still alive. It is. Above you can find an early test video from the application which runs on a PC and does post processing of the data collected by raspberry pi. More details to come in next post. All source code for this project is here (work in progress). First post here.

Motorcycle black box part 1. Data acquisition with Arduino Mega.

2013-06-02T00:00:00+02:00

The objective

Make a black box, a device which would record short clips from camera in loop overwriting oldest clips. That would produce constant stream of short movies which put together would make one long recording containing last 30minutes (or more - depending on storage capacity) of my riding. Among with the recording, telemetric data would be collected such as velocity, RPM, temperature, front and rear brake pressed, depressed, and turn signals, and maybe more. Then this data could be put on the video in overlay.

The motorcycle

Yamaha XJ6SA 2010.

Identify by what means communication between the ECU and the dashboard is performed.

Which cables are used and what is the protocol used? After inspecting the service manual for my bike I was able to eliminate wires which are used for other things (see picture), and I left with only one, which is connecting the dash, the ECU and the immobilizer. Other ones was for flashing some warning LEDs, gathering information from fuel pump, oil switch and so on. So the yellow-blue wire was my first guess and it was correct. On the ecuhacking forum, which was source of very helpful information, guys was talking about something called K-line. I believe it is something widely common in the automotive industry, and for certain it has bunch of ISO standards describing it, but hey, if this is only one wire, and data flowing inside is some kind of serial communication, I bet I could sniff it, and figure out without any standards, which are hard to find and get (there is so much of them, I’ve got confused after few minutes of googling).

Figure out how to interface this, make some circuit if needed.

Again on the ecuhacing forum I’ve found information that K-line has logic levels relative to 12V, where 0V is logic 0, and 12V logic 1. There has to be some voltage level converter if I want to connect some TTL stuff to it. On the forum some guys were using a L9637 chip which is described as “ISO 9141 INTERFACE” by its datasheet. So I bought a few of these and connected it as follows :

Later on I removed the 510 ohm pull up resistor, because after turning engine on there was error showing of on the dash. I guessed that could be this resistor, and it helped. Dunno what was wrong.

Most difficult part for me was to find a place in motorcycle’s wiring to connect to. After some time I managed to insert piece of rigid wire to the back side of ECU connector as depicted below:

5V supply voltage I was drawing from step down voltage converter which I bought on the Internets. It is a PCB with a few discrete parts and quite huge radiator with some coils inside. There is [EDIT] label on it. To the output of L9637 I connected a Saleae logic analyzer, which I also bought. It is quite cheap and has good software for Windows, Linux and MAC OS. I can definitely recommend it, especially if you want to use it with Linux (I use Ubuntu).

Sniff the data, and collect it for further investigation.

My circuit worked the first time. After turning ignition to the ON state this is what I got:

Sealae app, among others, has a “Async serial” analyzer which I used with default configuration, and “use autobaud” checkbox checked. This useful option corrected initial 9600 baud to whatever it thought to be appropriate, and showed 16064 baud. Pretty odd value isn’t it? None the less it is very useful information if I want to read the data with some AVR, or something like that. It turns out, that data comes in packets which are 6B long. First byte is some kind of command, and the rest is the reply i.e the dashboard issues command 0x01 ant then ECU replies with 5 bytes of data. From the ecuhacking I knew that forst byte of the reply would be the RPM, second probably velocity, third an error code, fourth would be engine temperature (that is coolant or oil temperature?) and the very last is the checksum.

Collect the data in some more useful format.

Although Sealae has an option to store the analyzer’s data in CSV, sooner or later I would have to make some custom electronics anyway. Yet I want to make self contained logger hidden in neat case somewhere in the bike. I want to use a Raspberry PI i own as the main component of the gizmo, but after reading about serial communication with the Pi, I gave up for that time, and connected Arduino Mega. The main problem with PI is that I don’t know how to set it up for so unusual baud rate as 16064 baud (or 15625 as someone suggested). I had limited time, so for now I chose the Arduino. Below the code I uploaded :

#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX

void setup() {
    // initialize both serial ports:
    Serial.begin(115200);

    // set the data rate for the SoftwareSerial port
    mySerial.begin(16064);
}

void loop() {
    static int count = 0;

    // read from port 1, send to port 0:
    if (mySerial.available()) {
        int inByte = mySerial.read();

        if (inByte == 0x01 && count >= 5) {
            Serial.println(' ');
            count = 0;
        }

        Serial.print(inByte, HEX);
        Serial.print (' ');
        ++count;
    }
}

As you can see, RX is set up for pin 10, so the only thing I did was to disconnect the logic analyzer, and connect Arduino pin 10 instead. But nothing happened. This was because the SoftSerial library have a few baud rates predefined, namely the most usual ones. The solution was to modify arduino-1.0.5/libraries/SoftwareSerial/SoftwareSerial.cpp so it looks like that:

// .... line 59
static const DELAY_TABLE PROGMEM table[] =
{
    // baud rxcenter rxintra rxstop tx
    { 115200, 1, 17, 17, 12, },
    { 57600, 10, 37, 37, 33, },
    { 38400, 25, 57, 57, 54, },
    { 31250, 31, 70, 70, 68, },
    { 28800, 34, 77, 77, 74, },
    { 19200, 54, 117, 117, 114, },
    { 16064, 66, 140, 140, 137, }, // added baud rate
    { 15625, 68, 144, 144, 141, }, // added baud rate 2
    { 14400, 74, 156, 156, 153, },
    { 9600, 114, 236, 236, 233, },
    { 4800, 233, 474, 474, 471, },
    { 2400, 471, 950, 950, 947, },
    { 1200, 947, 1902, 1902, 1899, },
    { 600, 1902, 3804, 3804, 3800, },
    { 300, 3804, 7617, 7617, 7614, },
};
// ....

Here is the link you should follow for more info. I haven’t figured it out by myself. After this modification Arduino happily sent me my precious data, which I observed in serial monitor.

This is the data I collected so far (motorcycle standing on central stand, back wheel revolving, velocity comes from the back wheel, ABS LED blinking).

Ignition ON, engine stopped.

0 0 0 30 30
0 0 0 30 30
0 0 0 30 30
0 0 0 30 30
...

Ignition ON, engine started, no throttle (~1200 RPM), no gear (N) i.e. wheel not revolving, cold engine:

24 0 0 30 54
24 0 0 30 54
24 0 0 30 54
24 0 0 30 54
...

Ignition ON, engine started, little throttle (more RPM), no gear (N) i.e. wheel not revolving, cold engine:

34 0 0 53 87
34 0 0 53 87
34 0 0 53 87
34 0 0 53 87
...

1st gear, no throttle (engine warmed up thus less RPM). About 10 km/h

17 0 0 5C 73
17 1 0 5C 74
17 1 0 5C 74
17 0 0 5C 73
17 1 0 5C 74
18 1 0 60 79
18 1 0 60 79
18 0 0 60 78
18 1 0 60 79
17 1 0 60 78
17 0 0 60 77
17 1 0 60 78
17 1 0 60 78
17 0 0 60 77
17 1 0 60 78
17 1 0 60 78
17 0 0 60 77
18 1 0 60 79
18 1 0 60 79
18 1 0 60 79
18 0 0 60 78
18 1 0 60 79
18 1 0 60 79
18 0 0 60 78
18 1 0 60 79
18 1 0 60 79
17 0 0 60 77

23 km/h (6th gear)

17 2 0 68 81
17 2 0 69 82
17 2 0 69 82
17 2 0 69 82
17 1 0 69 81
17 2 0 68 81
17 2 0 68 81
17 2 0 68 81
17 2 0 68 81
17 1 0 68 80
17 2 0 69 82
17 2 0 68 81
17 2 0 68 81
17 1 0 68 80
17 2 0 68 81

40 km/h

2B 4 0 70 9F
2B 3 0 70 9E
2B 3 0 72 A0
2B 3 0 72 A0
2B 4 0 72 A1
2B 3 0 72 A0
2C 3 0 72 A1
2C 4 0 72 A2
2C 3 0 72 A1
2C 3 0 72 A1
2C 4 0 72 A2
2C 3 0 72 A1
2C 3 0 72 A1
2C 4 0 72 A2
2C 3 0 72 A1
2C 4 0 72 A2
2C 3 0 72 A1
2C 3 0 72 A1

60 km/h

40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
41 4 0 74 B9
41 6 0 74 BB
41 4 0 74 B9
40 5 0 74 B9
40 5 0 74 B9
41 5 0 74 BA
40 5 0 74 B9
40 5 0 74 B9

80 km/h

56 7 0 77 D4
55 6 0 77 D2
56 7 0 77 D4
55 6 0 77 D2
56 7 0 77 D4
56 6 0 77 D3
56 7 0 77 D4
56 6 0 77 D3
56 7 0 77 D4
56 6 0 77 D3
56 7 0 77 D4
56 7 0 77 D4
56 6 0 77 D3
56 7 0 77 D4
56 7 0 77 D4
56 6 0 77 D3

Future

Due to uncertainty about Raspberry PI serial communication I plan to make custom PCB with AVR in form of shield to Raspberry Pi. It will have two purposes. First it will acquire the data in some similar manner as depicted above, and will pass it to Pi by I2C or SPI (probably with velocity in some more usable form), among with some other data such as brakes and turn-lights, an maybe even outdoor temperature (I always wanted to have this information, especially in spring and autumn). And secondly it will drive some relay to cut the power to Pi which draws 2W of power even when shut down. Of course it also should send some signal first to Raspberry to shut it down correctly. If someone know something more about Pi’s UART and custom baud rates in particular, please let me know. Maybe there is a way to read K-line directly without AVR.