Failed to configure project using slc generate for ot-rcp

[inkspot72]

I am trying to create an openthread rcp image for ZBDongle-E.
To run docker as your guide, I ran

docker run --rm -it \
  --user builder \
  -v $(pwd)/build:/build \
  ghcr.io/ksjh/silabs-firmware-builder:4.2.2

When you tried to create a project using slc generate, like below

slc generate \
    --with="EFR32MG21A020F768IM32,bootloader_interface" \
    --project-file="/gecko_sdk/protocol/openthread/sample-apps/ot-ncp/ot-rcp.slcp" \
    --export-destination=ot-rcp-zbdonglee-460 \
    --copy-proj-sources --copy-sdk-sources --new-project --force \
    --configuration=""

An error occurs, and the error message is as follows.

Project configuration is invalid. Check header file configuration. 
The following issues exist: 
ERROR : DOUT is not defined - DOUT is required when PTI enabled, please select pin for DOUT : Location = #define SL_RAIL_UTIL_PTI_DOUT_PORT, SL_RAIL_UTIL_PTI_DOUT_PIN
Forced Generation was requested -- project generating anyway.
Generation location: /build/ot-rcp-zbdonglee-460
Generation: Starting AC generation for ucProject in project ot-rcp: Tue Mar 28 09:09:45 UTC 2023
Generation: Starting AC generation for ProjectPostBuild in project ot-rcp: Tue Mar 28 09:09:45 UTC 2023
Generation: AC content generated for ucProject. Elapsed time: 812ms
Generation: AC content generated for ProjectPostBuild. Elapsed time: 13ms
Generation: Starting project generation for ot-rcp: Tue Mar 28 09:09:45 UTC 2023
Generation: Projects failed ot-rcp.Makefile, ot-rcp.vscode.Makefile

Failed to generate ot-rcp.Makefile for Ot-rcp [ot-rcp]
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/SEGGER_RTT_Conf.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/nvm3_default_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/psa_crypto_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/uartdrv_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/sl_uartdrv_usart_vcom_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/sl_sleeptimer_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/sl_memory_config.h
Failed to copy file:/build/ot-rcp-zbdonglee-460/config/dmadrv_config.h
...

Can you give me a hint as to what's wrong?

Thanks for advance.

[ksjh]

Oh, that is a bit hard to diagnose, but I will try.
The first error in the log is not really a problem, this happens always, even in the original NabCasa firmware builder. Since it uses a feature not relevant for the respective hardware we try to compile for, it does not matter, as the parameter --force is used here.
The next error is a bit trick, I do not see any reason why the generation is reported as failed.

Just to be sure:
So, did you create a directory called build in the current directory and copy the contents of this repo into this ./build directory before starting the docker image?

[inkspot72]

After running the Docker image, the current directory in Docker is ./build, but the source code is not being copied by slc generate.

[inkspot72]

Please make sure that the docker run command entered according to your example is okay.

[inkspot72]

If my attempts to create a project in this docker continue to fail, I plan to run the ot-rcp project in SimplicityStudio and build it with your patchset.

[darkxst]

After running the Docker image, the current directory in Docker is ./build, but the source code is not being copied by slc generate.

You need to create an empty build folder before starting docker, as this is what gets mounted in docker as ./build

[inkspot72]

Before starting docker, I need to create an empty build folder, check out this repository in there, and then bind it locally in docker to use it.
After doing that, the project is well configured and copying source files works fine.

After applying the patch to both the SDK and the platform, I followed the guide to build and the binary was generated just fine. The post-processing to generate the GBL image is also good.

Thanks for the detailed guide.

[ksjh]

If you do this, it should at least generate and you theoretically could compile. But the binaries would still not be right for the hardware. You need to apply the correct patches after the generation process first, before compiling.
Once the generation process works (or even before), I suggest that you look at the Actions above, click on one succesful workflow run there, and fold out every step in the branch for your firmware variant and hardware to see what github is doing inside the docker when building the firmware.

Please note: The current process builds firmware with hardware flow control enabled, but some people noticed that the hardware does not support hardware flow control. You can use this firmware and it works basically, but the promised hardware flow control does nothing due to the hardware implementation.

[inkspot72]

Thanks for the detailed explanation.
I fully understood that the proper patchset needs to be applied to generate the correct hardware firmware.
And you've described the generation process in detail in Actions. I'll look at this and go through the steps again and update.

[inkspot72]

Please note: The current process builds firmware with hardware flow control enabled, but some people noticed that the hardware does not support hardware flow control. You can use this firmware and it works basically, but the promised hardware flow control does nothing due to the hardware implementation.

I'm going to use the ot-rcp configuration for the OpenThread Border Router, so baud rate is important, and I've seen some messages discussing hardware flow control for Dongle-E. Last time I checked, the Dongle-E module seems to work with 460800, so I'll try that.
What about ZB-GW4 1.2? You posted a patch that enables hardware flow control for this hardware module as well, can you confirm this?

[darkxst]

What about ZB-GW4 1.2?

This device has the necessary connections for hardware flow control to work. Dongle-E does not.

[inkspot72]

It would be helpful to know more about those hardware details.

[inkspot72]

@darkxst

• when the new experimental OpenThread RCP builds (Thread only, no Zigbee support) are already installed on the dongle, the current version of the NabuCasa flasher will not work.

This should be fixed in v0.0.10 of NabuCasa flasher, however it does rely on patches to the Openthread SDK so will only work with firmware built using those, so probably wont work with other random community built firmware.

In another discussion thread, I read your comment that the issue with NobuCasa Universal Flasher not working properly for ot-rcp images was fixed in 0.0.10, can you confirm if this is correct?
I'm asking because I ordered the hardware and it hasn't come yet, so I can't confirm whether it's working properly or not.

[darkxst]

It would be helpful to know more about those hardware details.

Neither device has official info on the hardware, its really just the scattering of whats posted in forum posts and the few repos building community firmwares for these.

In another discussion thread, I read your comment that the issue with NobuCasa Universal Flasher not working properly for ot-rcp images was fixed in 0.0.10, can you confirm if this is correct?

I've not tested myself yet if fixed, but the issue was the flasher had no way to put the device into bootloader mode. v0.0.10 added support for this. Alternatively there is always the physical boot button

[darkxst]

Ive tested the Openthread builds from this repo and they work as expected with universal-silabs-flasher (v0.0.12), which will successfully reset into the bootloader for then flashing different firmware.

[inkspot72]

In another discussion thread, I read your comment that the issue with NobuCasa Universal Flasher not working properly for ot-rcp images was fixed in 0.0.10, can you confirm if this is correct?

I've not tested myself yet if fixed, but the issue was the flasher had no way to put the device into bootloader mode. v0.0.10 added support for this. Alternatively there is always the physical boot button

The original physical hardware key combination to enter bootloader mode, was changed to the new rcp spinnel, SPINEL_RESET_BOOTLOADER, which solved the problem.
For this purpose, a new reset reason has been added to NobuCasa Universal Flasher.

[darkxst]

Some hardware doesnt have a physical hardware boot key, but ZBDongle-E (requires disassembly) and ZB-GW04 both do.