My original goal was to optimize the choice of " spiMasterBootCmd " value for booting from a SPI flash, but at the moment, I can't even get adi_rom_Boot() to mimic the boot ROM behavior at reset.
The test setup is an ADZS-BF707-EZBRD, and it has the factory-programmed Power On Self Test in U33.
The factory-programmed image should be the simplest test case. It doesn't have any of the fancy features; the boot ROM should just load the image into RAM and run it.
With SW1 in position 1, pressing RESET (SW2) causes the program to load and the flickering pattern to appear on the yellow LEDs (LED3, LED4, and LED5). This is a success condition to look for in testing.
I have the most simple program that invokes adi_rom_boot():
adi_rom_Boot(0,0,0,0,/* what is the right value? */);
Using CrossCore, I load the program into RAM and run it. However, even though I pick what should be valid values for dBootCommand, the call to adi_rom_Boot() does not cause the processor to boot. Instead, it generates a fault (red LED1).
A logic analyzer shows that the SPI traffic ends prematurely and the SPI clock speed is different from the boot ROM behavior.
Changing the BCMD_SPI_SPEED clock in dBootCommand according to Figure 36-8 in the HRM (or the inconsistent #define values in defBF70x_rom.h) does not produce a corresponding change in the SPI clock speed seen by the logic analyzer. I fear the documentation is incomplete or suspect, or the function prototyping in the CrossCore include files is inconsistent with the boot ROM contents.
Is there at least a known-good set of arguments to the adi_rom_Boot() call above that should produce identical behavior to when the boot ROM runs? That would at least be a starting place for users seeking to optimize settings for their application.
Since Analog has not provided the source code to the boot ROM, it is highly problematic to diagnose its problems.