RS41ng icon indicating copy to clipboard operation
RS41ng copied to clipboard

Failure to build under docker and fedora workstation

Open Notupus opened this issue 2 years ago • 30 comments

Using either the docker or fedora build enviroments I get the following error

npc@fedora build]$ cmake ..

-- The C compiler identification is GNU 12.2.1 -- The CXX compiler identification is GNU 12.2.1 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/npc/RS41ng/build [npc@fedora build]$ make [ 1%] Building C object src/CMakeFiles/RS41ng.elf.dir/bmp280_handler.c.o [ 2%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs.c.o [ 3%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs_position.c.o [ 4%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs_weather.c.o [ 5%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/ax25/ax25.c.o [ 6%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/bell/bell.c.o [ 8%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_common.c.o [ 9%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_l2.c.o [ 10%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_packet_v1.c.o [ 11%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_packet_v2.c.o [ 12%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/crc14.c.o [ 13%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/mfsk/mfsk.c.o [ 14%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/morse/morse.c.o [ 16%] Building C object src/CMakeFiles/RS41ng.elf.dir/config.c.o [ 17%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/bmp280/bmp280.c.o [ 18%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/pulse_counter/pulse_counter.c.o [ 19%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/si4032/si4032.c.o [ 20%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/ubxg6010/ubxg6010.c.o [ 21%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/cmsis_boot/startup/startup_stm32f10x_md_vl.c.o [ 22%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/cmsis_boot/system_stm32f10x.c.o [ 24%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/datatimer.c.o [ 25%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/delay.c.o [ 26%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/i2c.c.o [ 27%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/pwm.c.o [ 28%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/spi.c.o [ 29%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/misc.c.o [ 31%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_adc.c.o [ 32%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_dma.c.o [ 33%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_exti.c.o [ 34%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_flash.c.o [ 35%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_gpio.c.o [ 36%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_i2c.c.o [ 37%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_pwr.c.o [ 39%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_rcc.c.o [ 40%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_spi.c.o [ 41%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_tim.c.o [ 42%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_usart.c.o [ 43%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/system.c.o [ 44%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/usart_ext.c.o [ 45%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/usart_gps.c.o [ 47%] Building C object src/CMakeFiles/RS41ng.elf.dir/locator.c.o [ 48%] Building C object src/CMakeFiles/RS41ng.elf.dir/log.c.o [ 49%] Building C object src/CMakeFiles/RS41ng.elf.dir/main.c.o [ 50%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio.c.o [ 51%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_aprs_position.c.o [ 52%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_aprs_weather.c.o [ 54%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_cw.c.o [ 55%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_fsq.c.o [ 56%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_horus_v1.c.o [ 57%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_horus_v2.c.o [ 58%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_jtencode.c.o [ 59%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_wspr.c.o [ 60%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_si4032.c.o [ 62%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_si5351.c.o [ 63%] Building C object src/CMakeFiles/RS41ng.elf.dir/syscalls/semihosting.c.o [ 64%] Building C object src/CMakeFiles/RS41ng.elf.dir/syscalls/syscalls.c.o [ 65%] Building C object src/CMakeFiles/RS41ng.elf.dir/telemetry.c.o [ 66%] Building C object src/CMakeFiles/RS41ng.elf.dir/template.c.o [ 67%] Building C object src/CMakeFiles/RS41ng.elf.dir/utils.c.o [ 68%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/jtencode.cpp.o [ 70%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/JTEncode.cpp.o [ 71%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/encode_rs_int.cpp.o [ 72%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/init_rs_int.cpp.o /home/npc/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp: In member function 'void* JTEncode::init_rs_int(int, int, int, int, int, int)': /home/npc/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp:33:29: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare] 33 | if(symsize < 0 || symsize > 8*sizeof(data_t)){ | ~~~~~~~~^~~~~~~~~~~~~~~~~~ [ 73%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/drivers/si5351/si5351.cpp.o [ 74%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/drivers/si5351fast/si5351mcu.cpp.o [ 75%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/si5351_handler.cpp.o [ 77%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/si5351_test.cpp.o [ 78%] Linking CXX executable RS41ng.elf /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libstdc++_nano.a(eh_globals.o): in function _GLOBAL__sub_I___cxa_get_globals_fast&apos;: eh_globals.cc:(.text.startup._GLOBAL__sub_I___cxa_get_globals_fast+0xc): undefined reference to __dso_handle' /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol `__dso_handle' isn't defined /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [src/CMakeFiles/RS41ng.elf.dir/build.make:1153: src/RS41ng.elf] Error 1 make[1]: *** [CMakeFiles/Makefile2:117: src/CMakeFiles/RS41ng.elf.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 [npc@fedora build]$

Notupus avatar Sep 29 '22 18:09 Notupus

I can add to this issue that with Ubuntu 20.04 lts in wsl 2 I run into the same problem except for me the problem appears as 100 percent, docker instructions as in readme.md

[ 98%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/si5351_test.cpp.o /usr/local/src/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp: In member function 'void* JTEncode::init_rs_int(int, int, int, int, int, int)': /usr/local/src/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp:33:29: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare] 33 | if(symsize < 0 || symsize > 8*sizeof(data_t)){ | ~~~~~~~~^~~~~~~~~~~~~~~~~~ [100%] Linking CXX executable RS41ng.elf /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libstdc++_nano.a(eh_globals.o): in function _GLOBAL__sub_I___cxa_get_globals_fast': eh_globals.cc:(.text.startup._GLOBAL__sub_I___cxa_get_globals_fast+0xc): undefined reference to __dso_handle' /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol __dso_handle' isn't defined /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [src/CMakeFiles/RS41ng.elf.dir/build.make:1073: src/RS41ng.elf] Error 1 make[1]: *** [CMakeFiles/Makefile2:117: src/CMakeFiles/RS41ng.elf.dir/all] Error 2 make: *** [Makefile:91: all] Error 2`

zanco avatar Oct 08 '22 09:10 zanco

Ι checked, for me it hasn't made the bins

On Thu, Oct 6, 2022 at 5:32 PM Ben aka PE2BZ @.***> wrote:

Somehow this is common, happens to me and other users too, however, the .bin and .hex files have been written over here, can be flashed and do work.

— Reply to this email directly, view it on GitHub https://github.com/mikaelnousiainen/RS41ng/issues/23#issuecomment-1270164528, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG5YMOUTBJJFN6DEKZDNKC3WB3PHBANCNFSM6AAAAAAQZA3UME . You are receiving this because you authored the thread.Message ID: @.***>

Notupus avatar Oct 09 '22 10:10 Notupus

I have the same problem ...

linuxmint@linuxmint-virtual-machine:~/Downloads/RS41ng-main$ sudo docker run --rm -it -v $(pwd):/usr/local/src/RS41ng rs41ng_compiler
-- The C compiler identification is GNU 12.2.1
-- The CXX compiler identification is GNU 12.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/src/RS41ng/build
[  2%] Building C object src/CMakeFiles/RS41ng.elf.dir/bmp280_handler.c.o
[  2%] Building C object tests/CMakeFiles/RS41ng_top.dir/morse_test.c.o
[  3%] Building C object tests/CMakeFiles/RS41ng_top.dir/bell_test.c.o
[  4%] Building C object tests/CMakeFiles/RS41ng_top.dir/template_test.c.o
[  6%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs.c.o
[  6%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/aprs/aprs_position.c.o
[  8%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/aprs/aprs.c.o
[  9%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs_position.c.o
[ 10%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/aprs/aprs_weather.c.o
[ 11%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/ax25/ax25.c.o
[ 12%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/aprs/aprs_weather.c.o
[ 13%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/bell/bell.c.o
[ 16%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/horus/horus_common.c.o
[ 16%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/ax25/ax25.c.o
[ 17%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/horus/horus_l2.c.o
[ 18%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/horus/horus_packet_v1.c.o
[ 19%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/bell/bell.c.o
[ 20%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/horus/horus_packet_v2.c.o
[ 21%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/jtencode/lib/crc14.c.o
[ 22%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_common.c.o
[ 24%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/mfsk/mfsk.c.o
[ 25%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/codecs/morse/morse.c.o
[ 26%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_l2.c.o
[ 27%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_packet_v1.c.o
[ 29%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/horus/horus_packet_v2.c.o
[ 29%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/config.c.o
[ 31%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/template.c.o
[ 32%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/crc14.c.o
/usr/local/src/RS41ng/src/template.c: In function 'template_replace':
/usr/local/src/RS41ng/src/template.c:16:5: warning: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit-function-declaration]
   16 |     strlcpy(replacement, CALLSIGN, sizeof(replacement));
      |     ^~~~~~~
      |     strncpy
[ 33%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/mfsk/mfsk.c.o
[ 34%] Building C object tests/CMakeFiles/RS41ng_top.dir/__/src/utils.c.o
[ 35%] Linking C executable RS41ng_top
[ 36%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/morse/morse.c.o
[ 37%] Building C object src/CMakeFiles/RS41ng.elf.dir/config.c.o
[ 37%] Built target RS41ng_top
[ 39%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/bmp280/bmp280.c.o
[ 40%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/pulse_counter/pulse_counter.c.o
[ 41%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/si4032/si4032.c.o
[ 42%] Building C object src/CMakeFiles/RS41ng.elf.dir/drivers/ubxg6010/ubxg6010.c.o
[ 43%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/cmsis_boot/startup/startup_stm32f10x_md_vl.c.o
[ 44%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/cmsis_boot/system_stm32f10x.c.o
[ 45%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/datatimer.c.o
[ 47%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/delay.c.o
[ 48%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/i2c.c.o
[ 49%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/pwm.c.o
[ 50%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/spi.c.o
[ 51%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/misc.c.o
[ 52%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_adc.c.o
[ 55%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_exti.c.o
[ 55%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_dma.c.o
[ 56%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_flash.c.o
[ 57%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_gpio.c.o
[ 58%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_i2c.c.o
[ 59%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_pwr.c.o
[ 60%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_rcc.c.o
[ 63%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_tim.c.o
[ 63%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_spi.c.o
[ 64%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/stm_lib/src/stm32f10x_usart.c.o
[ 65%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/system.c.o
[ 66%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/usart_ext.c.o
[ 67%] Building C object src/CMakeFiles/RS41ng.elf.dir/hal/usart_gps.c.o
[ 68%] Building C object src/CMakeFiles/RS41ng.elf.dir/locator.c.o
[ 70%] Building C object src/CMakeFiles/RS41ng.elf.dir/log.c.o
[ 71%] Building C object src/CMakeFiles/RS41ng.elf.dir/main.c.o
[ 72%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio.c.o
[ 73%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_aprs_position.c.o
[ 74%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_aprs_weather.c.o
[ 75%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_cw.c.o
[ 77%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_fsq.c.o
[ 78%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_horus_v1.c.o
[ 79%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_horus_v2.c.o
[ 80%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_jtencode.c.o
[ 81%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_payload_wspr.c.o
[ 82%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_si4032.c.o
[ 83%] Building C object src/CMakeFiles/RS41ng.elf.dir/radio_si5351.c.o
[ 85%] Building C object src/CMakeFiles/RS41ng.elf.dir/syscalls/semihosting.c.o
[ 86%] Building C object src/CMakeFiles/RS41ng.elf.dir/syscalls/syscalls.c.o
[ 87%] Building C object src/CMakeFiles/RS41ng.elf.dir/telemetry.c.o
[ 88%] Building C object src/CMakeFiles/RS41ng.elf.dir/template.c.o
[ 89%] Building C object src/CMakeFiles/RS41ng.elf.dir/utils.c.o
[ 90%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/jtencode.cpp.o
[ 91%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/JTEncode.cpp.o
[ 93%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/encode_rs_int.cpp.o
[ 94%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/init_rs_int.cpp.o
[ 95%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/drivers/si5351/si5351.cpp.o
[ 96%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/drivers/si5351fast/si5351mcu.cpp.o
/usr/local/src/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp: In member function 'void* JTEncode::init_rs_int(int, int, int, int, int, int)':
/usr/local/src/RS41ng/src/codecs/jtencode/lib/init_rs_int.cpp:33:29: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
   33 |   if(symsize < 0 || symsize > 8*sizeof(data_t)){
      |                     ~~~~~~~~^~~~~~~~~~~~~~~~~~
[ 97%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/si5351_handler.cpp.o
[ 98%] Building CXX object src/CMakeFiles/RS41ng.elf.dir/si5351_test.cpp.o
[100%] Linking CXX executable RS41ng.elf
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7-m/nofp/libstdc++_nano.a(eh_globals.o): in function `_GLOBAL__sub_I___cxa_get_globals_fast':
eh_globals.cc:(.text.startup._GLOBAL__sub_I___cxa_get_globals_fast+0xc): undefined reference to `__dso_handle'
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol `__dso_handle' isn't defined
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/RS41ng.elf.dir/build.make:1153: src/RS41ng.elf] Error 1
make[1]: *** [CMakeFiles/Makefile2:117: src/CMakeFiles/RS41ng.elf.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

guerradr avatar Oct 15 '22 20:10 guerradr

There are lots of comments about building in Docker to prevent strlcpy errors, but I get the exact same error, at the exact same percent complete:

[ 32%] Building C object src/CMakeFiles/RS41ng.elf.dir/codecs/jtencode/lib/crc14.c.o /usr/local/src/RS41ng/src/template.c: In function 'template_replace': /usr/local/src/RS41ng/src/template.c:16:5: warning: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit- function-declaration] 16 | strlcpy(replacement, CALLSIGN, sizeof(replacement)); | ^~~~~~~ | strncpy My whole screen looks almost exactly like guerradr's output

Is there a fix? Rob KB8RCO

KB8RCO avatar Nov 03 '22 14:11 KB8RCO

Removed (commented out) # add_subdirectory(tests) and the strlcpy error went away.

Still working on the if(symsize < 0 || symsize > 8*sizeof(data_t)) error.

KB8RCO avatar Nov 03 '22 17:11 KB8RCO

Apologies for a late reply. The error is indeed originating from the test code. However, I'm having trouble replicating this issue. Fedora 36 (which is used in the Docker container) should have the necessary libraries for this to work correctly.

The warning for strlcpy is NOT an error and does not prevent linking and compilation. Also, the warning about if(symsize < 0 || symsize > 8*sizeof(data_t)){ is not an error and will compile correctly.

The actual error you're getting is about __dso_handle symbol not being defined -- which is something I've never seen before:

/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol `__dso_handle' isn't defined
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value

Which platform are you running Docker on? Is it an x86_64 and a Linux -- or possibly Windows or macOS?

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

Ok, it seems that downloading a newer version of Fedora 36 Docker image causes this error, so they've changed something.

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

I am running docker on Kubuntu 20.04.1.  OS type is 64-bit (Ryzen 3 processor)

Info from cat /proc/version: Linux version 5.15.0-52-generic @.***) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #58~20.04.1-Ubunt u SMP Thu Oct 13 13:09:46 UTC 2022

Any additional information needed?

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 02:25:52 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

Apologies for a late reply. The error is indeed originating from the test code. However, I'm having trouble replicating this issue. Fedora 36 (which is used in the Docker container) should have the necessary libraries for this to work correctly.

The warning for strlcpy is NOT an error and does not prevent linking and compilation. Also, the warning about if(symsize < 0 || symsize > 8*sizeof(data_t)){ is not an error and will compile correctly.

The actual error you're getting is about __dso_handle symbol not being defined -- which is something I've never seen before: /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol `__dso_handle' isn't defined /usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value

Which platform are you running Docker on? Is it an x86_64 and a Linux -- or possibly Windows or macOS?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

KB8RCO avatar Nov 03 '22 18:11 KB8RCO

Thanks. Yeah, this is something that has changed very recently in GCC/G++ compilers and linking. I'll do some investigation.

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

I am new to Docker.  Is there any way to load the previous image?

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 02:32:30 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

Ok, it seems that downloading a newer version of Fedora 36 Docker image causes this error, so they've changed something.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

KB8RCO avatar Nov 03 '22 18:11 KB8RCO

I'm not sure where/when the change has happened, so it's difficult to pinpoint an image -- anyway, this needs to be fixed for new Fedora images too.

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

@KB8RCO @Notupus @zanco @guerradr It seems that the GCC toolchain has changed somehow and this is why you are getting the error about __dso_handle being undefined. I personally do not know much about this error and how to fix it, but one article suggested adding the following line to the very end of src/main.c:

void* __dso_handle;

This seems to make the firmware compile for me, but I do not yet know if the produced binary works correctly.

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

This was the discussion suggesting the above fix:

https://github.com/esp8266/Arduino/issues/39#issuecomment-88866601

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

@KB8RCO @Notupus @zanco @guerradr Please test compilation with the suggested fix above.

mikaelnousiainen avatar Nov 03 '22 18:11 mikaelnousiainen

Compiled with the fix.  build directory has   RS41ng.bin   RS41ng.hexbut I don't see RS41.elf file?

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 02:57:26 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

@KB8RCO @Notupus @zanco @guerradr Please test compilation with the suggested fix above.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 03 '22 19:11 KB8RCO

Last few lines from build:Building /usr/local/src/RS41ng/build/RS41ng.bin   text    data     bss     dec     hex filename  50604    1512    5160   57276    dfbc RS41ng.elf [100%] Built target RS41ng.elf RS41ng build complete

At [100%] Built target RS41.elf but no file is provided in /build. I am away from my RS41 sonde, so even if I get the file, I probably won't be able to program and test it until tomorrow.

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:04:07 PM EDT, Rob Giuliano ***@***.***> wrote:  

Compiled with the fix.  build directory has   RS41ng.bin   RS41ng.hexbut I don't see RS41.elf file?

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 02:57:26 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

@KB8RCO @Notupus @zanco @guerradr Please test compilation with the suggested fix above.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 03 '22 19:11 KB8RCO

@KB8RCO The ELF file will be generated in build/src/RS41ng.elf (as it is documented in the README).

mikaelnousiainen avatar Nov 03 '22 19:11 mikaelnousiainen

Found it!Okay, so I just have to flash one of my RS41SGP sondes with this. I am not using the Si5351, so enabled GPS serial output.  That should give me a 'quick' indication that all is working.I will try and do that this evening, but probably won't be able to until tomorrow.

Thanks for all your help!

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:38:27 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

@KB8RCO The ELF file will be generated in build/src/RS41ng.elf (as it is documented in the README).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 03 '22 19:11 KB8RCO

Well, I programmed the RS41, and I think I bricked it. Nothing seems to be happening, and now the LEDs don't do anything when I press the button. I tried reprogramming it, and get "Error: init mode failed (unable to connect to target)

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:46:40 PM EDT, Rob Giuliano ***@***.***> wrote:  

Found it!Okay, so I just have to flash one of my RS41SGP sondes with this. I am not using the Si5351, so enabled GPS serial output.  That should give me a 'quick' indication that all is working.I will try and do that this evening, but probably won't be able to until tomorrow.

Thanks for all your help!

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:38:27 PM EDT, Mikael Nousiainen ***@***.***> wrote:  

@KB8RCO The ELF file will be generated in build/src/RS41ng.elf (as it is documented in the README).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 04 '22 01:11 KB8RCO

After "can not connect to target" I have to remove a battery, disconnect the programmer, put it back, after which the sonde starts.

Might work for you too?

Op vr 4 nov. 2022 02:16 schreef KB8RCO @.***>:

Well, I programmed the RS41, and I think I bricked it. Nothing seems to be happening, and now the LEDs don't do anything when I press the button. I tried reprogramming it, and get "Error: init mode failed (unable to connect to target)

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:46:40 PM EDT, Rob Giuliano @.***> wrote:

Found it!Okay, so I just have to flash one of my RS41SGP sondes with this. I am not using the Si5351, so enabled GPS serial output. That should give me a 'quick' indication that all is working.I will try and do that this evening, but probably won't be able to until tomorrow.

Thanks for all your help!

Robert Giuliano KB8RCO

On Thursday, November 3, 2022 at 03:38:27 PM EDT, Mikael Nousiainen @.***> wrote:

@KB8RCO The ELF file will be generated in build/src/RS41ng.elf (as it is documented in the README).

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/mikaelnousiainen/RS41ng/issues/23#issuecomment-1302843411, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCFGJSNOFXPP34FSP4ANDDWGRPYJANCNFSM6AAAAAAQZA3UME . You are receiving this because you were mentioned.Message ID: @.***>

zanco avatar Nov 04 '22 05:11 zanco

@zanco Thanks, so it seems the firmware works with the fix above? I can try to test locally today.

@KB8RCO That sounds odd. I think it should not be possible to brick the sonde with any invalid firmware, as the programming interface kind of bypasses everything.

Right after flashing the firmware the sonde needs a full power cycle usually.

mikaelnousiainen avatar Nov 04 '22 05:11 mikaelnousiainen

Apologies for a late reply. The error is indeed originating from the test code. However, I'm having trouble replicating this issue. Fedora 36 (which is used in the Docker container) should have the necessary libraries for this to work correctly.

The warning for strlcpy is NOT an error and does not prevent linking and compilation. Also, the warning about if(symsize < 0 || symsize > 8*sizeof(data_t)){ is not an error and will compile correctly.

The actual error you're getting is about __dso_handle symbol not being defined -- which is something I've never seen before:

/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: RS41ng.elf: hidden symbol `__dso_handle' isn't defined
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: final link failed: bad value

Which platform are you running Docker on? Is it an x86_64 and a Linux -- or possibly Windows or macOS?

I can confirm this error - just now i have forked your repo and build docker compiler under debian. Correction with void* __dso_handle; (put as a global into any source file) works. Can i suggest you (to reproduce) to purge all docker images before build ? It seems something had changed in compiler version used to build image and may be you are still using some previously cached image layers .

miklobit avatar Nov 04 '22 10:11 miklobit

I did power cycled the sonde right after programming.I powered the sonde through the ST-Link per: Steps to flash the firmware

  1. Remove batteries from the sonde2. Connect an ST-LINK v2 programmer dongle to the sonde via the following pins:     * SWDIO -> Pin 9 (SWDIO)     * SWCLK -> Pin 8 (SWCLK)     * GND -> Pin 1 (GND)     * 3.3V -> Pin 5 (MCU switch 3.3V)
  2. Unlock the flash protection - needed only before reprogramming the sonde for the first time  * openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 31 off; exit"   * NOTE: If the above command fails with an error about erasing sectors, try replacing the number 31 with 63:       - openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 63 off; exit"
  3. Flash the firmware   * openocd -f ./openocd_rs41.cfg -c "program build/src/RS41ng.elf verify reset exit"5. Power cycle the sonde to start running the new firmware Since there is no step to "re-install the batteries", I programmed the sonde while powered by the ST-Link dongle.

@zanco You say you had to cycle power.  Two questions:1.  Where you having this issue ("hidden symbol '__dso_handle' isn't defined" before, and it now works with this fix?2. Did you just create the firmware, starting from scratch (new Docker image which has this issue) or from an already working configuration?

Robert Giuliano KB8RCO Message ID: @.***>

KB8RCO avatar Nov 04 '22 11:11 KB8RCO

Hi Robert, sorry for my incomplete reply but I had to go for work and tried to send you a solution for the "bricked RS41".

In short: I did not try any of the fixes yet.

I never program an RS41 powered from the ST-Link. I always have 2 batteries attached and no V+ connection to the programmer. After flashing the RS41 with RS41ng firmware I always get the "init failed" error message for which I have to remove one battery and reconnect it. The power from the ST-Link is nowhere high enough to power the RS41 when starting up for me. So, I would try to put 2 batteries into the RS41 and see if it powers up., Wait a bit, showing signs of life with this firmware by blinking led's takes a bit more time as with the older firmware.

Ben

Op vr 4 nov. 2022 om 12:59 schreef KB8RCO @.***>:

I did power cycled the sonde right after programming.I powered the sonde through the ST-Link per: Steps to flash the firmware

  1. Remove batteries from the sonde2. Connect an ST-LINK v2 programmer dongle to the sonde via the following pins:
    • SWDIO -> Pin 9 (SWDIO)
    • SWCLK -> Pin 8 (SWCLK)
    • GND -> Pin 1 (GND)
    • 3.3V -> Pin 5 (MCU switch 3.3V)
  2. Unlock the flash protection - needed only before reprogramming the sonde for the first time * openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 31 off; exit"
  • NOTE: If the above command fails with an error about erasing sectors, try replacing the number 31 with 63:
    • openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 63 off; exit"
  1. Flash the firmware
  • openocd -f ./openocd_rs41.cfg -c "program build/src/RS41ng.elf verify reset exit"5. Power cycle the sonde to start running the new firmware Since there is no step to "re-install the batteries", I programmed the sonde while powered by the ST-Link dongle.

@zanco You say you had to cycle power. Two questions:1. Where you having this issue ("hidden symbol '__dso_handle' isn't defined" before, and it now works with this fix?2. Did you just create the firmware, starting from scratch (new Docker image which has this issue) or from an already working configuration?

Robert Giuliano KB8RCO Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/mikaelnousiainen/RS41ng/issues/23#issuecomment-1303336519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCFGJXK2G73HYMI5DMGO3LWGT3CVANCNFSM6AAAAAAQZA3UME . You are receiving this because you were mentioned.Message ID: @.***>

zanco avatar Nov 04 '22 12:11 zanco

Ben - Thanks for the reply!I tried fresh batteries and left them in for quite some time.  Pressed the button and waited some time as well (in case default was OFF).No luck. Tried the process again: > Unlock   (I know it shouldn't be needed if programmed once, but it was more a 'connect test') Error: init mode failed (unable to connect to the target) in procedure 'init'   in procedure 'ocd_bouncer'

Program Error: init mode failed (unable to connect to the target) in procedure 'program'   in procedure 'init' called at file "embedded:startup.tcl", line 506 in procedure 'ocd_bouncer' ** OpenOCD init failed ** shutdown command invoked

Pressed button Program Error: init mode failed (unable to connect to the target) in procedure 'program'   in procedure 'init' called at file "embedded:startup.tcl", line 506 in procedure 'ocd_bouncer' ** OpenOCD init failed ** shutdown command invoked

It does not look promising.

Robert Giuliano KB8RCO

On Friday, November 4, 2022 at 08:31:46 AM EDT, Ben aka PE2BZ ***@***.***> wrote:  

Hi Robert, sorry for my incomplete reply but I had to go for work and tried to send you a solution for the "bricked RS41".

In short: I did not try any of the fixes yet.

I never program an RS41 powered from the ST-Link. I always have 2 batteries attached and no V+ connection to the programmer. After flashing the RS41 with RS41ng firmware I always get the "init failed" error message for which I have to remove one battery and reconnect it. The power from the ST-Link is nowhere high enough to power the RS41 when starting up for me. So, I would try to put 2 batteries into the RS41 and see if it powers up., Wait a bit, showing signs of life with this firmware by blinking led's takes a bit more time as with the older firmware.

Ben

Op vr 4 nov. 2022 om 12:59 schreef KB8RCO @.***>:

I did power cycled the sonde right after programming.I powered the sonde through the ST-Link per: Steps to flash the firmware

  1. Remove batteries from the sonde2. Connect an ST-LINK v2 programmer dongle to the sonde via the following pins:
  • SWDIO -> Pin 9 (SWDIO)
  • SWCLK -> Pin 8 (SWCLK)
  • GND -> Pin 1 (GND)
  • 3.3V -> Pin 5 (MCU switch 3.3V)
  1. Unlock the flash protection - needed only before reprogramming the sonde for the first time * openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 31 off; exit"
  • NOTE: If the above command fails with an error about erasing sectors, try replacing the number 31 with 63:
  • openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 63 off; exit"
  1. Flash the firmware
  • openocd -f ./openocd_rs41.cfg -c "program build/src/RS41ng.elf verify reset exit"5. Power cycle the sonde to start running the new firmware Since there is no step to "re-install the batteries", I programmed the sonde while powered by the ST-Link dongle.

@zanco You say you had to cycle power. Two questions:1. Where you having this issue ("hidden symbol '__dso_handle' isn't defined" before, and it now works with this fix?2. Did you just create the firmware, starting from scratch (new Docker image which has this issue) or from an already working configuration?

Robert Giuliano KB8RCO Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/mikaelnousiainen/RS41ng/issues/23#issuecomment-1303336519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCFGJXK2G73HYMI5DMGO3LWGT3CVANCNFSM6AAAAAAQZA3UME . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 04 '22 13:11 KB8RCO

@mikaelnousiainen I can confirm it works with the void* __dso_handle; fix and you can add Tested-by: Notupus <[email protected]> to this patch, I've tested all functions(i2c sensors + MS5351M cause it was what I have in hand, effectively equivilent see https://qrp-labs.com/synth/ms5351m.html )

@KB8RCO I used STM32 ST-LINK Utility on windows since openocd did not recognize my st-link (seems to be a clone but still works)

Notupus avatar Nov 04 '22 13:11 Notupus

@notupusGood to hear it is working!Linux (Kubuntu 20.04LTS) seems to be fine with my ST-Link.  I bought it from Adafruit, along with an SWD breakout for the DFM-17 sonde.  Not much info on those. Do you program with batteries installed, or powered by ST-Link?

Now to figure out if/how I can unbrick my sonde. I have 3 RS41sgp sondes.  Two are unusable (one failed on earth impact - I think, other seems to be bricked).I have been kind of afraid to try the 3rd until someone confirmed it was working.

Robert Giuliano KB8RCO

On Friday, November 4, 2022 at 09:34:04 AM EDT, Notupus ***@***.***> wrote:  

@mikaelnousiainen I can confirm it works with the void* __dso_handle; fix and you can add Tested-by: Notupus @.***> to this patch, I've tested all functions(i2c sensors + MS5351M cause it was what I have in hand, effectively equivilent see https://qrp-labs.com/synth/ms5351m.html )

@KB8RCO I used STM32 ST-LINK Utility on windows since openocd did not recognize my st-link (seems to be a clone but still works)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

KB8RCO avatar Nov 04 '22 13:11 KB8RCO

@notupusGood to hear it is working!Linux (Kubuntu 20.04LTS) seems to be fine with my ST-Link. I bought it from Adafruit, along with an SWD breakout for the DFM-17 sonde. Not much info on those. Do you program with batteries installed, or powered by ST-Link? Now to figure out if/how I can unbrick my sonde. I have 3 RS41sgp sondes. Two are unusable (one failed on earth impact - I think, other seems to be bricked).I have been kind of afraid to try the 3rd until someone confirmed it was working. Robert Giuliano KB8RCO On Friday, November 4, 2022 at 09:34:04 AM EDT, Notupus @.> wrote: @mikaelnousiainen I can confirm it works with the void __dso_handle; fix and you can add Tested-by: Notupus @.> to this patch, I've tested all functions(i2c sensors + MS5351M cause it was what I have in hand, effectively equivilent see https://qrp-labs.com/synth/ms5351m.html ) @KB8RCO I used STM32 ST-LINK Utility on windows since openocd did not recognize my st-link (seems to be a clone but still works) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>

Any power source is adaquate, just wire to pin 6 or 5(make sure that you have enough power, sometimes it turns on and off if the supply cannot give enough power, can use battaries instead, turn on and try connecting.). swd on these can break on landing cause there seems to be some kind of bead.

Notupus avatar Nov 04 '22 14:11 Notupus

@Notupus I just tried a few more things, and now noticed that the ST-Link LED goes out at times. I'll have to try a couple other ports to see if they will supply the needed power.

BTW: can you provide more detail on the Windows STM ST-Link tool you used? I've seen stsw-link007-v3-9-3, stsw-link009, and stm32cubeprg.
I tried stm32cubeprg but it didn't seem to install properly. It may be the restrictions on the computer though.

KB8RCO avatar Nov 07 '22 20:11 KB8RCO

I think I just found out that my ST-Link dongle from Adafruit is fried. My computers (neither Linux now Windows) recognize it any more. Linux LSUSB shows no change in devices on the USB bus when plugged/unplugged. Windows says "USB device not recognized" and won't find any driver for it. The VID and PID report 0x0000. It appears they should be: Vendor ID of 0483 and Product ID of 3748 or 374b. Now, 2 options: replace or find a fix.

KB8RCO avatar Nov 10 '22 21:11 KB8RCO