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.
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.
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:
In other words, when NOAUTO is not set, the BCODE, DUMMY, ADDR, and SPEED values are ignored.
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.
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.
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.
Retrieving data ...