Post Go back to editing

bfrom_SpiBoot using Revision .1 vs .2 (BF527)

The API bfrom_SpiBoot works with .2 of the die for the BF527.  But, when the same code is loaded onto a Revision .1 API does not return it is in a loop @ 0xEF000486.

Is there a difference in the API between the two revisions?  The source is only available for .2 and not .1?

Tim

  • Hi,

    To assist you better, can you get back on the below points

    1) Can you first try with simple LED blink as main application, store it in different sector and try to boot with the calling application?
    2) Is it working in debug mode?
    3) Are you using Hook routine functionality in bfrom_SpiBoot() API. If so, it will not functional for 0.1 revision.
    4) Are you using CCES or VisualDsp?

    However, we would also like you to confirm if you are not hitting anomaly at any point.  The silicon anomaly sheet can be downloaded from the below link.
    www.analog.com/.../ADSP-BF523-BF525-BF527-anomaly.pdf

    Regards,
    Anand Selvaraj.

  • >1) Can you first try with simple LED blink as main application, store it in different sector and try to boot with the calling application?

    Tim>  The application has been working for +10 years using a Revision of .2, From .2 to Revision .1 it does not work. Tracing the BOOT ROM, it gets into a light jump loop.

    >2) Is it working in debug mode?

    Tim>On revision .2 Debug/Release worked fine.  Will use the any Revision selection for the project.  Or should the Revision be .1?  This is selected on the project screen in visualDSP

    >3) Are you using Hook routine functionality in bfrom_SpiBoot() API. If so, it will not functional for 0.1 revision.

    Tim>Yes, I was trying to use the Hook API to validate the the API was working for .1.  Since it is not supported in .1, will pass a NULL.

    >4) Are you using CCES or VisualDsp?

    Tim>Using VisualDSP.  

    Programming the SPI with the original code, the processor will boot from Power ON.  I changed the code to idle for 5 seconds and call bfrom_SpiBoot()  with an offset of 0, that should reboot the same application, it does not.  The processor is in a tight jump loop in the BOOR ROM.

    Tim

  • Hi,

    As mentioned in anomaly (05000395) Hook routine function in bfrom_SpiBoot() is not functional in Revision 0.1. Could you please change silicon revision 0.1 and try to flash simple application without Hook routine functionality. However, we would also like you to confirm if you are not hitting any other anomaly at any point.  The silicon anomaly sheet can be downloaded from the below link.
    www.analog.com/.../ADSP-BF523-BF525-BF527-anomaly.pdf

    Regards,
    Anand Selvaraj.

  • 1.  Hook was removed. 

    2. It is a small application.  It boots from flash without an issue.  There is a 5 second pause then the bfrom_SpiBoot() is called.  The goal is to reload the same code again.  The following arguments are passed.

        s32 dFlags = BFLAG_PERIPHERAL| 5 ;  

        s32 res = bfrom_SpiBoot(0, dFlags, 0, 0);

    The function does not return and loops at address EF000486.  does .1 need a number of blocks?

    Tim

  • Tracing the .1 boot loader, the SPI boot ROM is not being read properly or SPI is not being setup properly in the boot routine.

    tline 544:

    /*******************************************************************************/
    /*                                                                             */
    /*   If still no valid reply, likely no memory is connected or it is not       */
    /*   proberly programmed: Abort.                                               */
    /*                                                                             */
    /*******************************************************************************/
        
        
        CC = r6 == 0;
        call _bootrom.assert.inverse;

    r6 is 0 and calls into the _bootrom.assert.inverse and loops.

    SPI has a valid boot image, it boots from power on.   What should PORTG_FER and PORTG_MUX be?  Does .1 setup these registers?

  • Hi,

    This issue is already handled through private support. To avoid duplication of efforts,You can the continue the discussions through private support and final resolution here if appropriate.

    Regards,
    Anand Selvaraj.