1

I'm currently trying to build RIOT-OS on MSYS2/mingw64 and flash it to some STM32 dicovery board. Building works just smooth now, but flashing does not work with OpenOCD.

I traced down the problem to the point, where the absolute path to the stlink.cfg is somehow misinterpreted. While all command line tools can find the file /c/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg, openocd does not. OpenOCD is the mingw64 version residing in /mingw64/bin/openocd.

The command in question, executed by RIOTs Makefiles is:

sh -c "openocd \
    -c 'set stlink_version 2;source /c/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg' \
    -c 'transport select hla_swd' \
    -f '/c/somepath/RIOT/boards/common/stm32/dist/stm32f4.cfg' \
    -c 'tcl_port 0' \
    -c 'telnet_port 0' \
    -c 'gdb_port 0' \
    -c 'init' \
    -c 'targets' \
    -c 'reset halt' \
    -c 'flash write_image erase \"/c/somepath/RIOT/hello_world/bin/stm32f429i-disco/helloworld.elf\" 0 ' \
    -c 'verify_image "/c/somepath/RIOT/hello_world/bin/stm32f429i-disco/helloworld.elf" 0' \
    -c 'reset run' \
    -c 'shutdown'"

and also when I just execute:

openocd -d -c 'set stlink_version 2;source /c/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg'

same error occurs:

Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
User : 13 2 options.c:63 configuration_output_handler(): debug_level: 3
[...]
User : 24 3 command.c:694 command_run_line(): couldn't read file "/c/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg": No such file or directory

But when I execute:

openocd -d -c 'set stlink_version 2;source c:/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg'

it seems to work.

A simple cat /c/somepath/RIOT/dist/tools/openocd/adapters/stlink.cfg shows the correct content of the file, the same when I prepend c:/ instead of /c/.

I tried to dig into openocd's code, but since thissomehow involves the interpreter, there is no chance for me to dig deep enough.

Any idea how I can work around this feature/bug?

Edit:

I quickly wrote a little test program (without sanity checks) in C to show that on C-level, both variants of an absolute path work with the open sysem call:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/stat.h>   // Edit 2


int main( int argc, char *argv[] ) {

        char chunk[128], char filename[256];
        struct stat sb;   // Edit 2
        int retval;       // Edit 2

        strncpy(filename, argv[1], sizeof(filename));
        printf("Filename: %s\r\n", filename);

        retval = stat(filename, &sb);     // Edit 2
        printf("Retval of stat: %d\r\n"); // Edit 2

        FILE *fp = fopen(filename, "r");
        int linecnt = 0;

        while(fgets(chunk, sizeof(chunk), fp) != NULL) {
                printf("LINE %3d: %s\r\n", linecnt++, chunk);
        }

        fclose(fp);

}

The test.txt file simply contains: This is a test text.

enter image description here

Edit2:

Found the piece of code that seems to throw the error. It is located in openocd sources in jimtcl/jim.c around line 10986 and looks the following

    if (stat(filename, &sb) != 0 || (fp = fopen(filename, "rt")) == NULL) {
        Jim_SetResultFormatted(interp, "couldn't read file \"%s\": %s", filename, strerror(errno));
        return JIM_ERR;
    }

If I put the stat() in my piece of code, it runs seamlessly.

enter image description here

Anybody could explain, what is happening here in openocd or what is different to my code?

Could it be, that OpenOCD was compiled with mingw64 libraries and mine was compiled with msys?

Here is my ouput of gcc -print-search-dirs

$ gcc -print-search-dirs
install: /usr/lib/gcc/x86_64-pc-msys/11.2.0/
programs: =/usr/lib/gcc/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../x86_64-pc-msys/bin/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../x86_64-pc-msys/bin/
libraries: =/usr/lib/gcc/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../x86_64-pc-msys/lib/x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../x86_64-pc-msys/lib/../lib/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../x86_64-pc-msys/11.2.0/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../lib/:/lib/x86_64-pc-msys/11.2.0/:/lib/../lib/:/usr/lib/x86_64-pc-msys/11.2.0/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../../x86_64-pc-msys/lib/:/usr/lib/gcc/x86_64-pc-msys/11.2.0/../../../:/lib/:/usr/lib/
themole
  • 363
  • 3
  • 12
  • OP has clarified that he will only accept answers that explain how to change the MinGW OpenOCD build so that it recognizes POSIX-style paths. I'm not sure if he needs to recognize everything listed by the MSYS2 `mount` command or would be happy with just replacing `/c` with `C:`, etc. – David Grayson Feb 07 '22 at 23:20
  • That is very well written. However, command line input and output should be provided as text, not images. Please review *[Why not upload images of code/errors when asking a question?](https://meta.stackoverflow.com/questions/285551/)* (e.g., *"Images should only be used to illustrate problems that* ***can't be made clear in any other way,*** *such as to provide screenshots of a user interface."*) and [do the right thing](https://stackoverflow.com/posts/70840794/edit) (it covers command lines as well). – Peter Mortensen Aug 14 '22 at 18:56

0 Answers0