the secret BF70x documentation

For anyone trying to evaluate the BF70x for design-in, there are definite gaps in the documentations.

I don't claim to have all the answers, but I'm posting what I've managed to infer in the hopes that it saves someone else some anguish.

  • Lesson 1:

    Figure 36-8 in the Hardware Reference Manual (Revision 0.2, May 2014) is inaccurate/incomplete. Refer to the "BITM_ROM_BCMD_" #define values in "defBF70x_rom.h" in the CrossCore IDE.

  • Lesson 2:

    An essential piece of information not found in any Analog document is the following table that should accompany a corrected version of Figure 36-8:

    NOAUTO BCODE DUMMY ADDR SPEED
    0 ignored ignored ignored ignored
    1 used used used used

    In other words, when NOAUTO is not set, the BCODE, DUMMY, ADDR, and SPEED values are ignored.

  • Lesson 3:

    Table 36-14 in the Hardware Reference Manual and the preceding text implies that selection of "SPIMCODE" (called "BCODE" in "defBF70x_rom.h") controls the Command, Dummy Bytes, and SPI Clock.  However, this is not true.

    SPIMCODE / BCODE appears to only control which command byte is used.

  • Lesson 4:

    Table 36-14 in the Hardware Reference Manual doesn't enumerate what the algorithms and/or assumptions are in booting.

    For example, both SPIMCODE / BCODE modes 0xA " QOR FAST_MODE (Atmel) " and 0xC " QOR FAST_MODE " appear to boot the Winbond W25Q32 populated on the ADZS-BF707-EZBRD.

    However, mode 0xC is at a considerable performance disadvantage to mode 0xA.

    For an unexplained reason, mode 0xC wastes 11-12 milliseconds continuously polling with a RDSR (Read Status Register 05h) command, which costs that much in extra boot time.

    Mode 0xA also issues a RDSR, but only does so for four SPI cycles.  It doesn't seem the polling is waiting for a change of value; it just issues that number of transactions.

  • Here is some collected data on the SPI clock speed in different boot modes using BF707 0.0 silicon on a ADZS-BF707-EZBRD development board.  As you will see, some boot modes appear to be broken.

    BootCMD BCODE SPEED measured SPI clock MHz
    F0210242 1 F 6.25
    80210242 1 8 11.11
    F0220242 2 F 6.25
    80220242 2 8 11.11
    F0230242 3 F 6.25
    80230242 3 8 11.11
    F0640242 4 F 6.25
    80640242 4 8 11.11
    F0680242 8 F 6.25
    80680242 8 8 11.11
    F0690242 9 F 6.25
    80690242 9 8 11.11
    F06A0242 A F 3.125
    806A0242 A 8 3.125
    F06C0242 C F 3.125
    806C0242 C 8 3.125

    The "quad" SPI modes of BCODEs A and C ought to offer extra speed.  However, if the clock rate is stuck, it could erode the advantage and cost boot time.