Post Go back to editing

Minimizing Initialization time... apart from Calibration

Category: Datasheet/Specs
Product Number: ADRV9002

In cases where total cold-start boot-up time is of supreme importance, are there factors in the initialization that can substantially (say, ~50%) reduce the time from the UG-1828 example of 2.5 seconds?  E.g., for starters, if it is a 1T1R design, could that save substantial time vs. 2T2R?

  • Hi Brain,

    We will get back to you shortly. We are looking into this.



  • Hi Brain,

    The initialization process comprises four essential steps:

    • Hardware initialization
    • Resource loading
    • ARM startup and verification

    Other configuration such as carrier frequencies, PLLs etc.

                                         Figure 1

    The figure 1 shows the line up with in the initialization process, first it turns on the hardware, loading the resource, then stating up the arms and wait till it is booted properly and proceed with the rest of the configurations.

    To expedite this process, several optimization methods can be implemented:

    • Utilizing SPI streaming instead of standard SPI transactions can reduce initialization time by approximately 0.5 seconds due to a decrease in overhead bytes. Since standard SPI transaction will send 1byte of data with 2 byte of address meaning there's two bytes of overhead for every one byte of payload but in SPI streaming will send 4 byte of data with 2 byte address.
    • Increasing the SPI clock rate allows for faster data transmission, leading to quicker device boot-up and a potential improvement of around 0.5 seconds in initialization time. The maximum SPI clock rate is 44MHz.
    • Optimizing the configuration stage can further enhance the efficiency of the initialization process.

                                            Figure 2

    In the adi_adrv9001_user.h file in the SDK, there are a set of user editable macros.  There’s a large section of this where they can experiment with changing the interval time of various processes. By default, we optimise these to reduce SPI traffic but it is possible to edit these intervals for their own system to optimise the boot timing. For example, from the below, the ‘verify arm checksum’ process interval is set to 5000 us but they might experiment with setting this to 1000 us for example. If they optimise these interval delays for their system, they could be able to reduce the overall boot-up timing.

                                                Figure 3

    • Prioritizing single transmission and reception setups over dual setups can minimize setup time, such as configuring attenuation solely on the transmitter path rather than both paths. But these time saving will be minimal.
    • Additionally, removing redundant code from extracted sample code can contribute to time . Please keep a track of the changes made within the code.
    • Warm bootup is another option for reducing the time within calibration. Please refer to user guide for more information.