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.
RE: the secret BF70x documentation by pinaz:
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.
RE: the secret BF70x documentation by pinaz:
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.
RE: the secret BF70x documentation by pinaz:
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.
RE: the secret BF70x documentation by pinaz:
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.
RE: the secret BF70x documentation by pinaz:
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.