Start up Sequence - SliceKit

[ChrisDev]

Hey folks,

currently I'm trying to build an application that is able to power on and start processing in less than 20 ms.
In an other thread I received the information, that this should be possible if the amount of code and data isn't that big. In my case every tile has to load about 8-10 kByte. The resulting time between the power on and the first outputted signal is about 206 ms.

So I created a quick test, just putting high and low signals on an output pin. This piece of code has a size of 1044 Bytes and it also needs its 205.6 ms (see provided picture)... so I guess there is a kind of startup routine slowing everything extremly down.


In the schematic I've found some hardware which also needs its time to power up, but nothing what could explain a time that big.
So, I'd appreciate it if anybody could provide a timing diagram of the power on sequence.

And a last question, exist any possibility to configure the time needed to power up?

Greets, Chris

[Bianco]

Which exact slicekit are you using?

[ChrisDev]

I'm using a XP-SKC-XL216 SliceKit

[mon2]

Suspecting the boot time is linked to the internal boot rom executing upon first power up. You can also confirm that for your kit, the QSPI mode is being used during boot time - check the QSPI CLK value and activity on the QSPI flash. Believe that is default for the XCORE-200 devices in that QSPI flash is booted in QSPI mode rather than standard SPI (slower) mode. Otherwise, that may be an option to speed up boot time.

The power rail sequencing does deal with a reset supervisor which adds to your power up delays. You could explore options of reset supervisors which may shrink down this delay value but you must confirm if the delays are suitable for your project and stable to use with the XMOS CPUs. For example, some Analog brand reset supervisors are defined by the capacitor values. Not sure of the precision of such parts but we are talking only a few ms of improvement.

Have no hard evidence of this but believe that the OTP rom is booting and reading the entire external QSPI flash before executing your custom code so that may explain your fixed boot time. Wonder if you were to swap out the flash device and use a lower density, would this boot time shrink since the flash fetch time will be less ? An idea to consider.

Alternatively consider to power up -> load your external SPI flash based code and then sit idle in lower power mode and wake up on demand of your external event to perform the required task(s). XMOS should be able to provide additional lower level details of your observation.