Build firmware instructions

[vChavezB]

Describe the bug
I cannot build the firmware with the latest rpi-pico sdk.

To Reproduce

git clone https://github.com/raspberrypi/pico-sdk --recurse-submodules
git clone https://github.com/Staacks/gbinterceptor
cd gbinterceptor/firmware
mkdir build && cd build
cmake .. -G Ninja -DPICO_SDK_PATH=../../../pico-sdk
ninja

Expected behavior

No compiler errors when building and binary output in cmake output directory.

Error

/gbinterceptor/firmware/main.c:265:69:` error: unknown type name 'video_probe_and_commit_control_t'
  265 | int tud_video_commit_cb(uint_fast8_t ctl_idx, uint_fast8_t stm_idx, video_probe_and_commit_control_t const *parameters) {

After I add this to tusb_config.h

// RHPort max operational speed can defined by board.mk
// Default to Highspeed for MCU with internal HighSpeed PHY (can be port specific), otherwise FullSpeed
#ifndef BOARD_DEVICE_RHPORT_SPEED
  #if (CFG_TUSB_MCU == OPT_MCU_LPC18XX || CFG_TUSB_MCU == OPT_MCU_LPC43XX || CFG_TUSB_MCU == OPT_MCU_MIMXRT10XX || \
       CFG_TUSB_MCU == OPT_MCU_NUC505  || CFG_TUSB_MCU == OPT_MCU_CXD56 || CFG_TUSB_MCU == OPT_MCU_SAMX7X)
    #define BOARD_DEVICE_RHPORT_SPEED   OPT_MODE_HIGH_SPEED
  #else
    #define BOARD_DEVICE_RHPORT_SPEED   OPT_MODE_FULL_SPEED
  #endif
#endif

// Device mode with rhport and speed defined by board.mk
#if   BOARD_DEVICE_RHPORT_NUM == 0
  #define CFG_TUSB_RHPORT0_MODE     (OPT_MODE_DEVICE | BOARD_DEVICE_RHPORT_SPEED)
#elif BOARD_DEVICE_RHPORT_NUM == 1
  #define CFG_TUSB_RHPORT1_MODE     (OPT_MODE_DEVICE | BOARD_DEVICE_RHPORT_SPEED)
#else
  #error "Incorrect RHPort configuration"
#endif

It starts to compile alas I get more errors due to macros not being defined.

/gbinterceptor/firmware/usb_descriptors.h:29:86: error: 'TUD_VIDEO_DESC_CAMERA_TERM_LEN' undeclared here (not in a function); did you mean 'TUD_VIDEO_DESC_INPUT_TERM_LEN'?

I suspect the firmware was developed for an older version of the rpi-pico sdk, could you mention which tag or hash commit you used from the rpi-pico sdk to reproduce the build.

[vChavezB]

I attempted again to build the project and now it works. Fixed by updating the tinyusb git submodule in the pico-sdk hash commit 2e6142b to the latest release tag 0.14.0.

git clone https://github.com/raspberrypi/pico-sdk --recurse-submodules
cd pico-sdk/lib/tinyusb && git checkout 0.14.0 && cd ../../../
git clone https://github.com/Staacks/gbinterceptor
cd gbinterceptor/firmware
mkdir build && cd build
cmake .. -G Ninja -DPICO_SDK_PATH=../../../pico-sdk
ninja

[Staacks]

Thanks. That should help others. I will add a note about it to the readme.

[maehw]

Thanks for the additional steps. I hope it's okay when I comment on the same issue:

My build shows a warning. Can it be ignored? Or did I miss to configure something?

...
[76/107] Building C object CMakeFiles/gb_interceptor.dir/<some_folder>/pico-sdk/src/rp2_common/pico_stdio_usb/stdio_usb.c.obj
/<some_folder>/pico-sdk/src/rp2_common/pico_stdio_usb/stdio_usb.c:245:2: warning: #warning stdio USB was configured along with user use of TinyUSB device mode, but CDC is not enabled [-Wcpp]
  245 | #warning stdio USB was configured along with user use of TinyUSB device mode, but CDC is not enabled
      |  ^~~~~~~
[107/107] Linking CXX executable gb_interceptor.elf

[Staacks]

Sorry, I had not noticed that warning before. It should not be a problem, though. Earlier versions of the GB Interceptor firmware had a USB serial endpoint enabled by default which I used for debugging. In recent builds I disabled it which basically means that debug message end up nowhere (but those are not triggered while the game is running anyway) unless I explicitly enable the CDC endpoint.
If the warning bothers you, you can simply set pico_enable_stdio_usb to 0 in

gbinterceptor/firmware/CMakeLists.txt

Line 33 in 0ad6aec

pico_enable_stdio_usb(gb_interceptor 1)

but if I am not mistaken, that should not make a difference except for the warning.

[maehw]

I know this issues is closed and I wonder if I should open a new one.

The firmware builds fine. However, when I build locally, my .uf2 file does not run properly. The USB device is listed but when I open it in VLC, I don't see nothing. I've tested this on a GB Interceptor I bought online (https://chaos.social/@maehw/111744070372283492).

Overwriting my locally built one with the release version from github (https://github.com/Staacks/gbinterceptor/releases/tag/v1.2.0) makes it work again. I am quite sure this is not related to the hardware but to my local build. (I use the same git commit, i.e. 0ad6aec - the current HEAD).

Mine: filesize: 605184 bytes, md5 hash: 18781f9109015cc79da16a937391e52c
Mine (when pico_enable_stdio_usb=0): filesize: 605184 bytes, md5 hash: f76dc473397d599912e86ea8e1f09b72
Yours: 605696 bytes, md5 hash: 3207bb44884632f2e607a68629175718

How could I debug this in the best way? Binary diff the .uf2 files, the .hex files?
I use pico-sdk commit 6a7db34 (tag: 1.5.1).

Sorry if I missed something.

[Staacks]

Sorry, I don't have much spare time at the moment, but hopefully I can try a build with entirely clean pulls this evening.

However, I already have a suspicion since you mentioned your pico-sdk version: They still seem to include an old commit of TinyUSB as a subrepository that did not yet include bulk transfer for UVC. I suspect that I pulled the latest commit in this subrepo without realizing that others trying to build would no know about it. So, if you pull the latest TinyUSB in the pico-sdk lib folder, does it fix the build for you?

[maehw]

Thanks for having a look into this! It's very much appreciated.

I tried to pin pico-sdk to commit hash 2e6142b15b8a75c1227dd3edbe839193b2bf9041 and then pin lib/tinyusb to tag 0.14.0, i.e. commit hash 9e91b02ec7fb3502747b5c413a4824654fa7fc7e as mentioned above.

However, this throws TUD_VIDEO_DESC_* errors. This can be reproduced locally and with the GitHub Actions CI)

https://github.com/maehw/gbinterceptor/actions/runs/7519981657/job/20469147860 (Build log)

[Staacks]

Again sorry, did not get around to try today, so just one quick observation and hopefully testing tomorrow:
tinyusb should be at least 0.16.0, because that's when bulk transfer streaming for UVC was introduced.

[maehw]

No worries, Sebastian. Thanks for your quick help - and making your baby an open source software project!

Your hints finally helped, see #26 👍

I pinned pico-sdk to 1.5.1 and tinyusb to 0.16.0 (the most recent release versions speaking of today).

As the include file ...

#include "bsp/board.h"

seems to have moved, I replaced it by

#include "bsp/rp2040/board.h"
#include "bsp/board_api.h"

which makes it build again. (Not sure if this is 100% clean, but it does the trick.)

Happy to hack on this now:

---

Edit: As this is my first rp2040 project.. I am also new to this. I discovered that there is bi_decl() in the pico SDK which can be set from code or CMake file. You could add

    bi_decl(bi_program_description(PROGRAM_DESCRIPTION));
    bi_decl(bi_program_url(PROGRAM_URL));
    bi_decl(bi_program_version_string(VERSION_STRING));

... and maybe also commit hashes of pico-sdk and tinyusb being used for a build. 😄

[vChavezB]

just as a sidenote: would be nice to add a github actions to this project to have reproducible builds 👍

[Staacks]

I know... @maehw has already submitted a pull request. Since I have never used this before I want to take some time to properly look into it, but I am just pushing it up and down my todo list as I am a bit swamped at the moment.