Hi TI,
We’ve had our application up-and-running on a pair of DC6727BGDH250 DSPs for a while now. Our configuration boots both DSPs from a host via the HPI bus. We first load a “stage 2 bootloader” (with “stage 1” being the DSP’s ROM-resident bootloader) at the top of SRAM, which configures the PLL and EMIF registers, tells the host it’s done by setting an SRAM flag, and then enters a “wait” loop until the host clears the flag telling S2 it’s OK to jump to the app code. S2 also provides state change info to the host so that these steps can be verified. When S2 is finished, the host completes loading the app code segments into SRAM and SDRAM and flags S2 to jump to the app start address. Before loading the app code, the host also runs a test on the portion of SRAM used as “scratchpad” by the ROM bootloader (0x10000400-0x10000FFF per SPRAA69D–September 2009, §10) via the HPI bus, which can’t be tested until the S1 bootloader is done with it.
The DSPs boot fine about 95% of the time. However, the other 5% of the time, the S2 bootloader appears to go insane and falsely sets the flag indicating to the host that it’s done before the state info it’s been giving the host agrees. Two other things also happen. First, when the host runs the scratchpad SRAM test, it now fails, indicating that either the S1 bootloader is still changing this SRAM area or that the S2 bootloader is doing wild writes to an area it normally wouldn’t touch. Second, the host’s HPI bus interface HW is occasionally flagging an error condition on HPI bus accesses in that it’s taking > 2uS to gain access to the HPI bus, indicating that the DSP may be holding-off host accesses to DSP memory by continuously accessing it.
In debugging this scenario, we checked the TI support site and were reminded of the SPRS277 ROM patch for this device, which we had overlooked. We’re in the process of applying it, as we think the lack of it may be the root cause of our problems, and have a few associated questions.
1) SPRS277 says the patch applies to “ROM version C9230C100,” while the “bootloader revision” value we read from ROM location 0xc (the “bootloader revision register”) is 0xC9230C10 (which agrees with spraa69d §11). Our device number would seem to confirm that the patch applies to our device, but we’d like to leave no doubt. Why are there 9 hex digits in the ROM version specified in SPRS277, when the register only holds 8?
2) We’ll incorporate the patch into our S2 bootloader. Once the ROM-based bootloader executes the “system initialization” patch “at device reset” and jumps to our S2 bootloader, does all of the SRAM memory used by the patch become available to our application when the host loads it?
3) Would failure to apply this patch possibly cause intermittent failure behavior like we’re seeing?
Thanks,
Dave
