Failure to build under docker and fedora workstation

[Notupus]

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':
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]$

[zanco]

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_GLOBALsubIcxa_get_globals_fast': eh_globals.cc:(.text.startup._GLOBALsubIcxa_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`

[Notupus]

Ι 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: @.***>

[guerradr]

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

[KB8RCO]

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]

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.

[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?

[mikaelnousiainen]

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

[KB8RCO]

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: @.***>

[mikaelnousiainen]

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

[KB8RCO]

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: @.***>

[mikaelnousiainen]

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]

@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]

This was the discussion suggesting the above fix:

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

[mikaelnousiainen]

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

[KB8RCO]

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]

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: @.***>

[mikaelnousiainen]

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

[KB8RCO]

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]

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: @.***>

[zanco]

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: @.***>

[mikaelnousiainen]

@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.

[miklobit]

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 .

[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"
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: @.***>

[zanco]

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"
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: @.***>

— 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: @.***>

[KB8RCO]

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)
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: @.***>

— 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: @.***>

[Notupus]

@mikaelnousiainen I can confirm it works with the void* __dso_handle; fix and you can add Tested-by: Notupus <notpp46@googlemail.com> 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)

[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: @.***>

[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: @.>

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.

[KB8RCO]

@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]

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]

Verified: New ST-Link V2 dongle allowed me to program 2 of the RS-41s I have. One was "untouched" so I was confident it was okay. The second was one of the units I was afraid was "BRICKED". The cheap ST-Link does not supply enough power for the RS41.

Also. The 2mm header did not allow my ribbon cable to connect properly - too wide and plastic interfered. I had to break off some of the plastic along the edge of the connector.

Rob KB8RCO

[KB8RCO]

I disposed of the sonde that had a bad daughter board. It did not power up at all anymore. I now program the sondes with batteries installed, and that seems to work.

I was able to program the other 2 sondes with OM3BC's rtty.hex file. That seems to work, and I can decode it with my SDR dongle and Direwolf. I had to use the older STM32 ST-Link utility on my laptop as STM32CubeProgrammer didn't want to work.

I reprogrammed rs41ng into the sonde. STM32 ST-Link utility didn't show ELF files in the file listing for ">File >Open", so I used the rs41ng.hex file. I assume the rs41ng.bin is the same since they are from the same source. The audio sounded good, but the RTL / Direwolf combo doesn't seem to decode it. Also, it is transmitting very often - probably my settings. I messed around with some audio settings, but never got it to decode.

I went back to rtty and it decoded.

I'll have to go back and try my docker configuration again. Verify my parameters, recompile, and try reprogramming through docker or my laptop.

Any reason I shouldn't use the bin or hex files?

---

Rob KB8RCO

[KB8RCO]

So, I started from scratch again! $ git clone https://github.com/mikaelnousiainen/RS41ng copied my config.h file that I had edited with call, etc. went back to the main directory $ docker run --rm -it -v $(pwd):/usr/local/src/RS41ng rs41ng_compiler all compiled properly Already unlocked, so I used openocd $ openocd -f ./openocd_rs41.cfg -c "program build/src/RS41ng.elf verify reset exit"

Output: _Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 1000 kHz adapter_nsrstdelay: 100 none separate RS41 Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : clock speed 950 kHz Info : STLINK v2 JTAG v39 API v2 SWIM v7 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 3.252024 Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000320 msp: 0x20000d30 Programming Started auto erase enabled Info : device id = 0x10016420 Info : flash size = 64kbytes Error: stm32x device protected Error: failed erasing sectors 0 to 51 Programming Failed shutdown command invoked****

[KB8RCO]

UPDATE: changed openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 31 off; exit" to openocd -f ./openocd_rs41.cfg -c "init; halt; flash protect 0 0 63 off; exit" Programming Started auto erase enabled Info : device id = 0x10016420 Info : flash size = 64kbytes target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc wrote 53248 bytes from file build/src/RS41ng.elf in 3.305405s (15.732 KiB/s) Programming Finished Verify Started target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc verified 52244 bytes in 0.834288s (61.153 KiB/s) Verified OK Resetting Target shutdown command invoked

Looks like it programmed that time wit RS41ng.elf file. Now to let it run.

[mikaelnousiainen]

Thanks for the discussion and final resolution. I'm going to close this issue and add the changes to fix compilation.

Regarding removing flash protection: I'm not entirely sure about the sector count -- could it have something to do with the OpenOCD version? Sometimes 31 works fine and sometimes one needs 63. This is documented in README.

If someone knows better, please open another issue!

[KB8RCO]

I think the question should be how many sectors the chip has.  Wouldn't it be best to unlock them all, or as many as possible.  Might be better to start with 63.  

Rob KB8RCO

Sent from Yahoo Mail on Android

On Mon, Nov 21, 2022 at 16:53, Mikael @.***> wrote:

Thanks for the discussion and final resolution. I'm going to close this issue and add the changes to fix compilation.

Regarding removing flash protection: I'm not entirely sure about the sector count -- could it have something to do with the OpenOCD version? Sometimes 31 works fine and sometimes one needs 63. This is documented in README.

If someone knows better, please open another issue!

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

[mikaelnousiainen]

@KB8RCO That might be the case as well, I'm not sure. I can reverse the order of commands in the docs, so one can try 63 first and then 31.

[mikaelnousiainen]

@KB8RCO Done