Start up Sequence - SliceKit

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
ChrisDev
Member
Posts: 13
Joined: Tue Jan 31, 2017 8:45 am

Start up Sequence - SliceKit

Post by 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.
Image

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


User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

Which exact slicekit are you using?
ChrisDev
Member
Posts: 13
Joined: Tue Jan 31, 2017 8:45 am

Post by ChrisDev »

I'm using a XP-SKC-XL216 SliceKit
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by 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.
Post Reply