Project Fails to Build

Question

Project Fails to Build

Closed this issue a year ago · 9 comments

I am trying to compile yapicoprobe for the Raspberry Pi Pico, on the following build system:

OS: Ubuntu 20.04.6 LTS x86_64
CPU: Intel i7-8750H (12) @ 4.100GHz
Memory: 16GB
Toolchain: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
Pico SDK: v1.5.1

I initiate the build with the following steps:

$ git clone https://github.com/rgrr/yapicoprobe
$ cd yapicoprobe
$ git submodule update --init --recursive
$ make cmake-create-release && make all -j

I am greeting with a slew of errors, which I have attached as a logfile below. Could anyone point me in the right direction?

Thanks,
Joseph

make.log

Answer 1 · 2023-07-19T20:07:54.000Z

Not sure if your arm-none-eabi-gcc is the culprit. It seems to be very old.

Could you post the output of make cmake-create-release?

Mine:

hardy@ntbox:/tmp/xxx/yapicoprobe$ make cmake-create-debug
cmake -B _build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DPICO_BOARD=pico  -DPICOPROBE_VERSION_MAJOR=1 -DPICOPROBE_VERSION_MINOR=15 -DPROJECT=picoprobe -DGIT_HASH=83683fa -DCMAKE_EXPORT_COMPILE_COMMANDS=True
Using PICO_SDK_PATH from environment ('/mnt/d/u/pico/pico-sdk')
PICO_SDK_PATH is /mnt/d/u/pico/pico-sdk
Defaulting PICO_PLATFORM to rp2040 since not specified.
Defaulting PICO platform compiler to pico_arm_gcc since not specified.
PICO compiler is pico_arm_gcc
-- 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/arm-none-eabi-gcc - 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/arm-none-eabi-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
Build type is Debug
Using regular optimized debug build (set PICO_DEOPTIMIZED_DEBUG=1 to de-optimize)
PICO target board is pico.
Using board configuration from /tmp/xxx/yapicoprobe/include/boards/pico.h
-- Found Python3: /home/hardy/.local/bin/python3 (found version "3.11.4") found components: Interpreter 
TinyUSB available at /mnt/d/u/pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
System is unknown to cmake, create:
Platform/PICO to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
System is unknown to cmake, create:
Platform/PICO to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
Compiling TinyUSB with CFG_TUSB_DEBUG=1
BTstack available at /mnt/d/u/pico/pico-sdk/lib/btstack
cyw43-driver available at /mnt/d/u/pico/pico-sdk/lib/cyw43-driver
Pico W Bluetooth build support available.
lwIP available at /mnt/d/u/pico/pico-sdk/lib/lwip
mbedtls available at /mnt/d/u/pico/pico-sdk/lib/mbedtls
--------- /mnt/d/u/pico/pico-sdk/lib/tinyusb
-- Configuring done (0.7s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/xxx/yapicoprobe/_build

Answer 2 · 2023-07-19T21:44:38.000Z

I have upgraded to a more recent GCC ARM Embedded toolchain (arm-none-eabi-gcc (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.14)) 11.2.1 20220111) and repeated the steps listed above. Unfortunately, the error persists. I have attached logs which correspond to the make cmake-create-release and make all -j invocations. Unfortunately, the same errors remain.

make-cmake-create-release.log

make-all.log

Answer 3 · 2023-07-20T05:56:19.000Z

My thoughts:

If you compare your and my cmake creation, you will see some differences at the top.

Are you sure that you have the SDK correctly installed? Can you compile SDK examples?

make-all.log says something about gcc 9.4.0, the creation log 11.2.1. Why? And why don't you use anything newer?

It seems that you compiler doesn't like the CFG_TUSB_MEM_SECTION CFG_TUSB_MEM_ALIGN tu_static const ntb_parameters_t ntb_parameters. Rewrite it as static const ntb_parameters_t ntb_parameters. Same some lines below.
Perhaps const is the culprit...

Answer 4 · 2023-07-20T06:09:21.000Z

Nevertheless ncm_device from the original TinyUSB code uses the same construct (CFG_TUSB_MEM_SECTION CFG_TUSB_MEM_ALIGN tu_static const)

Answer 5 · 2023-07-20T18:02:07.000Z

Preliminary

# Double-check build environment
$ make --version # 4.2.1
$ cmake --version # 3.25.1
$ arm-none-eabi-gcc --version # 12.2.1 20230214

# Grab fresh copy of Pico SDK
$ cd /opt && git clone https://github.com/raspberrypi/pico-sdk.git
$ cd pico-sdk && git submodule update --init --recursive

# Grab fresh copy of yapicoprobe
$ cd
$ git clone https://github.com/rgrr/yapicoprobe.git -b v1.15
$ cd yapicoprobe && git submodule update --init --recursive

# Build yapicoprobe
$ export PICO_SDK_PATH=/opt/pico-sdk
$ make cmake-create-release > make-cmake-create-release.log 2>&1
$ make all -j > make-all.log 2>&1

Notes

make-all.log says something about gcc 9.4.0, the creation log 11.2.1. Why? And why don't you use anything newer?

Here, the system reports that my GCC/G++ version is 9.4.0 for the host platform, which will be used to build the elf2uf2 and pioasm utilities. However, it will use the ARM GNU toolchain to build yapicoprobe.

Fixes

At this point, our Cmake logs match closely, but I am still getting some of the same build errors.

It seems that you compiler doesn't like the CFG_TUSB_MEM_SECTION CFG_TUSB_MEM_ALIGN tu_static const ntb_parameters_t ntb_parameters. Rewrite it as static const ntb_parameters_t ntb_parameters. Same some lines below.
Perhaps const is the culprit...

Now, my compiler is unbothered by the libusb types. However, it does still complain about the const discrepancy. In this case, adding const where it is missing creates "assignment of read-only location" errors.

I use the below invocation to make the changes you suggest:

$ find . -type f -not -path '*/\.*' -exec sed -i 's/extern uint8_t tud_network_mac_address/extern const uint8_t tud_network_mac_address/g' {} +
$ sed -i 's/uint8_t tud_network_mac_address/const uint8_t tud_network_mac_address/g' src/get_config.c
$ make all -j > make-all-const-fix.log 2>&1

/home/joseph/yapicoprobe/src/get_config.c: In function 'get_config_init':
/home/joseph/yapicoprobe/src/get_config.c:59:32: error: assignment of read-only location 'tud_network_mac_address[0]'
   59 |     tud_network_mac_address[0] = 0xfe;     // 0xfe is allowed for local use, never use odd numbers here (group/multicast)
      |                                ^
/home/joseph/yapicoprobe/src/get_config.c:62:36: error: assignment of read-only location 'tud_network_mac_address[i]'
   62 |         tud_network_mac_address[i] = uID.id[i + (PICO_UNIQUE_BOARD_ID_SIZE_BYTES - sizeof(tud_network_mac_address))];

make-cmake-create-release.log
make-all.log
make-all-const-fix.log

Answer 6 · 2023-07-20T18:11:29.000Z

Hmmm... obviously now the new compiler is working. How about using unmodified sources?

Answer 7 · 2023-07-20T23:16:28.000Z

If I am only using the SWCLK and SWDIO pins, do I need to do anything with SWDIR and RESET, or may I leave them floating?

Answer 8 · 2023-07-21T05:22:33.000Z

If I am only using the SWCLK and SWDIO pins, do I need to do anything with SWDIR and RESET, or may I leave them floating?

Both are outputs, so there should be no problem leaving them open

Answer 9 · 2023-07-21T05:43:18.000Z

After you can build images which does not work according to #61: what does the probes debug output says?

PS: perhaps you should open another issue...