The questions about Connected Home Over IP (CHIP) on Nordic

[Jacob Lee]

Hi,

We are following the project CHIP and planning on design a matter device with our existing hardware platform.
The below are some questions about it:

1. Our platform is nrf52833 but not nrf52840. We will try to run the door lock example on nrf52833.
What changes do we need for that?

2. Does the lock example show a thorough demonstration of each phase for a matter device?
When the CHIP tool on an Android phone to turn the lock ON, does the command follow the dotdot spec.?

3. What's the schedule about the stable release?
We are planning to develop a matter product based on the SDK in project CHIP.

Thanks a lot,
Jacob

[Karl Ylvisaker]

Hello Jacob,

1. Our platform is nrf52833 but not nrf52840. We will try to run the door lock example on nrf52833.
What changes do we need for that?

Currently, all of our Matter application demos are made for the nRF52840, but fortunately it is quite easy to migrate a project from one device to another, as long as the new devices also fulfills the requirements of the application in terms of features and memory, etc.
In essence, you can follow the same instructions as for migrating a PCA10056 project to an nRF52811 SoC, and just make sure to change out all the nRF52811 specific steps with nRF52833. Additionally, you will have to adjust the RAM and Flash size, but the exact values will depend on what SoftDevice and version you will be using. Please see the RAM and Flash memory adjustment guide for more details. You might also find this answer by my colleague Hung useful.

2. Does the lock example show a thorough demonstration of each phase for a matter device?
When the CHIP tool on an Android phone to turn the lock ON, does the command follow the dotdot spec.?

No, Matter does not use DotDot specification but defines its own data and interaction model. For example it does not use CoAP protocol. Still ZCL clusters are used for data representation. As far as I know, the Android Matter controller is not working as intended right now, but both we and the community is working on this so it should'nt be too long till its up and running.

3. What's the schedule about the stable release?
We are planning to develop a matter product based on the SDK in project CHIP.

We do not discuss roadmaps or future releases here on DevZone, unfortunately. Please contact your Regional Sales Manager (RSM) with this question, as they are better equipped at answering these questions.
The RSM for Taiwan is Richard Chen, and you may contact him on [email protected]

Please do not hesitate to ask if any part of my answer should be unclear! 

Best regards,
Karl

[Jacob Lee]

HiKarl,

I have a concern about memory and code size.
The spec of nrf52833 is 512KB(FLASH)/128KB(RAM) and I am worried about if it can meet the requirement of matter device.

The codesize of lock app in exmaple(nrf52840dk_nrf52840) is over 512KB:
Memory region      Used Size      Region Size        %age Used
FLASH:                   620628 B          1 MB               59.19%
SRAM:                    175617 B          256 KB            66.99%
IDT_LIST:                     0 GB             2 KB              0.00%

And I tried to build nrf52833dk_nrf52833:
         west build -b nrf52833dk_nrf52833

It built failed because the memory overflowed:

/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `rodata' will not fit in region `FLASH'
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `noinit' will not fit in region `SRAM'
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: section .intList VMA [0000000020020000,00000000200200c7] overlaps section noinit VMA [000000002001c900,000000002002cb20]
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 70976 bytes
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: region `SRAM' overflowed by 52001 bytes
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: modules/openthread/build/src/core/libopenthread-mtd.a(ecdsa.cpp.obj): in function `ot::Crypto::Ecdsa::P256::KeyPair::Sign(ot::Crypto::Sha256::Hash const&, ot::Crypto::Ecdsa::P256::Signature&) const':

Since the nrf52833dk_nrf52833 is supported in the zephyr borad list, the memory parameters should be right.

Do you have any idea about the memory requirement of nrfconnect in matter?

thanks,
Jacob

[Karl Ylvisaker]

Hello again Jacob,

Thank you for your continued patience with this. I have been out of office for some days, sorry for the inconvenience.

Jacob Lee said:

I have a concern about memory and code size.
The spec of nrf52833 is 512KB(FLASH)/128KB(RAM) and I am worried about if it can meet the requirement of matter device.

Yes, unfortunately it seems that the Matter Door lock example indeed is too big to fit onto the nRF52833. I was unaware of the high RAM requirements until just now, my apologies - I am terribly sorry for this oversight on my part. My compilation of the Matter examples all require less than 500 kB FLASH, however they all seem to require approximately 148 kB RAM - which indeed is more than the nRF52833 has by default.
What build configuration were you using when you got the requirements you list above, with 620 kB FLASH? You RAM usage seems correct, at least.

Jacob Lee said:

Do you have any idea about the memory requirement of nrfconnect in matter?

I have spoken to our Matter development team, and they have told me that since the protocol is still being tested and developed there is unfortunately no way to estimate this at the current time.

Best regards,
Karl

[Jacob Lee]

Hi Karl,

What build configuration were you using when you got the requirements you list above, with 620 kB FLASH? You RAM usage seems correct, at least.

In current stage I am just testing the example. So I didn't chnage any configuration and use the defaut build instruction (with docker):

west build -b nrf52840k_nrf52840

[Karl Ylvisaker]

Thank you for clarifying this for me - I will test this on my end and see if I see the same memory footprint as you described earlier.

Is there anything else I can help you with regarding the Matter examples at this time?
Please know that you can always open a new ticket if you should encounter any issues or questions during your development in the future.

Best regards,
Karl