Category: programming

Posted on

Epoll tutorial and understanding the overlooked epoll_data_t

Epoll is a mechanism of Linux Kernel / Linux C runtime to monitor multiple file descriptors for I/O. Lets say you have a server program which has open connections as file descriptors. Epoll mechanism offers more performant “watching” of all these file descriptors for activity compared to some other options, like select(). Some tutorials about epoll exist on the internet, but many fail to acknowledge WHY what is happening is actually happening. So allow me to walk you through with this small example program utilizing epoll.

Continue reading “Epoll tutorial and understanding the overlooked epoll_data_t”

Posted on

Portable Position-Independent Code (PIC) bootloader and firmware for ARM Cortex-M0 and Cortex-M4

How to implement Position-Independent Code for microcontroller (MCUs) is a question which has been asked countless and countless of times all over the Internet. The answers and “solutions” are usually whippersnappering comments dropping a couple of key terms they probably just googled up without any kind of intrinsic knowledge about how the system should be working.

Sometimes the answer is “OK I got it working” followed by eternal silence from people asking clarifications. In other words, it looks like the task is very difficult and once people get it to work, it is so valuable they want to hide the details. In a way I cannot blame them much; it took me 6 months of half-time work every now and then to understand everything.

So, some 6 months ago I set myself a goal: “Create a portable solution where an intelligent bootloader can boot firmware images from any address in flash on Cortex-M0 or Cortex-M4 platform.” Finally, as of today 2022-01-16, I consider I have solved the problem in an intelligent and understandable way.

Funnily, I think I am the only person on planet Earth who has made available readily working example code and documented the code in a way I am doing now in this post.

Those impatient can explore the fully working STM32CubeIde codes at GitHub, for Cortex-M0: https://github.com/usvi/F070RB-BL-FW  and for Cortex-M4: https://github.com/usvi/L432KC-BL-FW  . (One might ask why one would use this kind of bloated stock configuration for developing on MCUs. Believe me, I’m doing it here only for pedagogical reasons. This way it is easier for noobs having the needed evaluation boards to verify that the code is working.)

The set of code I have created is a proof-of-concept, working for the C language. There might, and I underline, might be unforeseen problems when amount of global variable gets absurdly high. In any case, comments and criticism is more than welcome.

If you are ready to dive into the deep end of Cortex-M boot process, PIC constructs, esoteric debugging and linker script optimizations, continue reading…

Continue reading “Portable Position-Independent Code (PIC) bootloader and firmware for ARM Cortex-M0 and Cortex-M4”

Posted on

Primer and use case of Position-Independent Code in ARM Cortex-M MCU environment

Recently I described my friend that I was working with Position-Independent Code on a Cortex-M0 and Cortex-M4 environment. To my surprise, he was more interested about “why” and not “how”. I think before revealing the nitty-gritty details of this domain, I can give readers an overview about things.

Continue reading “Primer and use case of Position-Independent Code in ARM Cortex-M MCU environment”

Posted on

Firmware interrupt vector table relocation by bootloader considered harmful

I have developed in the past month or so a way to have position-independent-code (PIC) firmware image (on ARM Cortex-M0 and Cortex-M4) which can be put (almost) anywhere in flash. I’m still refining the concept and will write an in-depth-article about it. There is a part of the PIC stuff that I can discuss briefly to get us going about THIS article.

Part of the PIC firmware + bootloader has been interrupt vector table relocation. Basically the bootloader needs to read from flash the firmware vector table and copy it to RAM and then point the MCU to use the vector table from RAM. Some of tutorials, videos and comments suggest that bootloader should do the relocation. I have, however, come to the conclusion that this is actually wrong way to proceed. I will try to demonstrate now why.

Continue reading “Firmware interrupt vector table relocation by bootloader considered harmful”

Posted on

Dynamically generated MCU binary image header (Arm Cortex-M4)

Every seasoned embedded systems engineer faces at some point of their career a problem about needing to put a header to their built firmware image binaries. This header usually contains at least information about what device the image is for and what version number the image is. Checksums are also common.

There are multiple ways of implementing the header. One solution is to just glue it on top of the image and peel it off while updating the firmware via IAP or external programmer means.

Another approach is to place it actually in firmware flash, to a known location, possibly even start of the image, but use a bootloader to jump past the header.

There is however yet another solution I’m going to demonstrate. It is about generating the header template directly into the flash image, and even surprisingly in a way that the MCU can start executing actually from the beginning of the header (template). An external tool is used later to fill in checksum data.

But before continuing, heres a big fat warning:

WE ARE MANIPULATING VECTOR TABLE OFFSETS WHICH IS CONSIDERED DANGEROUS PRACTICE REGARDING ULTIMATE RELIABILITY OF THE RUNNING CODE. YOU HAVE BEEN WARNED.

There. Now lets go on.

We will be working on our trusty old STM32 Nucleo-L432KC and STM32CubeIDE. Example codes are available at https://github.com/usvi/L432KC-dynamic-header .

Continue reading “Dynamically generated MCU binary image header (Arm Cortex-M4)”

Posted on

Properly offsetting relocated (Arm Cortex-M4) code in STM32CubeIDE GDB

In my previous post I was showing a very elementary but outright inefficient way to debug tricky (Arm Cortex-M4) code which was relocated. The full case was/is: There is a bootloader which loads actual firmware binary. Bootloader is at 0x8000000, firmware at 0x8005000. We used a method to load debug values to registers we were monitoring. It worked but was complex and did not address the root cause of mismatched symbols. There is however a way to make the relocated firmware binary to correspond 100% to the debug symbols and debugger screen. Read below to know more.

Continue reading “Properly offsetting relocated (Arm Cortex-M4) code in STM32CubeIDE GDB”

Posted on

Debugging tricky (Arm Cortex-M4) code with register values

Sometimes you may run into problems when debugging tricky code. This is the case especially with microcontroller code if you are implementing a bootloader+firmware image solution. Debugger started in bootloader goes haywire and displays garbage or nothing at all when jumping to firmware.

Normally one should invest some time in getting debugger symbols aligned properly with source code, but if there are for example some barring deficiencies in environment or debugger UI, one can still figure out a bit more what is going on by using spare register values. Following shows a somewhat obvious, but still possibly helpful technique in brief for aforementioned debugging situations.

UPDATE 2021-08-16:
To get the job actually done, see my follow-up post

But in any case, the rest of the earlier post is here for posterity.

Continue reading “Debugging tricky (Arm Cortex-M4) code with register values”

Posted on

LEGACY Crash Course in Debugging C Programs with Emacs GDB (annotate=3)

I have a constant need to debug specific C programs. Because I have mostly worked in constrained embedded systems Linux environments, in reality I have not had possibility to have a debugger available. So I never learned GDB. But recently I was able to compile the application binaries in a regular 32-bit Linux environment. I was finally able to do debugging with Emacs GDB after learning just one day. This crash course will probably help you if you want to learn GDB debugging with text mode Emacs. We will be using the gdb-many-windows variant layout.

Continue reading “LEGACY Crash Course in Debugging C Programs with Emacs GDB (annotate=3)”

Posted on

Reverse-Engineering The Samsung SCX-3205 Scan To -Button Protocol

USB packet analysis in USBlyzer

In the year 2014, I tried to be smart with my old Samsung SCX-3205 printer/scanner device. I wanted to get the physical Scan to -button to work. I went with Windows first. It failed eventually, and as a result, I had to reverse-engineer the Samsung USB protocol to get things to work in Linux. Continue reading “Reverse-Engineering The Samsung SCX-3205 Scan To -Button Protocol”