FAQ: VisualDSP++ Workaround for SPI Boot Anomaly 05-00-0490

Anomaly 05-00-0490 requires a very specific timing element that is unfortunately possible to encounter through normal boot ROM execution.  While the software workaround is a simple fix, it is obviously not possible to modify the ROM code itself.  However, all the processors susceptible to this anomaly also feature the ability to register a "custom boot handler"...if the custom boot handler is exactly the boot ROM code with these minor tweaks, this anomaly is avoided altogether (even for SPI_BAUD=2). The attached ZIP file contains the corrected code to be linked into your project as part of the initialization block to avoid anomaly 05-00-0490, as well as guidance for using it and augmenting it with other initialization customizations that your application may require (changing clock speeds, initializing the external memory interface, etc.).

However, additional protection beyond the custom boot handler is required to prevent the init block itself from encountering the same anomaly, which requires modification of the loader file (LDR) output image containing the application boot stream. The Workaround_Description.pdf file in the attached ZIP archive contains the details regarding the nature of the changes required and how to go about making the changes (based on which revision of VisualDSP++ is being used).

Attachments:
Comments
Anonymous
  • in reply to wallman16

    The workaround code included in the ZIP file is generic to the boot ROM which is common to both the BF52x and BF51x families.  It provides native support of BF51x processors based on built-in switches that are configured inside the IDDE based on project options.  While this stand-alone project was built for and tested on the BF527 EZ-KIT, the SPI_LOAD.asm routine itself and the guidance for implementing the custom boot stream is common to BF51x as well.

  • in reply to vix

    Hi ,

    How about code for BF51x .

    Thanking you

    With best regards and wishes

  • in reply to vix

    The code that is actually in the boot ROMs doesn't change, and you can get a build of that boot ROM code by going through the bk_version.h header to see which THIS_VERSION value selects the code that is in the ROM of your processor. While I cannot say for sure what the files look like between tools revisions, the files themselves indicate the actual source code that is burned into the ROMs of the processors.  This code is UNCHANGED from tools revision to tools revision.  For your BF527 rev 0.2 processor, it is as follows:

    // Note: irrelevant code removed from bk_version.h

    #elif defined(__ADSPBF523__) || defined(__ADSPBF525__) || defined(__ADSPBF527__)

       #if !defined(__SILICON_REVISION__) || (__SILICON_REVISION__ == 2)

                #define BK_THIS_VERSION      0x03

    So, your THIS_VERSION is 0x03.  Comparing the bk_spi.asm file in the 03 directory to the load algorithm above:

    1> The function protocols at the top include all the generic boot ROM functions that configure the part to recognize SPI boot mode and establish a connection with the SPI memory.  These functions run in the boot ROM outside of anything that might arrive at the anomaly, so they are safe and are removed from our patch.  These functions also include all the SPI slave functions irrelevant to this discussion, so these are also removed.  Per this explanation, everything in bk_spi.asm up to line 289 is irrelevant for the comparison.

    2> In the _bootrom.spiboot.master.load routine in SPI_LOAD.asm, the NEWCODE macro at line 111 controls the addition of the DMA disable required between work units to avoid one manifestation of the anomaly.  The rest of the function is identical to the original in bk_spi.asm.

    3> Lines 359-575 of bk_spi.asm are the device detection routine, which is irrelevant and removed.

    4> Lines 575-759 of bk_spi.asm match exactly with SPI_LOAD.asm.  In the _bootrom.spiboot.master.disable function in SPI_LOAD.asm line 327, the NEWCODE macro adds the code to do the dummy read of SPI0_RDBR to clear the possible stuck bit condition for the boot anomaly.

    5> Starting at line 362 of SPI_LOAD.asm are functions that are declared externally in our boot ROM source, but for the purpose of this patch must be local because edits are required to protect against the anomaly.  So, the _bootrom.bootkernel.pdma function matches the same function in the bk_kernel.asm file, except for where we had to account for a stack modification made above, as noted by NEWCODE macro at line 445.  There is also some specific BF54x handling that doesn't apply to you (NEWCODE = 0 at line 519).

    6> In SPI_LOAD.asm, the getport routine is needed by the patch, but it uses the original routine and sub-routines in the ROM, so the code at lines 682-700 simply sets up a call to the original ROM function.

    7> In SPI_LOAD.asm, lines 701 on match exactly the bk_kernel.asm lines 1364-1440.

  • in reply to jobo23

    OK, now everything is clear.

    Nothing is better than a clear and complete explanation...

  • in reply to jobo23

    The files are vastly different because the patch removes all the SPI setup code

    ...

    The part of the boot ROM that is rewritten in the patch is the rest of the boot ROM code that actually performs the DMA and processes the stream as it comes over the SPI port.  This code matches  the bk_spi.asm source except where differentiated by the NEWCODE macro

    I can confirm without any doubt that this code doesn't match the bk_spi.asm included in VDSP++ 5.0 Update 9 for BF52x processor. The problem is not in some parts that have been removed, and other added inside the NEWCODE macro: the files are really different!!

    Please check carefully for the update and the processor I'm referring to.

    I believe that this workaround works for some processors and it is based over the bk_spi.asm file included in some of the past VDSP++ updates, but I'm interested in BF527 and VDSP++ Update 9.

Related