We’re taking a cursory look at using Particle and can see our application quickly exceeding the allocated 128 kB of user application space.
Does anyone know when/if support for XIP from the 4MB external flash will be added to deviceOS?
@jpaustin, what was your application space assessment based on? The Particle deviceOS includes many of the library functions normally having to be included in the user application.
As for XIP, there is no current plan (that I know of) to use the external flash for XIP. Instead, it would be used for external user data storage using a file system (Posix capable). This might manifest itself in Q1 2020 but there has been no official word from Particle.
@peekay123 thanks for clarifying 
Much of our original code was written for the nRF52840 (w/o a modem in our current prototype). The main allure of Particle is that deviceOS would take care of BLE (to talk with our companion app) and LTE (to transmit data to the cloud) without much setup from our end.
Unfortunately, there’s a rather complicated library we currently use that handles data synchronization between our servers and the device. We’re taking a look at ways of reducing the footprint of this library but we still have other code (e.g. drivers for motors, screen, and a handful of sensors) that would still likely put us over 128kB of user space without some rather extensive wringing on our end to shrink our code.
One option we’ve thrown around is finagling with deviceOS (which seems to already support XIP for the included 4MB of flash per this changelog) and introducing another bank of flash from which the device can XIP. We’re not sure what the technical challenges are with regards to this (or if it’s even possible) but we are trying to do due diligence.
@jpaustin, that XIP support is for the nRF5 SDK and is not carried forward in the DeviceOS that I know of. The challenge you will have trying to implement XIP is with the OTA and the dynamic links required to allow for the segregation of DeviceOS and User Application OTA updates. Implementing XIP would 'break" the code layout as currently implemented. Adding another QSPI flash device would also require a hardware redesign and a possible FCC re-certification of the new board.
Perhaps @rickkas7 can inject some wisdom here.
It’s not currently possible to use XIP from the QSPI flash. Aside from the just being able to execute, there are a large number of other issues, like building apps that load into non-contiguous blocks of flash, handing OTA, etc… It’s also not possible to add another flash chip to the QSPI bus, because it’s physically a separate SPI bus, and is not exposed.
1 Like