orbcode / orbuculum Goto Github PK

ca5d22f introduces a hard explicit call to setSerialConfig on the socket fd. I don't even know what it's trying to do. orbtop doesn't need a serial port, and it sure doesn't seem relevant to the commit comment for ca5d22f?

It kinda looks like you bled some attempted functionality at running orbtop directly against a dump file, or a trace spew file, instead of via orbuculum, and broke "normal" usage? That would seem to be going against the whole principle of composing things aroudn orbuculum, and means you're going to be fixing the same sorts of things in every one of them. Are you sure that's what you're trying to do? Shouldn't orbtop just connect to the orbuculum service, and orbuculum takes care of how the data arrives?

Direction aside, this call completely fails on a normal socket, and exits.

I was previously using an older version of orbuculum with this incantation (input trace file: raw.zip):
orbuculum -t -f raw.bin -P -e

and this worked very well without any issues. The expected output (obtained from the 1.13 release) is:

8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0
8,21,0x00003aa8
8,21,0x00003bc0

(this is the contents of the generated hwevents file)

Now I'm trying to do the same from the latest code (git main branch) and the results are inconsistent. Sometimes I get the same, sometimes I get a truncated version with fewer lines. My command line is:
orbfifo -t 1 -E -P --input-file raw.bin -c 0,blah,'%08x\n' -v 3

I do seem to always get the full output if I omit the -E option.
Another issue is that hwevent is either not generated at all, or empty, if I omit the -v 3 and/or -c 0... options. (I do not care about the 'blah' output file; hwevents is all I'm after.)

I poked around a bit and I suspect the truncation problem may lie here:

It just does not react

Hi,

I've been playing around with Orbuculum on MacOS over the last week or two. I have a couple of tweaks in the pipeline to make it play nice on this platform but the main one is the addition of the O_NONBLOCK flag when opening a serial port.

The open(2) system call can block waiting for "carrier" with some USB CDC devices. Since there is no carrier (they're not modems) you need to open them with O_NONBLOCK, set CLOCAL (which orbuculum already does) then clear O_NONBLOCK using the F_GETFL/F_SETFL commands with fcntl(2).

The attached diff contains the fix and also format string fixes for uint64_t.

Steve
orbuculum.txt

Hi,

Thanks for providing this great tool!

When using the provided win64 releases (tested v2.1.0), some part of the outputs of the tools appear to be corrupted. Maybe this is an issue with wrong character encodings?

Examples:

orbuculum -m 1000 -s localhost:50001
←[1F←[K←[1;33m     0 ←[0m Bits/sec ←[0m
←[1F←[K←[1;33m     0 ←[0m Bits/sec ←[0m
←[1F←[K←[1;33m     0 ←[0m Bits/sec ←[0m
←[1F←[K←[1;33m     0 ←[0m Bits/sec ←[0m```

orbtop -e test.elf
←[1;33mLoaded test.elf
←[0m←[2J←[;HConnected...
←[2J←[;H←[1;33m 61.57% ←[1;34m    1849 ←[1;36m** Sleeping **←[0m
←[1;33m 33.99% ←[1;34m    1021 ←[1;36mvApplicationIdleHook←[0m
←[1;33m  2.33% ←[1;34m      70 ←[1;36mFLEXCOMM1_DriverIRQHandler←[0m
←[1;33m  0.79% ←[1;34m      24 ←[1;36mprvIdleTask←[0m
←[1;33m  0.46% ←[1;34m      14 ←[1;36mFLEXCOMM_GetInstance←[0m
←[1;33m  0.19% ←[1;34m       6 ←[1;36mCTIMER_GetStatusFlags←[0m
←[1;33m  0.13% ←[1;34m       4 ←[1;36mSPI_MasterTransferNonBlocking←[0m
←[1;33m  0.13% ←[1;34m       4 ←[1;36mprvCheckTasksWaitingTermination←[0m
←[0m-----------------
←[1;33m 99.59% ←[1;34m    2992 ←[0mof ←[1;33m 3003 ←[0m Samples

←[0m[←[1;31mV←[1;32mS←[0m-←[1;36mH←[0m] ←[0mInterval = ←[1;33m998←[0mms

Thanks!

Something went missing?

ICE40HX1K_STICK_EVN.pcf:21: fatal error: no port rxInd_led' in top-level module topLevel'

6ef8cfc removed the rxInd_led, and added a heartbeat_led?

This doesn't work, it seems to be waiting for the end of input or something.

orbcat -c 0,'%c' | grep blah

There are some circumstances where orbuculum only needs to be a network multiplexer and the fifos are not needed. Add an option to make this possible.

$ cat /etc/os-release 
NAME="Linux Mint"
VERSION="20.3 (Una)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 20.3"

$ sudo apt install libusb-1.0-0-dev libczmq-dev libncurses-dev libsdl2-dev libelf-dev libcapstone-dev

$ meson --version
1.4.0

$ git log
commit 7968f96ef92a00b42123bf794442d54005284db3 (HEAD -> main, origin/main, origin/HEAD)
Author: Vegard Storheil Eriksen <[email protected]>
Date:   Tue Mar 26 00:23:45 2024 +0100

    Python interface moved to pyorb repo.

meson setup build is successful

$ meson setup build
The Meson build system
Version: 1.4.0
Source dir: /home/alex/git/orbuculum
Build dir: /home/alex/git/orbuculum/build
Build type: native build
Project name: orbuculum
Project version: 2.1.0
C compiler for the host machine: ccache cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0")
C linker for the host machine: cc ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Run-time dependency threads found: YES
Found pkg-config: YES (/usr/bin/pkg-config) 0.29.1
Run-time dependency libusb-1.0 found: YES 1.0.23
Run-time dependency libzmq found: YES 4.3.2
Run-time dependency sdl2 found: YES 2.0.10
Run-time dependency ncurses found: YES 6.2.20200212
Run-time dependency capstone found: YES 3.0.5
Run-time dependency libelf found: YES 0.176

Executing subproject libdwarf 

libdwarf| Project name: libdwarf
libdwarf| Project version: 0.7.0
libdwarf| C compiler for the host machine: ccache cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0")
libdwarf| C linker for the host machine: cc ld.bfd 2.34
libdwarf| C++ compiler for the host machine: ccache c++ (gcc 9.4.0 "c++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0")
libdwarf| C++ linker for the host machine: c++ ld.bfd 2.34
libdwarf| Compiler for C supports arguments -Wpointer-arith: YES
libdwarf| Compiler for C supports arguments -Wmissing-declarations: YES
libdwarf| Compiler for C supports arguments -Wstrict-prototypes: YES
libdwarf| Compiler for C supports arguments -Wcomment: YES
libdwarf| Compiler for C supports arguments -Wformat: YES
libdwarf| Compiler for C supports arguments -Wuninitialized: YES
libdwarf| Compiler for C supports arguments -Wshadow: YES
libdwarf| Compiler for C supports arguments -Wno-long-long: YES
libdwarf| Compiler for C supports arguments -Wfloat-compare: NO
libdwarf| Compiler for C supports arguments -Wsign-compare: YES
libdwarf| Compiler for C supports arguments -Wno-missing-field-initializers: YES
libdwarf| Compiler for C supports arguments -fno-omit-frame-pointer: YES
libdwarf| Compiler for C supports arguments -fvisibility=hidden: YES
libdwarf| Compiler for C supports function attribute unused: YES
libdwarf| Has header "fcntl.h" : YES
libdwarf| Has header "inttypes.h" : YES
libdwarf| Has header "malloc.h" : YES
libdwarf| Has header "stdint.h" : YES
libdwarf| Has header "sys/stat.h" : YES
libdwarf| Has header "unistd.h" : YES
libdwarf| Checking for type "uint64_t" : YES
libdwarf| Checking for type "uintptr_t" : YES
libdwarf| Checking for type "intptr_t" : YES
libdwarf| Has header "libelf.h" : YES
libdwarf| Has header "libelf/libelf.h" : NO
libdwarf| Has header "elf.h" : YES
libdwarf| Run-time dependency zlib found: YES 1.2.11
libdwarf| Run-time dependency libzstd found: NO (tried pkgconfig)
libdwarf| subprojects/libdwarf-0.7.0/test/meson.build:112: WARNING: Project targets '>=0.56' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
libdwarf| Program python3 found: YES (/home/alex/.local/pipx/venvs/meson/bin/python)
libdwarf| Message: Elf
libdwarf| subprojects/libdwarf-0.7.0/test/meson.build:137: WARNING: Project targets '>=0.56' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
libdwarf| Message: PE
libdwarf| Message: Macos
libdwarf| Program sh found: YES (/usr/bin/sh)
libdwarf| Configuring config.h using configuration
libdwarf| Configuring libdwarf.pc using configuration
libdwarf| Build targets in project: 26
libdwarf| WARNING: Deprecated features used:
libdwarf| * 0.56.0: {'meson.build_root', 'meson.source_root'}
libdwarf| Subproject libdwarf finished.

Build targets in project: 39

libdwarf 0.7.0

  Configuration Options Summary:
    OS               : linux
    BuildOS-BigEndian: no
    libelf support   : yes
    libdwarf         : always (zlib: yes) always (libzstd: no)
    dwarfdump        : always
    libdwarfp        : no
    dwarfgen         : no
    dwarfexample     : no
    documentation    : no

  Directories:
    prefix           : /usr/local
    bindir           : /usr/local/bin
    libdir           : /usr/local/lib/x86_64-linux-gnu
    incdir           : /usr/local/include
    pkgincdir        : /usr/local/include/libdwarf
    datadir          : /usr/local/share
    pkgdatadir       : /usr/local/share/libdwarf

  Compilation
    compilation      : ninja
    installation     : ninja install

orbuculum 2.1.0

  Subprojects
    libdwarf: YES 3 warnings

Found ninja-1.10.0 at /usr/bin/ninja

$ ninja -C build
[....]

FAILED: orbmortem.p/Src_loadelf.c.o 
ccache cc -Iorbmortem.p -I. -I.. -I../Inc -I../Inc/external -Isubprojects/libdwarf-0.7.0/src/lib/libdwarf -I../subprojects/libdwarf-0.7.0/src/lib/libdwarf -I/usr/include/libusb-1.0 -I/usr/include/pgm-5.2 -I/usr/include/SDL2 -I/usr/include/capstone -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -DLINUX -ggdb -D_GNU_SOURCE -DSCREEN_HANDLING -Wno-error=deprecated-declarations -include uicolours_default.h -include uicolours_default.h -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_REENTRANT -isystem /usr/include/mit-krb5 -pthread -MD -MQ orbmortem.p/Src_loadelf.c.o -MF orbmortem.p/Src_loadelf.c.o.d -o orbmortem.p/Src_loadelf.c.o -c ../Src/loadelf.c
../Src/loadelf.c: In function ‘symbolDisassembleLine’:
../Src/loadelf.c:1042:33: error: ‘ARM_INS_ERET’ undeclared (first use in this function); did you mean ‘ARM64_INS_ERET’?
 1042 |         *ic |=  ( ( insn->id == ARM_INS_ERET ) ) ? LE_IC_JUMP | LE_IC_IRET : 0;
      |                                 ^~~~~~~~~~~~
      |                                 ARM64_INS_ERET
../Src/loadelf.c:1042:33: note: each undeclared identifier is reported only once for each function it appears in
[261/271] Compiling C object orbtrace.p/Src_symbols.c.o
../Src/symbols.c:120:36: warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
  120 |     #pragma GCC diagnostic ignored "-Wanalyzer-malloc-leak"
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~
../Src/symbols.c:1064:36: warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
 1064 |     #pragma GCC diagnostic ignored "-Wanalyzer-malloc-leak"
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~
[263/271] Compiling C object orblcd.p/Src_orblcd.c.o
ninja: build stopped: subcommand failed.

Do I have an older version of something?

Please add your name to this list if you're interested in joining the waiting list for hardware. This isn't a hard committent, we'll let you know things like cost before you sign on the dotted line!

The icebreaker has a ICE40UP5K-SG48 on it, seems like a good candidate for a port. Would probably have to leave off sump or reduce the number of pins in the analyser.

My first pass at pin assignment looks like this, but I need to move to the other FT2232 port.

# Trace signals PMOD1A 1-4, 10
set_io traceDin[0]              4  
set_io traceDin[1]              2
set_io traceDin[2]             47
set_io traceDin[3]             45
set_io traceClk                44

# SPI connection to PC

# FT2232H pin 40
set_io spitx            18    # SPI MISO
# FT2232H pin 39
set_io spirx            9     # SPI MOSI
# FT2232H pin 38
set_io spiclk           6     # SPI CLK
# FT2232H pin 41
set_io rstIn            19     # SPI CS pin of FT2232H

# Oscillator clock for FPGA PLL
set_io clkIn        35    # connected to 12MHz xtal

# LEDs (G & RGB)
set_io sync_led        37
set_io txOvf_led       39
set_io txInd_led       40
set_io heartbeat_led   41

I am trying out orbtrace with an iCE40HX-8K Breakout Board.

Building and flashing worked and orbuculum seems to talk to the FPGA fine as well.

First issue that arised was:

Orbuculum V1.10 (Git 0146E353 Dirty, Built 2020-11-30 12:40:35+0000)
BasePath   : 
ForceSync  : true
Permafile  : false
Orbtrace   : 4 bits width
Using TPIU : true (ITM on channel 1)
Channels   :
         00 [info] [info]
         HW [Predefined] [hwevent]
Port opened
All parameters configured
orbuculum: Src/nwclient.c:221: nwclientSend: Assertion `len' failed.
Aborted

That was quickly fixed by recompiling with WITH_NWCLIENT=0, since I don't need it. But you may want to check that out (maybe it is related to the root problem below).

Now I get:

orbuculum -o 4 -c 0,info,"%c" -v 3
Orbuculum V1.10 (Git 0146E353 Dirty, Built 2020-12-10 12:54:20+0000)
BasePath   : 
ForceSync  : true
Permafile  : false
Orbtrace   : 4 bits width
Using TPIU : true (ITM on channel 1)
Channels   :
         00 [info] [info]
         HW [Predefined] [hwevent]
Port opened
All parameters configured
RXED frame of 0/900 full packets (  0%)    
RXED frame of 0/900 full packets (  0%)    
RXED frame of 0/900 full packets (  0%)    
RXED frame of 0/900 full packets (  0%)    
RXED frame of 0/900 full packets (  0%)    
...

Heartbeat is blinking. Same thing with only 1 bit width.
I am not sure what this output means. Can it be that I am just stupid and didn't wire it correctly? Do I need to configure something special in the code or gdb, besides enabling ITM and TRCENA? I am using a NRF52840 Preview DK.

Hi, nice work you're doing! I'm trying to run this with CP2102 but no luck so far

my orbuculum command is

orbuculum -b swo/ -v 3 -a /dev/ttyUSB0 -s 115200

for gdb

prepareSWD 72000000 115200 1 0

followed by

https://github.com/mubes/orbuculum/blob/master/Support/gdbinits/gdbinit-bmp#L35

The result is I can see the data on scope and when using screen but no output from orbcat.

Also tried with 921600 baudrate (both in gdb and for orbuculum, also with TPIU on/off).

I'm also going to try with BluePill and F4 discovery flashed with BMP, managed to flash HX8K board as well but no data from parallel trace yet. Will report soon.

Target: tm4c129x @ 120Mhz
Interface: jlink pro
middleware: openocd

The Jlink is running at 20M, with SWO speed autodetected, (openocd reports 41M, but that's... clearly not correct)

I'm using DWT PC sampling with the 1024 divider, and it all works nicely. I've got some ITM channels for debug as well, all values are as expected. the Bottom of the orbtop screen shows no overflows, but lots of samples, as expected for this sort of setup.

95.89%   112588 of  117116  Samples

[-S-H] Interval = 999ms

however, over time the ortbtop process CPU usage crawls up until it pegs a CPU, and eventually stops processing. I've used perf record -p $(pidof orbtop) to capture CPU usage early: (using something like 5-10% at this point)

Samples: 8K of event 'cycles:Pu', Event count (approx.): 4895560717
Overhead  Command  Shared Object     Symbol
  28.30%  orbtop   orbtop            [.] _handlePCSample
  27.92%  orbtop   orbtop            [.] _consolodateReport
   7.93%  orbtop   orbtop            [.] _routines_sort_fn
   7.28%  orbtop   liborb.so.2.1.0   [.] ITMPump
   4.36%  orbtop   [vdso]            [.] __vdso_gettimeofday

Then, later, when it was using ~40% cpu

Samples: 43K of event 'cycles:Pu', Event count (approx.): 44954534996
Overhead  Command  Shared Object     Symbol
  76.78%  orbtop   orbtop            [.] _consolodateReport 
  14.27%  orbtop   orbtop            [.] _routines_sort_fn
   5.43%  orbtop   orbtop            [.] _handlePCSample
   0.76%  orbtop   liborb.so.2.1.0   [.] ITMPump
   0.45%  orbtop   [vdso]            [.] __vdso_gettimeofday

During this time, orbtop's output itself has remained stable, showing steady ~100k samples per interval, with the target processor doing the "same" thing as before...

I suspect that overtime, I'm simply seeing more and more slightly different addresses, and that's making this hash sort in "consolidate": https://github.com/orbcode/orbuculum/blob/main/Src/orbtop.c#L371 take an unreasonable amount of time.

however, I'm afraid I don't know enough about the mechanisms here to try and work on a fix for this at this point.

OS: Windows 10
J-LINK: On board of an nrf52840DK
jlinkgdbservercl -select USB -device nRF52840_xxAA -endian little -if SWD -speed 4000 -noir -LocalhostOnly -nologtofile

GDB:

target remote localhost:2331
monitor reset
monitor SWO EnableTarget 0 8000000 0xff 0
prepareSWO 64000000 8000000
... other standard setups to enable PC sampling ...

orbuculum -s localhost:2332 -m 1000 -v3 outputs

orbuculum version a4d410b-dirty
Report Intv    : 1000 mS
NW SERVER H&P  : localhost:2332
Use/Strip TPIU : False
Established NW Server Link
Lost NW Server Link
Established NW Server Link
 No active connection

pretty much immediatly.

However, orbtop can connect fine using orbtop -s localhost:2332

Let me know if there is anything I can help with. Love the project ❤️

Unable to build:

make
 Compiling Src/itmDecoder.c
 Compiling Src/tpiuDecoder.c
 Compiling Src/generics.c
 Compiling Src/orbuculum.c
 Compiling Src/filewriter.c
 Compiling Src/ftdispi.c
Completed build of orbuculum
Completed build of orbcat
 Compiling Src/orbtop.c
 Compiling Src/symbols.c
Src/symbols.c: In function ‘SymbolLookup’:
Src/symbols.c:138:35: warning: implicit declaration of function ‘bfd_get_section_vma’; did you mean ‘bfd_set_section_vma’? [-Wimplicit-function-declaration]
  138 |     uint32_t workingAddr = addr - bfd_get_section_vma( s->abfd, s->sect );
      |                                   ^~~~~~~~~~~~~~~~~~~
      |                                   bfd_set_section_vma
Src/symbols.c:140:44: warning: passing argument 1 of ‘bfd_section_size’ from incompatible pointer type [-Wincompatible-pointer-types]
  140 |     if ( workingAddr <= bfd_section_size( s->abfd, s->sect ) )
      |                                           ~^~~~~~
      |                                            |
      |                                            bfd * {aka struct bfd *}
In file included from Inc/bfd_wrapper.h:44,
                 from Inc/symbols.h:38,
                 from Src/symbols.c:50:
/usr/include/bfd.h:1206:35: note: expected ‘const asection *’ {aka ‘const struct bfd_section *’} but argument is of type ‘bfd *’ {aka ‘struct bfd *’}
 1206 | bfd_section_size (const asection *sec)
      |                   ~~~~~~~~~~~~~~~~^~~
Src/symbols.c:140:25: error: too many arguments to function ‘bfd_section_size’
  140 |     if ( workingAddr <= bfd_section_size( s->abfd, s->sect ) )
      |                         ^~~~~~~~~~~~~~~~
In file included from Inc/bfd_wrapper.h:44,
                 from Inc/symbols.h:38,
                 from Src/symbols.c:50:
/usr/include/bfd.h:1206:1: note: declared here
 1206 | bfd_section_size (const asection *sec)
      | ^~~~~~~~~~~~~~~~
make: *** [Makefile:163: ofiles/Src/symbols.o] Ошибка 1

binutils version is 2.31.1-16

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-11' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-11)

clang -v
clang version 9.0.1-12 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda-10.1, version 10.1

I'm debugging an stm32f427 target using an orbtrace mini, and noticed that the tick counts for the interrupt in question according to orbtop are significantly smaller than a cycle count in code of the exception's running, even taking into account the nested interrupts running during the interrupt. Digging into orbtop, it looks like an exception trace "Resume" is taken to mean rolling up the entire exception stack to nothing, but that does not seem to be what the actual trace output is doing:

1,1,Enter,External,28
0,0,13
1,2,Enter,External,57
0,0,2690
1,1,Exit,External,57
0,0,960
1,1,Resume,External,28
0,0,7
1,2,Enter,External,57
0,0,4409
1,1,Exit,External,57
0,0,961
1,2,Resume,External,28
0,0,7
1,1,Enter,External,57
0,0,4401
1,3,Exit,External,57
0,0,965
1,2,Resume,External,28
0,0,7
1,2,Enter,External,54
0,0,3950
1,2,Exit,External,54
0,0,361
1,6,Resume,External,28
0,0,7
1,2,Enter,External,57
0,0,80
1,2,Exit,External,57
0,0,965
1,1,Resume,External,28
0,0,7
1,2,Exit,External,28
0,0,412

In the above example, 28 is the interrupt I'm trying to measure, and 57 occurs a few times during it as a higher priority. orbtop maxTicks appears to be only giving me the max single instance of 28 between the 57s, but really the exception is underway for the entire above trace.

Modifying orbtop like:

@@ -302,12 +304,12 @@ void _handleException( struct excMsg *m, struct ITMDecoder *i )
             break;
 
         case EXEVENT_RESUME: /* Unwind all levels of exception (deals with tail chaining) */
-            while ( ( _r.currentException != NO_EXCEPTION ) && ( _r.erDepth ) )
+            while ( ( _r.currentException != m->exceptionNumber ) && ( _r.erDepth ) )
             {
                 _exitEx( _r.timeStamp );
             }
 
-            _r.currentException = NO_EXCEPTION;
+//            _r.currentException = NO_EXCEPTION;
             break;

produces numbers far more aligned with my own measurements. Am I misunderstanding something about the meaning of the trace messages, or is this the correct way to handle these events?

Hi @mubes , I would like to start a list of activities, kind of 'first contributions' tasks, to get familiar with the orbcode tooling.Do you (or folks) have such list?

orbcat -c 0, "%c" results in no output and no error message. Note the spaces.

In version 5c711f4 from Devel branch, I get the following with orbtrace --help:

   -T, --trace-format:  <x> Trace format; 1,2 or 4 bit parallel, m for Manchester SWO, u=UART SWO
   -                         For UART, follow with speed, e.g. -Tu for Manchester SWO, u=UART SWO

with the message coming from here: https://github.com/orbcode/orbuculum/blob/Devel/Src/orbtrace.c#L144-L145

I don't understand what the second line means, looks like copy paste mistake to me.

(For clarity, this is tested against b475ebb)

Currently:

> objdump.exe
'objdump.exe' is not recognized as an internal or external command,
operable program or batch file.
> echo %OBJDUMP%
%OBJDUMP% (i.e. env var is unset)
> dir /b simple.elf
simple.elf
> orbtop.exe -e simple.elf
(Program launches, only continuously reports "Could not read symbols" error despite elf existing)

Expected:

> orbtop.exe -e simple.elf
orbtop: Unable to find objdump. Add to path or set with OBJDUMP.
> set OBJDUMP=c:\armgcc\bin\arm-none-eabi-objdump.exe
> orbtop.exe -e simple.elf
(Program works properly)

Hello. This is a notice of another project which aims to accomplish similar goals as orbuculum. My aim here is to establish a line of communication that may eventually lead to some cross-pollination that would hopefully improve both projects.

As part of my thesis which I'm currently wrapping up I have been working with ITM on Cortex-M platforms where RTIC is used. This has collimated into a toolset named RTIC Scope. Unfortunately, I did not discover orbuculum until later later into the thesis and only just recently realized that I have effectively reimplemented some features which orbuculum already offers. While orbuculum seems to be a more generally applicable UNIX-style toolset, RTIC Scope instead exclusively fits into the Rust ecosystem by offering a cargo subcommand which aims to do it all:

1. build your firmware with cargo;
2. recover some metadata;
3. optionally flash your target with the firmware and reset it;
4. collect trace data from the target using SWO or the embedded trace buffer;
5. map trace information to RTIC tasks (i.e. resolve raw ITM data);
6. save trace packets to file for port-mortem analysis; and
7. forward resolved trace information to frontends which can do whatever they like (display something in a GUI, save traces in a database, etc.).

The whole point of the toolset is to remove any end-user overhead: if an application is written in RTIC, RTIC Scope should allow instant insight into the system without any setup. We're some ways away from zero end-user overhead in the project's current state, however.

Interface-wise RTIC Scope currently supports any targets probe-rs supports and serial devices on which a raw ITM data-stream is expected.

Aside from the cargo subcommand work has been made on APIs for configuring ITM tracing target-side and host-side (via probe-rs), and an ITM protocol decoding library has been written.

The next big feature for RTIC Scope would be a graphical display of the trace data which orbuculum would appear to offer via orbtop and orbstat. I'll be taking a look at these in the coming weeks and see if they can be combined with RTIC Scope.

Now that we're aware of eachother I look forward to any eventual cross-pollination between the two projects.

Cheers.

Assume stuff !

Will this work with bumpy : https://github.com/electronut/ElectronutLabs-Bumpy ?

Will it work with any DAPlink probes ? The firmware ( https://github.com/ARMmbed/DAPLink ) seems to have SWO (UART / NRZ only), but it doesn't seem to be enabled for any hardware. I have a FRDM-K64F board (w/ K20DX chip) that runs DAPlink, so I could test with that.

The IBDAP hardware seems to have SWO : https://www.adafruit.com/product/2764 , https://www.hackster.io/armstart/ibdap-affordable-cmsis-dap-jtag-swd-debug-probe-e6d9a4 ... but can't find the firmware source.

Dunno if these have SWO : https://l-tek.si/web-shop/cmsis-dap-debug-probe/ , https://os.mbed.com/platforms/SWDAP-LPC11U35/

Thanks !

We are trying to save the captured instruction trace with orbmortem. The help menu says that you should use the S key for this, but after typing the filename and hitting 'enter' the file isn't created anywhere. I would expect for the file to be saved in the current working directory, but I see nothing.

Am I missing something?

Thanks,
Augusto.

I'll try and find and fix this myself if I run into it again, but filing it so it doesn't get forgotten.

It's not terrible behaviour, it's just not a very graceful exit :) (I'm presuming exiting is about the only sane thing to do. It could stay there saying "unable to open file" forever, but not sure that's better)

The new high speed serial hander code appears to set incorrect baudates.

(For clarity, this is tested against b475ebb)

Currently:

$ orbtop
Elf File not specified
$ cat justsomefilename
cat: justsomefilename: No such file or directory
$ orbtop -e justsomefilename
(program continues but complains about "Could not read symbols")
$ cat .
cat: .: Is a directory
$ orbtop -e .
(program continues without any errors)

Expected:

$ cat justsomefilename
cat: justsomefilename: No such file or directory
$ orbtop -e justsomefilename
orbtop: justsomefilename: No such file or directory
$ orbtop -e .
orbtop: .: Is a directory

Similarly for permission errors etc.

As far as I can tell from the code and from my experiments, you simply don't support ITM mode (no TPIU formatting) without synchronization packets.

This is a rather harsh requirement, even ARM says not to do this. "If a system is using an asynchronous serial trace port, ARM recommends it disables Synchronization packets to reduce the data stream bandwidth." (See armv7m architecture reference manual Section C1.7.1 "Synchronization support" (page 847 in my copy)

a few insertions of ITMDecoderForceSync( &_r.i, TRUE ); into orbcat/orbtop/orbdump improve things substantially, but that's probably not how you want to handle things permanently.

The default colour palette for the Orb tools is not ideal when used with a pale window background; the light colours (e.g. yellow, cyan, green) are more or less illegible:

There's a compile-time option to switch off colourisation, but it would be nice to have a command line option to select from some built-in palettes.

orbtop is using numbers starting from 0 as exception number, it is also numbering scheme used in ARM docs. However typical definition of IRQn_Type enum will use negative numbers for exceptions and non-negative for interrupts (SysTick_IRQn = -1 and FirstInterrupt = 0).

While translating between these two schemes are trivial it is also easy for human being to make off-by-one error and mismatch interrupts (I imagine that two interrupts in active use can be next to each other so mistake will not be easy to spot).

I'm not sure that switching orbtop numbering to -16..N is the best choice but maybe adding some info ("subtract 16 to get IRQn_Type values") or configurable option?

it would be extremely helpful if runnable binaries/installers were uploaded to each release to prevent users from having to compile.

Got my orbtrace mini today and I've been speedrunning getting all the tooling going, coming from a SeggerGDBServer style setup.

Issue

Blindly following this repo's docs will lead overly keen Arch Linux users into a pretty typical error when any orb* tool tries to load liborb.so from the default install path /usr/local/lib/liborb.so.

orbtrace: error while loading shared libraries: liborb.so.0: cannot open shared object file: No such file or directory

Resolution

Arch Linux's packaging etiquette normally wants meson builds to be prefixed on /usr.

i.e. a more correct incantation for this repo's build is:

meson setup --prefix=/usr build

I'm happy to PR a note into the docs if you want.

If it's meant to be a directory, it should not require trailing slash.
If it's meant to be a prefix it should be named differently

You guys really need a travis or something build that tries building various modes for you :)

in orbuculum.c:1099 we have

   /* Start the filewriter */
    IF_WITH_FIFOS( fifoFilewriter( _r.f, options.filewriter, options.fwbasedir ) );

and it would seem that options.fwbasedir is "file writer base dir" ? or at least, that'swhat the fifoFilewriter method expects.

However, in the options struct at line 136:

    /* FPGA Information */
    IF_INCLUDE_FPGA_SUPPORT( char *fwbasedir );          /* Where the firmware is stored */

Which seems to be something else?

It's not actually used anywhere though, it's never set either, not by any of the command line options. Given these amgiuities, I can make it compile by just

diff --git a/Src/orbuculum.c b/Src/orbuculum.c
index 785bb39..012e32b 100644
--- a/Src/orbuculum.c
+++ b/Src/orbuculum.c
@@ -1096,7 +1096,7 @@ int main( int argc, char *argv[] )
 #endif
 
     /* Start the filewriter */
-    IF_WITH_FIFOS( fifoFilewriter( _r.f, options.filewriter, options.fwbasedir ) );
+    IF_WITH_FIFOS( fifoFilewriter( _r.f, options.filewriter, NULL ) );
 
 #ifdef INCLUDE_FPGA_SUPPORT
 

But I don't know what the "real" fix is I'm sorry.

I had too much data being written to ITM software trace ports, which resulted in ITM Overflow messages as expected. However what I didn't expect is that orbuculum wrote a bunch of weirdly named files to the working directory:

petteri@oddish:tmp$ ls -l
total 116
-rw-r--r-- 1 petteri petteri 110254 Apr 29 10:55 swo_log.bin

petteri@oddish:tmp$ orbuculum -f swo_log.bin
ITM Overflow (1)
ITM Overflow (2)
ITM Overflow (3)
ITM Overflow (4)
....
Request for write on descriptor 1 while file closed
Request for write on descriptor 6 while file closed
Request for write on descriptor 6 while file closed
Request for write on descriptor 6 while file closed
Request for write on descriptor 3 while file closed
Attempt to write to descriptor 7 while open writing 4
...

petteri@oddish:tmp$ ls -l
total 360
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 '~'
-rw-r--r-- 1 petteri petteri      2 Apr 29 10:56 '~}'$'\367\272'
-rw-r--r-- 1 petteri petteri      2 Apr 29 10:56 '~'$'\256'
-rw-r--r-- 1 petteri petteri      3 Apr 29 10:56 '<'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 '>'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\343'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\376'
-rw-r--r-- 1 petteri petteri      5 Apr 29 10:56 ''$'\352'
-rw-r--r-- 1 petteri petteri     18 Apr 29 10:56 ''$'\377'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\276'
-rw-r--r-- 1 petteri petteri      2 Apr 29 10:56 ''$'\326'
-rw-r--r-- 1 petteri petteri     17 Apr 29 10:56 ''$'\372'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\254'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\354'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\374'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\367'
-rw-r--r-- 1 petteri petteri     10 Apr 29 10:56 ''$'\303'
-rw-r--r-- 1 petteri petteri      3 Apr 29 10:56 ''$'\274'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\356'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\256'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\254\367'
-rw-r--r-- 1 petteri petteri      9 Apr 29 10:56 ''$'\372\367\272'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56 ''$'\327\017\356'
-rw-r--r-- 1 petteri petteri      0 Apr 29 10:56  4
-rw-r--r-- 1 petteri petteri      2 Apr 29 10:56  l
-rw-r--r-- 1 petteri petteri 110254 Apr 29 10:55  swo_log.bin

I think the file should be properly synchronized etc., so I'm wondering what causes the weird files.
I've attached the swo_log.bin. I've been using git revision 1fda426.
swo_log.bin.gz

At the moment the meson install target only installs the executables and library.
In my opinion on Linux the Support/60-orbcode.rules should be installed to /lib/udev/rules.d/.
Also the Support/gdbtrace.init is useful enough to be placed in /usr/share/orbuculum/.
The need to manually copy this file could lead to people using outdated versions.

I would like to know if there's any alternative to libiberty on Mac OS X as i'm unable to compile orbuculum since clang and macport gcc-7 don't have the libiberty library.

Is this a typo?

enableSTM32SWD <*--- turn on SWO output pin on CPU

In my understanding it should read enableSTM32SWO (?)

thanks

Not an issue but perhaps worth noting the following issues and adding to the documentation?

1. Homebrew on macOS now installs into /opt/homebrew/ so you need to adjust paths inn the Makefile appropriately.
2. If you have installed binutils with Homebrew, this will not build on M1 without deactivating them.

So need to (1) edit the Makefile:85 to

 ifdef OSX
    INCLUDE_PATHS += -I/opt/homebrew/include/libusb-1.0
    LDLIBS = -L. -L/opt/homebrew/lib -lusb-1.0 -ldl -lncurses -lpthread -lintl -L$(OLOC) -l$(ORBLIB)

and (2) need to (at least temporarily) move aside any binutils installed in /opt/homebrew/opt/binutils
mv /opt/homebrew/opt/binutils ~/binutils

I have tried using orbuculum with the toolchain linked here: https://modm.io/guide/installation/

The issue is that the arm-none-eabi-gdb (version 12.1.90) does not correctly process the gdbtrace.init from this repository and therefore the enableSTM32TRACE command cannot be used.

Example output is here: https://cdn.discordapp.com/attachments/614885210395508738/1146444609174654987/image.png

I cloned the repo and tried building the main branch which resulted in this:

make WITH_FPGA=0 
 Compiling Src/generics.c
 Compiling Src/itmDecoder.c
 Compiling Src/tpiuDecoder.c
 Compiling Src/msgDecoder.c
 Compiling Src/msgSeq.c
Completed build of orb
 Compiling Src/orbuculum.c
 Compiling Src/filewriter.c
 Compiling Src/fifos.c
 Compiling Src/nwclient.c
/usr/bin/ld: cannot find -liberty
collect2: error: ld returned 1 exit status
Makefile:218: recipe for target 'orbuculum' failed
make: *** [orbuculum] Error 1

I was able to fix it (and meet other deps except FPGA) with :

sudo apt install binutils-dev libelf-dev libiberty-dev

Thanks for this software :)

I'm trying to build orbuculum from source, from the main branch. I get the following error:

$ meson setup build
The Meson build system
Version: 0.56.2
Source dir: /home/j-hui/extern/orbuculum
Build dir: /home/j-hui/extern/orbuculum/build
Build type: native build
Project name: orbuculum
Project version: undefined
C compiler for the host machine: ccache cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
C linker for the host machine: cc ld.bfd 2.35.2
Host machine cpu family: x86_64
Host machine cpu: x86_64
Run-time dependency threads found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency libusb-1.0 found: YES 1.0.24
Run-time dependency libzmq found: YES 4.3.4
Run-time dependency sdl2 found: YES 2.0.14

meson.build:3:0: ERROR: Expected 1 arguments, got 2.

A full log can be found at /home/j-hui/extern/orbuculum/build/meson-logs/meson-log.txt

The problem appears to be from the dependencies section, which invokes dependency('ncurses', 'ncursesw'). I'm able to work around the problem with either of the following changes:

-    dependency('ncurses', 'ncursesw')
+    dependency('ncurses')

or

-    dependency('ncurses', 'ncursesw')
+    dependency('ncurses', fallback: ['ncursesw'])

but I'm wondering if I'm doing something wrong in the first place?

Thanks!

I'm trying to use the file input mode with the output file written by openocd. (So that I can get the SWO data from say, stlink instead of having to have an extra usb-uart) but a) it doesn't follow the file, it just reads it once, and b) it simply reads the file, passes it to "all" clients and exits. It does this... very quickly. Far far far faster than one could possibly run any of the other orb tools to actually connect and be one of these clients :)

Hey, first, thanks so much for this awesome tool!

My only issue so far is that I run into a segmentation fault when I try to emit DWT events through the ITM.

My very simple test code on my nRF52840 Preview DK looks like that:

int32_t test = 0x1336;

void _DWT_enable() {
  CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
  ITM->LAR = 0xc5acce55;
  DWT->COMP2 = &test;
  DWT->FUNCTION2 |= (DWT_FUNCTION_EMITRANGE_Msk | (DWT_FUNCTION_FUNCTION_Msk & 0b0011));
}

int main() {

  _DWT_enable();

  while (true) {
 
    test++;

    nrf_delay_ms(1000);
         
  }
}

When I run Orbuculum it will receive a few bytes and then pretty much immediately segfault:

$ sudo ./orbuculum -s localhost:2332 -b swo/ -P -c 0,zero,"0x%08x\n" -v 3
Orbuculum V1.10 (Git 10BC7ACB Dirty, Built 2020-11-01 13:16:26+0000)
BasePath   : swo/
ForceSync  : true
Permafile  : true
SEGGER H&P : localhost:2332
Channels   :
         00 [zero] [zero]
         HW [Predefined] [hwevent]
Established Segger Link
RXED Packet of 144 bytes
Segmentation fault

Sometimes it manages to write a few lines into hwevent, sometimes not. If it does, it looks something like that:

6,2556,0,0x0002
6,46,0,0x0002

I didn't find any documentation on what this really means (is there any?) but according to the code that is a "offset write event" (is that correct? where would I find the data value and address? Or is this event not related at all?).

Running Orbuculum without any paramenters like: sudo ./orbuculum -s localhost:2332 segfaults as well.

Do you have an idea what causes the segfault?

Help does not show these options and they are not parsed.

I though it would be possible to directly connect this to a jlink raw SWO port..

typing make after cloning gives the following error

/bin/sh: ofiles/git_version_info.h: No such file or directory
make: *** [get_version] Error 1

mac osx sierra
kindly help.

Hi all,

I'm wondering if this solution is limited to be used with STM32 as stated in the command
"enableSTM32SWD <*--- turn on SWO output pin on CPU"

thansk!

Devel branch hasn't picked up fixes from master? It seems some of them were picked in with other changes, but others have been missed? eg, master's f6302c9 is included as part of the unrelated 6f0880e on Devel. It's at least missing the segfault on orbdump, but the way you've been using git makes it almost impossible to track what you have actually included where.