For the last couple of days I\u2019ve been battling with my custom embedded operating system \u2014 MicrOS<\/strong> (slogan: \u201csimple, open, embedded\u201d<\/em>). The goal was straightforward: get a bare-metal \u201cHello, world\u201d sample running under emulation, before moving to real hardware. The journey turned out to be more educational than I expected.<\/p>\n\n\n\n My first target was the familiar STM32VLDiscovery<\/strong> board. The linker defined the memory regions:<\/p>\n\n\n\n and the startup provided the vector table:<\/p>\n\n\n\n Everything looked fine\u2026 until I tried to run it:<\/p>\n\n\n\n QEMU answered:<\/p>\n\n\n\n \ud83d\udca5 A hard crash, every time.<\/p>\n\n\n\n I assumed it was my fault (it usually is \ud83d\ude05). Output:<\/p>\n\n\n\n This revealed the first bug: After fixing the linker script with:<\/p>\n\n\n\n the symbols looked healthy: But the crash persisted.<\/p>\n\n\n\n The culprit wasn\u2019t my code after all \u2014 it was QEMU\u2019s STM32 emulation<\/strong>.<\/p>\n\n\n\n The Instead of fighting STM32 emulation, I tried another board:<\/p>\n\n\n\n And\u2026 success! \ud83c\udf89<\/p>\n\n\n\n MicrOS booted cleanly, initialized To confirm, I inspected the vector table:<\/p>\n\n\n\n Output:<\/p>\n\n\n\n Decoded as:<\/p>\n\n\n\n The system was now booting properly<\/strong> in QEMU.<\/p>\n\n\n\n This milestone marks the first time MicrOS<\/strong> boots and runs on real (emulated) silicon.<\/p>\n\n\n\n It\u2019s a small step, but a foundational one \u2014 proving the toolchain, linker, and startup are working correctly.<\/p>\n\n\n\n The next blog post will hopefully show a clean For the last couple of days I\u2019ve been battling with my custom embedded operating system \u2014 MicrOS (slogan: \u201csimple, open, embedded\u201d). The goal was straightforward: get a bare-metal \u201cHello, world\u201d sample running under emulation, before moving to real hardware. The journey turned out to be more educational than I expected. The challenge My first target […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-81","post","type-post","status-publish","format-standard","hentry","category-development"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/81","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/comments?post=81"}],"version-history":[{"count":1,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/81\/revisions"}],"predecessor-version":[{"id":82,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/posts\/81\/revisions\/82"}],"wp:attachment":[{"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/media?parent=81"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/categories?post=81"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/microsproject.dev\/index.php\/wp-json\/wp\/v2\/tags?post=81"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nThe challenge<\/h2>\n\n\n\n
I wrote a minimal linker script<\/strong> and a startup file<\/strong> in C that set up the stack, copied .data<\/code>, zeroed .bss<\/code>, and jumped into main()<\/code>.<\/p>\n\n\n\nMEMORY {\n FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K\n RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K\n}\n<\/code><\/pre>\n\n\n\n__attribute__((section(\".isr_vector\")))\nconst void *vector_table[] = {\n (void *)&__stack_top__, \/\/ initial SP\n Reset_Handler, \/\/ entry point\n NMI_Handler,\n HardFault_Handler,\n \/\/ ...\n};\n<\/code><\/pre>\n\n\n\nqemu-system-arm -M stm32vldiscovery -nographic -serial mon:stdio \\\n -kernel build\/samples\/hello_world\/hello_world\n<\/code><\/pre>\n\n\n\nqemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)\n<\/code><\/pre>\n\n\n\n
\n\n\n\nThe investigation<\/h2>\n\n\n\n
I checked the ELF with nm<\/code> and objdump<\/code>:<\/p>\n\n\n\narm-none-eabi-nm hello_world | grep __data\n<\/code><\/pre>\n\n\n\n20000000 D __data_start__\n20000060 D __data_end__\n08001ad8 A __data_load__\n<\/code><\/pre>\n\n\n\n__data_load__<\/code> overlapped with .text<\/code>, so my Reset_Handler<\/code> was copying instructions<\/em> as if they were data \u2014 instant fault!<\/p>\n\n\n\n.data : {\n __data_start__ = .;\n *(.data*)\n __data_end__ = .;\n} > RAM AT > FLASH\n\n__data_load__ = LOADADDR(.data);\n<\/code><\/pre>\n\n\n\n.data<\/code> in RAM, .data_load__<\/code> in FLASH.<\/p>\n\n\n\n
\n\n\n\nThe discovery<\/h2>\n\n\n\n
stm32vldiscovery<\/code> machine in QEMU is only partially implemented. Touching even basic RCC or FLASH registers triggers faults that can\u2019t be recovered. That explained the mysterious HardFault loop.<\/p>\n\n\n\n
\n\n\n\nThe breakthrough<\/h2>\n\n\n\n
qemu-system-arm -M lm3s6965evb -nographic \\\n -kernel build\/samples\/hello_world\/hello_world\n<\/code><\/pre>\n\n\n\n.bss<\/code> and .data<\/code>, and reached main()<\/code> without crashing.<\/p>\n\n\n\narm-none-eabi-objdump -s -j .isr_vector hello_world | head\n<\/code><\/pre>\n\n\n\n08000000 a8310020 c5010008 bd010008 ...\n<\/code><\/pre>\n\n\n\n\n
0x200031a8<\/code> \u2192 initial SP (in SRAM \u2705)<\/li>\n\n\n\n0x080001c5<\/code> \u2192 Reset_Handler (in FLASH \u2705)<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nWhat this means for MicrOS<\/h2>\n\n\n\n
\n
\n\n\n\nStep-by-step: reproduce this yourself \ud83d\udee0\ufe0f<\/h2>\n\n\n\n
\n
rm -rf build\/ cmake -S . -B build\/ -DMICROS_BOARD=lm\/lm3s6965evb -DMICROS_SAMPLE=hello_world cmake --build build\/<\/code><\/li>\n\n\n\narm-none-eabi-size build\/samples\/hello_world\/hello_world<\/code> Example output: text data bss dec hex filename 6805 160 12616 19581 4c7d build\/samples\/hello_world\/hello_world<\/code><\/li>\n\n\n\narm-none-eabi-objdump -s -j .isr_vector build\/samples\/hello_world\/hello_world | head<\/code> Make sure the first word is an SRAM address (SP), second is FLASH address (Reset_Handler).<\/li>\n\n\n\nqemu-system-arm -M lm3s6965evb -nographic \\ -kernel build\/samples\/hello_world\/hello_world<\/code> You should see the firmware boot without crashing.
(Output from printf()<\/code> will appear once _write()<\/code> is hooked to UART0.)<\/li>\n<\/ol>\n\n\n\n
\n\n\n\nNext steps<\/h2>\n\n\n\n
\n
_write()<\/code> for UART0 on LM3S \u2192 printf(\"Hello, MicrOS!\\n\")<\/code> visible in the QEMU terminal.<\/li>\n\n\n\narch\/<\/code> vs. board\/<\/code> directories to make LM3S (for emulation) and STM32 (for hardware) selectable in CMake.<\/li>\n<\/ol>\n\n\n\n
\n\n\n\nConclusion<\/h2>\n\n\n\n
\"Hello, MicrOS!\"<\/code> coming out of QEMU\u2019s UART, and then we can dive into scheduling and threads \ud83d\ude80.<\/p>\n\n\n\n
\n","protected":false},"excerpt":{"rendered":"