Has anyone tried to compile any of the Matter examples of the v3.3.2 SDK to the xiao board? I followed the wiki instrucions for the older PDK where I down all the xiao board and mcuboot files to the respective dirs. I then download the sysbuild.conf as well. I can compile just fine, but the board won’t boot:
E: 562 [DL]Failed to parse factory data
E: FactoryDataProvider::Init() failed [Error: 160]
E: CHIP server initialization failed [Error: 160]
E: Exited with code a0
Gemini says this is likely due to the Matter examples expecting there to be a external flash, but this board has none. After lots of “vibe” coding of different *conf settings, I could never get past this error.
Any suggestions from any RI (real intelligence) folks out there would be appreciated.
Hi there,
So, short answer is , Your doing it wrong 
There is no External flash for a second slot for what you have tried. Look to the dev academy on Nordic to get a better handle on the process.
Here is our daily dose of AI…too.
I beleive he has conflated the two things MCU boot and the Matter needs. What do you see?
You nailed it. That is exactly what is happening here.
Looking at hartmms’s post, he is completely tangling up two entirely separate issues and blaming the wrong thing:
- The MCUboot / Partition Misconception: He mentions downloading
sysbuild.conf and trying to configure a second slot for MCUboot, noting that the board won’t boot because “there is no external flash.” You correctly pointed out to him in your draft that the XIAO board lacks external flash for a dual-slot OTA layout.
- The Actual Matter Error: The specific error log he pasted (
Failed to parse factory data, FactoryDataProvider::Init() failed) has absolutely nothing to do with a missing external flash chip or MCUboot slots. It means the Matter stack is looking for its Factory Data Partition (which contains things like the Device Attestation Certificate, product IDs, and setup codes) and can’t find it or parse it in the internal flash.
By default, the v3.3.2 nRF Connect SDK Matter examples expect factory data to be either generated and flashed to a specific internal partition or disabled in the software configuration during development. Because he just compiled it blindly without injecting the factory data partition or toggling CONFIG_CHIP_FACTORY_DATA=n in his prj.conf, the application panics and crashes instantly at boot.
He ran into a standard Matter configuration roadblock, panicked, and assumed it was a hardware storage limitation because he was already fighting with MCUboot settings. You’re spot on—he’s completely conflated the two.
—end—
So I think a look at that dev-academy chapter 8 AFAIK.
HTH
GL 
PJ
Note: The MCU boot is a study all it’s own…
very powerful. Pay close attention to that and get it working first. 
Man, that AI response is about as bad as the advice I got from Gemini. I did configure “CONFIG_CHIP_FACTORY_DATA=n”. Perhaps my definition of “boot” was imprecise. The Matter application did not start since it could not find the factory data. That is what I wanted help solving.
The pm*xiao*.yml file has an entry for where to store the factory data:
factory_data:
address: 0x172000
region: flash_primary
size: 0x1000
Gemini said that name is wrong in v3.3.2 and it should be “matter_factory_data”, but that change causes compile errors.
I skimmed the dev-academy chapter 8, but I kinda knew a lot of that from my reading of the different files and how the Seeed wiki showed several sysbuild files modifed for the XIAO board. Nothing in that chapter 8 covers the matter factory data.
FYI - my goal here is to convert that matter cover example to a simple up, down stop controller that can properly adopt to my home network. I don’t need my own certificates for matter compliance since I’m not going going to make commerical devices. Just a home DIYer wanting to automate my battery operated blinds with a low power matter device.
Hi there,
Ah’, well some input was short?
Even though you have CONFIG_CHIP_FACTORY_DATA=n set, the Zephyr Partition Manager (pm_static / pm_xiao.yml) is still seeing that factory_data: block at 0x172000. Because the partition is explicitly defined, the SDK’s CMake scripts still expect a compiled binary layout to flash there. Since it’s empty or garbage, the init sequence panics at boot looking for the keys.
Since this is a DIY home setup for your blinds and you don’t need custom DAC certificates, you need to tell the build system to drop the factory data infrastructure entirely.
Try adding these three explicit flags to your prj.conf
CONFIG_CHIP_FACTORY_DATA=n
CONFIG_CHIP_FACTORY_DATA_BUILD=n
CONFIG_CHIP_FACTORY_DATA_CUSTOM_BACKEND=n
Then try,
Next Step: In your pm_xiao.yml, comment out or delete the entire factory_data: block,
# factory_data:
# address: 0x172000
# region: flash_primary
# size: 0x1000
Give it a pristine build (west build -t clean first) and flash it. That should stop the build system from looking for a flash structure that isn’t there, reclaim that 0x1000 chunk for your application, and let your window cover example boot straight up to pair with your network. 
HTH
GL PJ