Sorry no, I just added the wrong name of the file, I meant the Kinetis Thread Stack Application Developer's Guide as you can see here.
Sorry for putting the wrong name of file, but in the Thread developers guide you can find the information I referred in the last post about the linker files when using the Fsci_bootloader.
Sorry for the inconveniences cause by the name error.
Just to confirm, when you deploy your example with the HCD, did you make sure that you made the linker file changes mentioned in the BLE Application Developer's Guide? When using the fsci_bootloader you must change the linker file configuration of the project, if you did not make those changes there might be some memory issues , could you please check that and confirm ?
Again, thanks for your patience and your help.
I'm working with Thread, not BLE (though I understand that much of
the information can be applicable to both). So I followed
"Kinetis Thread Stack and FSCI Bootloader Quick Start Guide".
In section 1.4, it says "The user is requested to overwrite
MKW41Z512xxx4_connectivity.ld with the one under
That is what I did. I've attached the original (no_bl...) and the
modified (bl...) loader files.
My understanding is that the fsci bootloader, when working normally,
jumps to the application, and consumes 0 Ram space (i.e. any ram used
by the bootloader is overwritten by the application). Of course,
the bootloader does take some flash space, and the HCD application is
displaced to make room. But even then, I think there is still 100K
of extra flash space.
The difference that I see is that in main.c, the fsci boot loader fills the
the IVT with pointers to various interrupt handlers (for address
0x1c, that would be the default handler). When the HCD application
is built without allowing for the boot loader, the "reserved" IVT
entries get "0" because of the values in startup/startup_MKW41Z4.S
This changes the thread library behavior, when it reads from the
If I understand correctly you have already a network with some nodes , but at a certain point when you have your network and try to add a new device this fails, is this correct?
If this is the case , have you checked the memory ? It is possible that device is getting out of memory depending on you application size and how many devices you have already in your network, in the release notes of the SDK you will fin the footprint for most of the examples, considering that you have the library footprint + the fsci bootloader + your application + the routing table of the network it can be possible that the device is going out of memory.
About the source code of the libraries, I apologize but we do not share the source code of the pre-compiled libraries