Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified ZAP file build error #24591

Closed
mertmzk opened this issue Jan 23, 2023 · 22 comments
Closed

Modified ZAP file build error #24591

mertmzk opened this issue Jan 23, 2023 · 22 comments

Comments

@mertmzk
Copy link

mertmzk commented Jan 23, 2023

Hi,
I wanted to add different endpoints to the lighting example and here the steps I followed and it is giving error when try to build it:

1- Open a existing lighting zap template using Electron and added two additional datapoints
2- Generated zap files using the script ./scripts/tools/zap/generate.py and added them into the path for build
3- cd connectedhomeip

./scripts/checkout_submodules.py --shallow --platform linux

./scripts/build/gn_bootstrap.sh

source scripts/activate.sh

./scripts/build_python_device.sh --chip_detail_logging true

When I try to build the libraries for python getting this error: Does anyone have any suggestion how to fix this?

Checking the environment:

20230123 15:04:38 INF Environment passes all checks!

Environment looks good, you are ready to go!

Done. Made 6328 targets from 317 files in 1902ms
ninja: Entering directory `./out/python_lib'
[1/5] aarch64-linux-gnu-g++ -MMD -MF obj/zzz_generated/lighting-app/test1/lighting-common.IMClusterCommandHandler.cpp.o.d -Wconversion -O0 -g2 -fno-common -ffunction-sections -fdata-sections -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -Wall -Werror -Wextra -Wshadow -Wunreachable-code -Wvla -Wformat -Wformat-nonliteral -Wformat-security -Wno-deprecated-declarations -Wno-missing-field-initializers -Wno-unknown-warning-option -Wno-unused-parameter -Wno-cast-function-type -Wno-psabi -Wno-maybe-uninitialized -fdiagnostics-color -fno-strict-aliasing -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -std=gnu++14 -fno-rtti -Wnon-virtual-dtor -DCHIP_HAVE_CONFIG_H=1 -DCHIP_ADDRESS_RESOLVE_IMPL_INCLUDE_HEADER=\<lib/address_resolve/AddressResolve_DefaultImpl.h\> -DCHIP_MINMDNS_USE_EPHEMERAL_UNICAST_PORT=1 -DCHIP_MINMDNS_HIGH_VERBOSITY=0 -DCHIP_MINMDNS_DEFAULT_POLICY=1 -I../../zzz_generated/lighting-app -Igen/examples/lighting-app/lighting-common -I../../src/include -I../../src -Igen/include -I../../zzz_generated/app-common -I../../config/standalone -I../../third_party/nlassert/repo/include -I../../third_party/nlio/repo/include -I../../third_party/nlfaultinjection/repo/include -I../../third_party/inipp/repo/inipp -I../../zzz_generated -c ../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp -o obj/zzz_generated/lighting-app/test1/lighting-common.IMClusterCommandHandler.cpp.o
FAILED: obj/zzz_generated/lighting-app/test1/lighting-common.IMClusterCommandHandler.cpp.o 
aarch64-linux-gnu-g++ -MMD -MF obj/zzz_generated/lighting-app/test1/lighting-common.IMClusterCommandHandler.cpp.o.d -Wconversion -O0 -g2 -fno-common -ffunction-sections -fdata-sections -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -Wall -Werror -Wextra -Wshadow -Wunreachable-code -Wvla -Wformat -Wformat-nonliteral -Wformat-security -Wno-deprecated-declarations -Wno-missing-field-initializers -Wno-unknown-warning-option -Wno-unused-parameter -Wno-cast-function-type -Wno-psabi -Wno-maybe-uninitialized -fdiagnostics-color -fno-strict-aliasing -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -std=gnu++14 -fno-rtti -Wnon-virtual-dtor -DCHIP_HAVE_CONFIG_H=1 -DCHIP_ADDRESS_RESOLVE_IMPL_INCLUDE_HEADER=\<lib/address_resolve/AddressResolve_DefaultImpl.h\> -DCHIP_MINMDNS_USE_EPHEMERAL_UNICAST_PORT=1 -DCHIP_MINMDNS_HIGH_VERBOSITY=0 -DCHIP_MINMDNS_DEFAULT_POLICY=1 -I../../zzz_generated/lighting-app -Igen/examples/lighting-app/lighting-common -I../../src/include -I../../src -Igen/include -I../../zzz_generated/app-common -I../../config/standalone -I../../third_party/nlassert/repo/include -I../../third_party/nlio/repo/include -I../../third_party/nlfaultinjection/repo/include -I../../third_party/inipp/repo/inipp -I../../zzz_generated -c ../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp -o obj/zzz_generated/lighting-app/test1/lighting-common.IMClusterCommandHandler.cpp.o
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp: In function ‘void chip::app::Clusters::OtaSoftwareUpdateRequestor::DispatchServerCommand(chip::app::CommandHandler*, const chip::app::ConcreteCommandPath&, chip::TLV::TLVReader&)’:
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:854:24: error: ‘chip::app::Clusters::OtaSoftwareUpdateRequestor::Commands::AnnounceOtaProvider’ has not been declared
  854 |         case Commands::AnnounceOtaProvider::Id: {
      |                        ^~~~~~~~~~~~~~~~~~~
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:855:23: error: ‘chip::app::Clusters::OtaSoftwareUpdateRequestor::Commands::AnnounceOtaProvider’ has not been declared
  855 |             Commands::AnnounceOtaProvider::DecodableType commandData;
      |                       ^~~~~~~~~~~~~~~~~~~
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:856:52: error: ‘commandData’ was not declared in this scope; did you mean ‘CommandDataIB’?
  856 |             TLVError = DataModel::Decode(aDataTlv, commandData);
      |                                                    ^~~~~~~~~~~
      |                                                    CommandDataIB
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:856:52: note: maximum limit of 1000 namespaces searched for ‘commandData’
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:860:21: error: ‘emberAfOtaSoftwareUpdateRequestorClusterAnnounceOtaProviderCallback’ was not declared in this scope; did you mean ‘emberAfOtaSoftwareUpdateRequestorClusterAnnounceOTAProviderCallback’?
  860 |                     emberAfOtaSoftwareUpdateRequestorClusterAnnounceOtaProviderCallback(apCommandObj, aCommandPath, commandData);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                     emberAfOtaSoftwareUpdateRequestorClusterAnnounceOTAProviderCallback
../../zzz_generated/lighting-app/test1/IMClusterCommandHandler.cpp:860:21: note: maximum limit of 1000 namespaces searched for ‘emberAfOtaSoftwareUpdateRequestorClusterAnnounceOtaProviderCallback’
At global scope:
cc1plus: note: unrecognized command-line option ‘-Wno-unknown-warning-option’ may have been intended to silence earlier diagnostics
ninja: build stopped: subcommand failed.
@bzbarsky-apple
Copy link
Contributor

bzbarsky-apple commented Jan 23, 2023

The output above looks like you generated the lighting-app bits from old XML and are now trying to compile them against data model headers documented from new XML... At some point the command in the XML got renamed from AnnounceOtaProvider to AnnounceOTAProvider

@mertmzk

@mertmzk
Copy link
Author

mertmzk commented Jan 24, 2023

Thanks @bzbarsky-apple . I was generating zap files on host machine and transfering it to raspi for compilation. Genereating them on raspi has fixed the issue.

@mertmzk mertmzk closed this as completed Jan 24, 2023
@bzbarsky-apple
Copy link
Contributor

@mertmzk Sounds like the host machine has an old SDK version...

@mertmzk
Copy link
Author

mertmzk commented Jan 25, 2023

@bzbarsky-apple thanks, I am getting other error now. I have got 2 endpoint in device model and compiled the libraries based on zap generated files, but when try to toggle it using chip-tool getting this error:
lighting-app-modified.zap.txt

chip-tool onoff toggle 0x1234 0x2

CHIP:TOO: Run command failure: IM Error 0x0000057F: General error: 0x7f (UNSUPPORTED_ENDPOINT)

toggling endpoint 1 is working fine. What is the step that I am missing?

@bzbarsky-apple
Copy link
Contributor

@mertmzk What does the generated endpoint_config.h look like?

And just to check a common edge case: you're sure the chip-tool onoff toggle command is going to the right server app?

@mertmzk
Copy link
Author

mertmzk commented Jan 25, 2023

@bzbarsky-apple Attaching the file. The endpoint is defined there as well.
endpoint_config.h.txt

yes I am pretty sure it is accessing the right server, also monitored the command is received on server side.

@bzbarsky-apple
Copy link
Contributor

@mertmzk That all looks correct. The only thing I see remaining is that the header that is attached is not the header that is actually being included during the build....

@mertmzk
Copy link
Author

mertmzk commented Jan 25, 2023

@bzbarsky-apple I am calling them from python generated libs as follow: Do you think any modification needed on this

from chip.server import (
    GetLibraryHandle,
    NativeLibraryHandleMethodArguments,
    PostAttributeChangeCallback,
)

from chip.exceptions import ChipStackError

import sys
import os

from gpiozero import LED

led = LED(17)

@PostAttributeChangeCallback
def attributeChangeCallback(
    endpoint: int,
    clusterId: int,
    attributeId: int,
    xx_type: int,
    size: int,
    value: bytes,
):
    if endpoint == 1:
        if clusterId == 6 and attributeId == 0:
            if len(value) >= 1 and value[0] == 1:
                print("[PY] light on")
                led.on()
            else:
                print("[PY] light off")
                led.off()

chipLib = GetLibraryHandle(attributeChangeCallback)

input('Press enter to quit')

sys.exit(0)

@bzbarsky-apple
Copy link
Contributor

@mertmzk I have no idea how the Python bits work, or how they were compiled in your case.... @andy31415 or @tehampson might be able to help you with the Python part.

@andy31415
Copy link
Contributor

@mertmzk also to make sure Generated zap files using the script ./scripts/tools/zap/generate.py and added them into the path for build ... latest ToT uses compile-time codegen, so generating zap files using the script and adding them into the path should not be necessary / may actually conflict with other files.

If you use pre-generated directory that may be fine, however without that, the generation step feels wrong (unless it is 1.0, in which case you need to codegen)

Could you list branch and commands used?

@andy31415
Copy link
Contributor

This would explain a "header attached is not the one actually included in the build"

@andy31415
Copy link
Contributor

Maybe check your out/build directory if some endpoint_config.h exists there and is generated. My guess is that you tried to manually generate files and add includes, but the compile time codegen also generates its own copy and maybe those end up being used.

I do not quite understand however if that should conflict ... if you codegen from the same zap file, one would expect the same result.

@mertmzk
Copy link
Author

mertmzk commented Jan 26, 2023

@andy31415 I am following the steps here: https://community.arm.com/arm-community-blogs/b/internet-of-things-blog/posts/build-a-matter-home-automation-service-using-raspberry-pi-arm-virtual-hardware-and-python

I checkout to the v1.0.0.2 and only updating the zap file in ligting_app before building the device model. I don't think compile time codegen is working as If I remove zap generated files, the build process is failed with missing files error.

I also tried to generate the zap files and build it, but only endpoint 1 is functional not endpoint 2.

@mertmzk
Copy link
Author

mertmzk commented Jan 26, 2023

@andy31415 @bzbarsky-apple if I replace the existing zap files with script-generated zap files the build is failing with this error:

../../zzz_generated/lighting-app/zap-generated/endpoint_config.h:644:5: error: conversion from ‘int’ to ‘EmberAfDefaultOrMinMaxAttributeValue’ is ambiguous
  644 |     }
      |     ^
../../src/app/util/attribute-storage.cpp:85:71: note: in expansion of macro ‘GENERATED_ATTRIBUTES’
   85 | constexpr const EmberAfAttributeMetadata generatedAttributes[]      = GENERATED_ATTRIBUTES;
      |                                                                       ^~~~~~~~~~~~~~~~~~~~

@andy31415
Copy link
Contributor

That seems to be using an invalid combination of zap and source code. Likely some type safety error between int and other types.

Indeed, v1.0.0.2 build would not use compile time codegen. You would have to use the zap as in the zap repo in third_party submodules.

@andy31415
Copy link
Contributor

If you replace an example app zapfile, I believe running zap_regen_all.py should regenerate everything (you can probably also generate.py a single file, however I do not know the arguments that it is supposed to get)

@mertmzk
Copy link
Author

mertmzk commented Jan 26, 2023

@andy31415 Yes this is what I have been doing using below command but when compiling it is giving conversion error.

./scripts/tools/zap/generate.py examples/lighting-app/lighting-common/lighting-app.zap -z src/app/zap-templates/zcl/zcl.json -o zzz_generated/lighting-app/zap-generated/

Would you be able to try it on your side and suggest what might be wrong, attaching the zap file:
lighting-app-modified.zap.txt

@bzbarsky-apple
Copy link
Contributor

but when compiling it is giving conversion error.

Which ZAP version are you using? Tip ZAP does not work with 1.0.0.2; the format of the data table in endpoint_config.h has changed since then. You should use whatever ZAP version was current at that point....

@mertmzk
Copy link
Author

mertmzk commented Jan 26, 2023

@bzbarsky-apple I am using the latest zap. Which version of the SDK compatible with latest ZAP?

@bzbarsky-apple
Copy link
Contributor

The relevant change on the SDK side was faa7b08933b52c72387e7d5f4baf8e7b7852de59 (#24336).

The relevant change on the ZAP side was 9e7cabbc6b7c56e81fa8af61c66ad53fda160a78 (tag: v2023.01.09-nightly).

So if your SDK is anything that contains faa7b08933b52c72387e7d5f4baf8e7b7852de59 in it (e.g. tip), you need a ZAP that is v2023.01.09-nightly or newer. If your SDK does not contain faa7b08933b52c72387e7d5f4baf8e7b7852de59 then you need a ZAP that is v2023.01.06-nightly (aka bedd8db08d6eaec19b1873c1d48adf39118fb5f6) or older.

More generally, for any given SDK commit, I would determine ZAP as follows:

  1. If there is a ZAP submodule, use whatever version is there, because that's the one that was tested with that SDK version.
  2. If there is no ZAP submodule (i.e. your SDK is aa9b0c50c8ede5e38bb57fc2a422e698d665ef08 or newer), look at what ZAP_VERSION is set to in integrations/docker/images/chip-build/Dockerfile.
  3. In the future, if we move ZAP out of docker (which we might be with Add zap to CIPD setup #24630), look for the version in scripts/zap.json.
  4. In the even more distant future, I don't know yet.

@mertmzk
Copy link
Author

mertmzk commented Jan 27, 2023

@bzbarsky-apple thanks. I have checkout the lates on both. The SDK has got faa7b08933b52c72387e7d5f4baf8e7b7852de59 and zap has got v2023.01.09-nightly , but getting below error now:

FAILED: obj/src/controller/python/chip/_ChipServer.so obj/src/controller/python/chip/_ChipServer.map 
aarch64-linux-gnu-g++ -O0 -fPIC -Werror -Wl,--fatal-warnings -Wl,-z,defs -fdiagnostics-color -Wl,--gc-sections -Wl,-Map,obj/src/controller/python/chip/_ChipServer.map @obj/src/controller/python/chip/_ChipServer.so.rsp -o obj/src/controller/python/chip/_ChipServer.so -shared
/usr/bin/ld: obj/zzz_generated/lighting-app/zap-generated/lighting-common.IMClusterCommandHandler.cpp.o: in function `chip::app::Clusters::LevelControl::DispatchServerCommand(chip::app::CommandHandler*, chip::app::ConcreteCommandPath const&, chip::TLV::TLVReader&)':
/home/pi/connectedhomeip/out/python_lib/../../zzz_generated/lighting-app/zap-generated/IMClusterCommandHandler.cpp:747: undefined reference to `emberAfLevelControlClusterMoveToClosestFrequencyCallback(chip::app::CommandHandler*, chip::app::ConcreteCommandPath const&, chip::app::Clusters::LevelControl::Commands::MoveToClosestFrequency::DecodableType const&)'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Can you please suggest me a tested version, ideally option 1 where zap is submodule.

@mertmzk
Copy link
Author

mertmzk commented Jan 27, 2023

@bzbarsky-apple nevermind that error was related to enabling unnecessary cluster. Disabling it fixed the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants