Photon and Boron have different MCs. The photon MCU has a proprietary kernel from realtek, the harrow MCU has a Cortex M kernel. Because of this, they have different compilers, and this is probably why we caught the problem with the harrow. Our code is the same for both the harrow and the photon, only the “inside” of the particle itself and the compiler differ. On top of that, all of this is compiled with optimization - parts of the code can be thrown away by the compiler, which gives optimization in terms of memory usage or code execution speed, depending on which level of optimization is selected.
A question for the community
What tools does Particle have for debugging various kinds of failures (e.g. HardFault, memory leak, dead lock...), what code optimization is chosen and how to change it.
Both platforms use the same gcc-arm compiler version with the same compiler optimization options and are not easily changed.
That said, there are significant differences between the Realtek SDK and the Nordic nRF52 SDK. There are also pin differences between the RTL872x and nRF52840 MCUs and these affect some ports and features like PWM. The Photon 2 from Argon Migration Guide outlines some of these differences.
If you are experiencing hard fault, security fault, or deadlock, you should see the firmware introduction.
Perhaps you could also advise where to obtain the memory layout of Boron404x, namely: heap size and start address, stack size and start address, which nrf soft device is used if used, where memory is allocating when os_create api is used (thread stack, mutex, sema, etc), heap, stack usage for the particle network stuff.
