Blackfin
Embedded Processor
a
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
ABOUT ADSP-BF700/701/702/703/704/705/706/707 SILICON ANOMALIES
These anomalies represent the currently known differences between revisions of the Blackfin®ADSP-BF700/701/702/703/704/705/706/707
product(s) and the functionality specified in the ADSP-BF700/701/702/703/704/705/706/707 data sheet(s) and the Hardware Reference
book(s).
SILICON REVISIONS
A silicon revision number with the form "-x.x" is branded on all parts. The implementation field bits <15:8> of the DSPID core MMR
register can be used to differentiate the revisions as shown below.
Silicon REVISION
DSPID<15:8>
0.0
0x00
ANOMALY LIST REVISION HISTORY
The following revision history lists the anomaly list revisions and major changes for each anomaly list revision.
Date
Anomaly List Revision
Data Sheet Revision
Additions and Changes
07/03/2014
B
PrC
Added Anomalies: 19000013, 19000021, 19000022, 19000023,
19000024, 19000025, 19000026, 19000027, 19000028, 19000029,
19000031, 19000032, 19000034, 19000035, 19000036, 19000038
Revised Anomalies: 19000009, 19000012
04/03/2014
A
PrB
Initial Version
Blackfin and the Blackfin logo are registered trademarks of Analog Devices, Inc.
NR004345B
Information furnished by Analog Devices is believed to be accurate and reliable.
However, no responsibility is assumed by Analog Devices for its use, nor for any
infringements of patents or other rights of third parties that may result from its use.
Specifications subject to change without notice. No license is granted by implication or
otherwise under any patent or patent rights of Analog Devices. Trademarks and
registered trademarks are the property of their respective owners.
One Technology Way, P.O.Box 9106, Norwood, MA 02062-9106 U.S.A.
Tel: 781.329.4700
www.analog.com
Fax: 781.461.3113
©2014 Analog Devices, Inc. All rights reserved.
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
SUMMARY OF SILICON ANOMALIES
The following table provides a summary of ADSP-BF700/701/702/703/704/705/706/707 anomalies and the applicable silicon revision(s) for
each anomaly.
No.
ID
Description
0.0
1
19000002
Disabling Posted MMR Writes While Writes Are Outstanding May Cause Unpredictable Results
x
2
19000003
Invalid Opcode Does Not Cause Exception
x
3
19000004
SEQSTAT Parity Bits Can't be Cleared
x
4
19000005
Parity Error Status Registers May Capture the Incorrect Error Address
x
5
19000007
Reads of SPU_SECCHK by Non-secure Masters Result in an Erroneous Violation Interrupt
x
6
19000008
GPIO Slave Trigger Cannot Be Used on the Same Port as GPIO Outputs
x
7
19000009
CRC Look-Up Table Generation Doesn't Work as Expected
x
8
19000010
STI Directly Before CLI Does Not Enable Interrupts
x
9
19000011
The WRDO Bit in WDOG_CTL is Erroneously Cleared Under Certain Conditions
x
10
19000012
MSI 4-bit Read Operation Does Not Work as Expected
x
11
19000013
SPIHP Erroneously Drives SPI_MISO While Receiving Commands
x
12
19000015
TESTSET to a Write-Protected Bank of L2 Causes the Bank to Remain Locked
x
13
19000016
PKTE Hash Result Corruption in the Case of Data Output Buffer Full
x
14
19000017
Reading Certain PKTE Registers May Return Incorrect Data During Packet Processing
x
15
19000018
L1 Parity Checking Detects Spurious Parity Errors
x
16
19000019
Misaligned Accesses to L2 or L3 Memory Return Incorrect Data
x
17
19000020
L1 Cache and Parity Error Detection Are Disabled During Boot
x
18
19000021
CGU0_STAT.LWERR Bit Gets Erroneously Set Under Certain Conditions
x
19
19000022
Fill Blocks Not Functional During Secure Boot
x
20
19000023
adi_rom_sysControl Forces DMC_PADRESTORE Flag To True
x
21
19000024
Boot Mode Disable Feature is Not Functional
x
22
19000025
RCU_BCODE Cannot be Restored Upon Returning From Hibernate Mode
x
23
19000026
Secure SPI Master Boot Only Supported From Memory-Mapped SPI Devices on SPI2
x
24
19000027
RCU_MSG Register Incorrectly Reports HALTONINIT Emulation Exception
x
25
19000028
The adi_rom_Boot API Only Allows Booting From SPI Flash Address 0x0
x
26
19000029
Error Address in the Boot Config Struct is Incorrect
x
27
19000031
CGU and DMC Settings Cannot be Restored From the DPM Upon Wake from Hibernate
x
28
19000032
Transactions to Certain SPU and SMPU MMR Regions Cause Erroneous Errors
x
29
19000034
The JUMPCCEN Enable Bit in the BP_CFG Register Defaults to b#0 Instead of b#1
x
30
19000035
SYS_RESOUT Fails to Drive Low During Hardware Reset and Hibernate
x
31
19000036
System Reset Causes Emulator to Lose Connectivity
x
32
19000038
Writes to the SPI_SLVSEL Register Do Not Take Effect
x
Key: x = anomaly exists in revision
. = Not applicable
NR004345B | Page 2 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
DETAILED LIST OF SILICON ANOMALIES
The following list details all known silicon anomalies for the ADSP-BF700/701/702/703/704/705/706/707 including a description,
workaround, and identification of applicable silicon revisions.
1. 19000002 - Disabling Posted MMR Writes While Writes Are Outstanding May Cause Unpredictable Results:
DESCRIPTION:
Disabling posted MMR writes using the SYSCFG.MPWEN bit while MMR writes are outstanding may cause unpredictable results.
WORKAROUND:
Always place an SSYNC after setting SYSCFG.MPWEN = b#0.
APPLIES TO REVISION(S):
0.0
2. 19000003 - Invalid Opcode Does Not Cause Exception:
DESCRIPTION:
The opcode 0xEC81D373 is invalid and should cause an exception if executed, but it does not.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
3. 19000004 - SEQSTAT Parity Bits Can't be Cleared:
DESCRIPTION:
The parity bits in SEQSTAT can't be cleared.
WORKAROUND:
Use the BYTELOC bits in L1IM_IPERR_STAT and L1DM_DPERR_STAT to clear parity errors. The SEQSTAT parity bits will not update to show
that the parity erorr(s) have been cleared unless a core or system reset is applied.
APPLIES TO REVISION(S):
0.0
4. 19000005 - Parity Error Status Registers May Capture the Incorrect Error Address:
DESCRIPTION:
In the rare case of two consecutive parity errors the L1IM_IPERR_STAT or L1DM_DPERR_STAT registers may capture the second error
address location instead of the first. For this condition to occur both of the following events must occur:
1. Two consecutive DAG0 reads have parity errors
2. The return of the first read data is delayed by the core
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
NR004345B | Page 3 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
5. 19000007 - Reads of SPU_SECCHK by Non-secure Masters Result in an Erroneous Violation Interrupt:
DESCRIPTION:
Reads of SPU_SECCHK by non-secure masters result in an erroneous SPU violation interrupt. The erroneous interrupt will only be
observed if the SPU violation interrupt is enabled.
WORKAROUND:
There are two possible workarounds:
1. Don't use SPU_SECCHK.
2. Ignore the erroneous SPU interrupt after SPU_SECCHK is read.
APPLIES TO REVISION(S):
0.0
6. 19000008 - GPIO Slave Trigger Cannot Be Used on the Same Port as GPIO Outputs:
DESCRIPTION:
If a GPIO trigger slave asserts at the same time as a register write to change the output state of a signal on the same port, neither
transaction will complete. For instance, if PA_10 and PA_13 are set to toggle after a Port A slave trigger, any register writes to
PORTA_DATA, PORTA_DATA_SET, PORTA_DATA_CLR, or PORTA_DATA_TGL occurring at the same time as a Port A slave trigger will not
successfully complete.
WORKAROUND:
Don't use trigger toggle functionality on a port where writes to PORT_DATA, PORT_DATA_SET, PORT_DATA_CLR, or PORT_DATA_TGL will
occur.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 4 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
7. 19000009 - CRC Look-Up Table Generation Doesn't Work as Expected:
DESCRIPTION:
The CRC Look-Up Table (LUT) generation by writing to the CRC_POLY register works as expected only once after system reset. The boot
code uses the CRC to initialize memory, so any subsequent writes to the CRC_POLY register after the LUT is generated may lead to
unexpected CRC results.
WORKAROUND:
To work around this issue, the following steps should be followed while writing the CRC_POLY register with the polynomial value:
1. Write the polynomial value into the CRC_POLY register.
2. Wait for the look up table to get generated automatically by polling the CRC_STAT_LUTDONE bit.
3. Enable access to the CRC_LUT registers by first writing the internal register (address: 0x20005010) with the values 0x1E7B1C96 and
0xDFF0C3B2 one by one respectively and then setting bit 31 of the CRC_CTL register.
4. Calculate the CRC_LUT table values in software and write these values into the CRC_LUT registers (as mentioned in the code below).
5. Disable access to the CRC_LUT registers by first clearing bit 31 of the CRC_CTL register and then writing the internal
register(address:0x20005010) with the values 0x1E7B1C96 and 0xDFF0C3B2 one by one respectively.
The following C code can be used for a workaround :
//Initialize the CRC_POLYNOMIAL to be used here
#define CRC_POLYNOMIAL 0x82608EDB
//1. Write the polynomial value into the CRC_POLY register
*pREG_CRC0_POLY = CRC_POLYNOMIAL;
//2. Wait for the look up table to get generated automatically by polling the
//CRC_STAT_LUTDONE bit
while((*pREG_CRC0_STAT&BITM_CRC_STAT_LUTDONE==0));
//Internal register definition to be used only for this workaround
#define pINT_REG (volatile int*)0x20005010
//Uncomment this line when using the workaround for CRC0
#define USE_CRC0
//Uncomment this line when using the workaround for CRC1
//#define USE_CRC1
//Internal definition to be used only for this workaround (start address of the
//CRC_LUT registers)
#ifdef USE_CRC0
#define CRC_LUT_OFFSET 0x200B0080
#endif
#ifdef USE_CRC1
#define CRC_LUT_OFFSET 0x200B1080
#endif
uint32_t lutdat = 0x80000000;
uint32_t gx = CRC_POLYNOMIAL;
uint32_t lut[32];
uint32_t* pointer;
//3. Enable access to the CRC_LUT registers by first writing the internal
//register (address: 0x20005010) with the values 0x1E7B1C96 and 0xDFF0C3B2 one
//by one respectively and then setting bit 31 of the CRC_CTL register
*pINT_REG = 0x1E7B1C96;
*pINT_REG = 0xDFF0C3B2;
*pREG_CRC0_CTL|=0x80000000;
//4. Calculate the CRC LUT table
for (i=0; i<32; i++)
{
contents in software
NR004345B | Page 5 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
lutdat=((lutdat&0x80000000)==0x80000000)?((lutdat<<1) ^ gx) : lutdat << 1;
lut[i] = lutdat;
}
//4. Write the LUT registers
for(i=1;i<32;i++)
{
pointer = CRC_LUT_OFFSET+i*4;
*pointer=lut[i];
}
//5. Disable access to the CRC_LUT registers by first clearing bit 31 of the
//CRC_CTL register and then writing the internal register (address: 0x20005010)
//with the values 0x1E7B1C96 and 0xDFF0C3B2 one by one respectively
*pREG_CRC0_CTL&=~0x80000000;
*pINT_REG = 0x1E7B1C96;
*pINT_REG = 0xDFF0C3B2;
The only time this workaround does not need to be run is if the boot code memory initialization has been disabled and it is the first time
the CRC_POLY register is being written.
APPLIES TO REVISION(S):
0.0
8. 19000010 - STI Directly Before CLI Does Not Enable Interrupts:
DESCRIPTION:
If a CLI instruction follows an STI instruction immediately like the following example, interrupts will not be enabled. Even pending
interrupts will not be taken:
STI;
CLI;
WORKAROUND:
Make sure there are two or more instructions between STI and CLI. NOP instructions can be used.
APPLIES TO REVISION(S):
0.0
9. 19000011 - The WRDO Bit in WDOG_CTL is Erroneously Cleared Under Certain Conditions:
DESCRIPTION:
For this anomaly to occur, the following sequence must happen:
1. The watchdog must be enabled and then subsequently expire, causing the WRDO bit in WDOG_CTL to be set.
2. Disable the watchdog using WDOG_CTL.
3. Re-enable the watchdog WDOG_CTL without clearing WRDO
In this case the WRDO bit will be erroneously cleared and the watchdog will begin to count down from 0xFFFFFFFF.
WORKAROUND:
The write that disables the watchdog after expiry should always be followed by a write that clears WRDO and keeps WDOG disabled to
avoid the watchdog counting from 0xFFFFFFFF.
Pseudo code:
WDOG0_CTL=0x0AD0;
// disable Watchdog timer
WDOG0_CTL=0x8AD0;
// Clear the WRDO bit with watchdog disabled
// Re-enable the watchdog timer here
APPLIES TO REVISION(S):
0.0
NR004345B | Page 6 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
10. 19000012 - MSI 4-bit Read Operation Does Not Work as Expected:
DESCRIPTION:
In case of a data read operation in 4-bit mode with MSI configured for 4-bit bus width, the controller samples the data well before the
actual start bit is driven by the card. As a result, the controller samples the initial data as 0xFF until the point when the card starts driving
out actual data on the bus. The number of 0xFFs sampled depends on the card used and MSI bus frequency. The problem occurs when
the PORTC_MUX/FER registers are configured for four MSI Data lines( MSI_D0 - MSI_D3). The problem is observed for SD/SDIO as well as
eMMC/MMC cards.
WORKAROUND:
For ADSP-BF700/702/704/706 the following configuration will set up an internal loopback that will prevent the issue, though PC10 cannot
subsequently be used for any other purpose:
1. Configure PC10, PC11, PC12, and PC13 as GPIO in PORTC_FER.
2. Set PC10, PC11, PC12, and PC13 as outputs in PORTC_DIR_SET.
3. Set PC10, PC11, PC12, and PC13 to output b#1 by setting the appropriate bits in PORTC_DATA.
4. Program PORTC_PC10, PC11, PC12, and PC13 as inputs by setting the appropriate bits in PORTC_INEN.
For ADSP-BF701/703/705/707 the following options are available:
1. Use 8-bit MSI mode.
2. Use the same workaround shown for ADSP-BF702/BF704/BF706. If this workaround is implemented, PC10, PC11, PC12, and PC13
cannot be used for any other purpose.
APPLIES TO REVISION(S):
0.0
11. 19000013 - SPIHP Erroneously Drives SPI_MISO While Receiving Commands:
DESCRIPTION:
The SPIHP erroneously drives the SPI_MISO signal of the selected SPI peripheral (SPI0, SPI1, or SPI2) during the receipt of commands or
addresses from the SPI master device. The SPI_MISO signal should be in the high impedance state while the SPIHP is receiving commands
or addresses.
WORKAROUND:
The SPI master must ignore the SPI_MISO input during the command and address phase of transactions. If SPI_MISO cannot be ignored or
another slave is transmitting on the master's SPI_MISO input during the command/address phase, external logic such as a multiplexer can
be used to gate the transmission from the BF70x.
APPLIES TO REVISION(S):
0.0
12. 19000015 - TESTSET to a Write-Protected Bank of L2 Causes the Bank to Remain Locked:
DESCRIPTION:
A TESTSET instruction to an L2 bank that has been locked by setting the L2CTL_ACTL_SYS register will cause the bank to lock out all
masters other than the core for subsequent transactions. This includes all read and write accesses by any DMA channel or by the SPIHP.
Any such accesses will stall until the workaround is performed.
WORKAROUND:
To avoid this issue, clear the L2CTL_ACTL_SYS bit of an L2 bank before performing a TESTSET to that bank. Write protection can be reenabled after the TESTSET completes.
If the anomaly conditions have already occurred and DMA is stalled, the following steps may be used to release the stall:
1. Clear the corresponding bank's disable bit in the L2CTL_ACTL_SYS register.
2. Perform a TESTSET instruction to the same bank in L2 memory that the original TESTSET went to.
3. Set the corresponding bit back to 1 in L2CTL_ACTL_SYS.
The above workaround can be used to recover from a problem scenario.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 7 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
13. 19000016 - PKTE Hash Result Corruption in the Case of Data Output Buffer Full:
DESCRIPTION:
When processing a packet where a hash result is appended after packet data ("Copy Digest" option specified, PKTE_SA_CMD1.CPYGST=1),
the last hash result word may become corrupted when the 256-byte Data Output Buffer starting at PKTE_DATAIO_BUF is full at the time
that the last hash result word is added to the Data Output Buffer. For situations where data is written into the Data Output Buffer at a
faster rate than it can be written out, this problem may be more apparent.
WORKAROUND:
Do not allow the output buffer to become full. This can be accomplished by setting the Output Buffer Threshold value in the
PKTE_BUF_THRESH.OUTBUF register well below the maximum value. This will allow data to start moving out of the Data Output Buffer
before it fills. This is sufficient for preventing the issue for regular hash/encrypt operations, including protocol operations, provided that
the data is not delayed in going through the SCBs to its destination.
For cases where large amounts of data are forwarded directly from the Input Data Buffer to the Output Data Buffer, (e.g. when doing a
hash operation where also the "Copy Payload" option specified), the workaround specified may be ineffective because the Packet Engine
forwards this data immediately and it prioritizes fetching inputs over writing outputs. In this situation the Packet Engine may still have
unforwarded input data available that is passed to the Output Data Buffer before the Packet Engine is able to write out the contents of
the Output Data Buffer. This unforwarded data may have filled up the Output Data Buffer in such a way that the hash result cannot be
stored completely in the Output Data Buffer, which then results in an incorrect hash result value.
APPLIES TO REVISION(S):
0.0
14. 19000017 - Reading Certain PKTE Registers May Return Incorrect Data During Packet Processing:
DESCRIPTION:
Reading out the PKTE_BUF_THRESH, PKTE_INBUF_CNT, or PKTE_OUTBUF_CNT register within one SCLK1 cycle of the Packet Engine
starting to process a packet results in an incorrect value being read. This situation can happen when working in Direct Host Mode and
starting to poll for the amount of data that can be transferred (input or output) shortly after starting packet processing by writing to the
PKTE_SA_RDY register. For Autonomous Ring Mode there is no need to read the affected registers because the data will be automatically
transferred out to specified host memory buffers.
WORKAROUND:
In all modes the anomaly can by avoided by not reading any of the affected registers after starting packet processing using the
PKTE_SA_RDY register.
Additionally, since Direct Host Mode is a manual sequential operation, the Data Output Buffer can be emptied before configuring and
starting a new job to process another packet. It can then be assumed that the Data Input Buffer is empty when starting with a new packet.
By skipping the first poll this anomaly can be avoided. Also, the maximum amount of data to transfer can be assumed to be equal to the
Input Data Buffer size of 256 bytes so there is no need to check the threshold register to gauge this. For the output side it suffices not to
start polling for the availability of data before input data has been transferred.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 8 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
15. 19000018 - L1 Parity Checking Detects Spurious Parity Errors:
DESCRIPTION:
L1 data and instruction memory may detect spurious parity errors when DMA or other non-core writes are performed to L1 memory.
WORKAROUND:
Before writing to L1 memory using DMA all L1 locations must be read using extended access mode as shown in this code example:
#define LOADIMM32REG(R,VAL) R = VAL;
// Enable the extended data access functionality from the L1 space
LOADIMM32REG(p4, REG_L1DM_DCTL)
LOADIMM32REG(r0, 0x00010000)
[p4] = r0;
ssync;
// Pointer to base of L1 space and the increment to reach the next subbank
LOADIMM32REG(p0, 0x11A00000)
LOADIMM32REG(p1, 0x1000 - 4)
p2 = 16;
lsetup (_l1_im_init.a, _l1_im_init.b) lc0 = p2;
_l1_im_init.a:
r0 = [p0++];
// read from sub-bank column 0
_l1_im_init.b:
r1 = [p0 ++ p1];
// read from sub-bank column 1
LOADIMM32REG(p0, 0x11800000)
LOADIMM32REG(p1, 0x1000 - 4)
p2 = 8;
lsetup (_l1_dm_a_init.a, _l1_dm_a_init.b) lc0 = p2;
_l1_dm_a_init.a:
r0 = [p0++];
// read from sub-bank column 0
_l1_dm_a_init.b:
r1 = [p0 ++ p1 ]; // read from sub-bank column 1
LOADIMM32REG(p0, 0x11900000)
LOADIMM32REG(p1, 0x1000 - 4)
p2 = 8;
lsetup (_l1_dm_b_init.a, _l1_dm_b_init.b) lc0 = p2;
_l1_dm_b_init.a:
r0 = [p0++];
// read from sub-bank column 0
_l1_dm_b_init.b: r1 = [p0 ++ p1 ];
// read from sub-bank column 1
LOADIMM32REG(p0, 0x11B00000)
r0 = [p0++];
// read from sub-bank column 0
r0 = [p0++];
// Disable extended data access functionality
r0 = 0;
[p4] = r0;
ssync;
This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
operating systems supported by Analog Devices, please consult the "Silicon Anomaly Tools Support" help page in the applicable
documentation and release notes for details.
For all other tool chains and operating systems, see the appropriate supporting documentation for details.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 9 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
16. 19000019 - Misaligned Accesses to L2 or L3 Memory Return Incorrect Data:
DESCRIPTION:
Misaligned accesses (accesses not on a 32-bit boundary) to L2 or L3 memory will return incorrect data.
WORKAROUND:
Avoid misaligned accesses to L2 and L3 memory.
This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
operating systems supported by Analog Devices, please consult the "Silicon Anomaly Tools Support" help page in the applicable
documentation and release notes for details.
For all other tool chains and operating systems, see the appropriate supporting documentation for details.
APPLIES TO REVISION(S):
0.0
17. 19000020 - L1 Cache and Parity Error Detection Are Disabled During Boot:
DESCRIPTION:
Cache and parity error detection are disabled during boot since the cache disable bit (cacheDis) in OTP memory is pre-programmed.
Consequently, the boot code execution will take longer to complete and parity errors that occur during boot will not be detected.
WORKAROUND:
If cache or parity is desired in the application, ensure that it is enabled after boot.
This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
operating systems supported by Analog Devices, please consult the "Silicon Anomaly Tools Support" help page in the applicable
documentation and release notes for details.
For all other tool chains and operating systems, see the appropriate supporting documentation for details.
APPLIES TO REVISION(S):
0.0
18. 19000021 - CGU0_STAT.LWERR Bit Gets Erroneously Set Under Certain Conditions:
DESCRIPTION:
The LWERR bit in the CGU0_STAT register will become erroneously set under the following conditions:
1. SPU_CTL.GLCK is enabled.
2. Any register within the CGU that can be locked has its lock bit set.
3. A write is made to a system MMR of another peripheral that shares that the same 12 LSBs as the locked CGU register.
Although CGU0_STAT.LWERR becomes erroneously set under these conditions, a bus error does not occur as a result. A bus error only
occurs under the conditions specified in the ADSP-BF70x Blackfin+ Processor Hardware Reference.
WORKAROUND:
There are two possible workarounds:
1. Change any one of the 3 conditions listed in the description.
2. When tracing the source of a bus error, check CGU0_STAT.LWERR after all of other possible sources of the error have been checked.
This will prevent incorrect attribution of bus errors to the CGU.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 10 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
19. 19000022 - Fill Blocks Not Functional During Secure Boot:
DESCRIPTION:
The use of fill blocks in the boot stream when secure boot is enabled may cause either a boot error or data to be copied to the incorrect
memory space. Non-secure boot is not affected.
WORKAROUND:
Ensure that the loader stream does not use fill blocks utilizing secure boot.
This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
operating systems supported by Analog Devices, please consult the "Silicon Anomaly Tools Support" help page in the applicable
documentation and release notes for details.
For all other tool chains and operating systems, see the appropriate supporting documentation for details.
APPLIES TO REVISION(S):
0.0
20. 19000023 - adi_rom_sysControl Forces DMC_PADRESTORE Flag To True:
DESCRIPTION:
When utilizing the adi_rom_sysControl API, and having the actionFlags set to read from the DMC (BITM_ROM_SYSCTRL_DMC_READ) or to
write to the DPM (BITM_ROM_SYSCTRL_WUA_DPMWRITE & BITM_ROM_SYSCTRL_WUA_DMC & !BITM_ROM_SYSCTRL_WUA_OVERRIDE),
the ulWUA_Flags bit BITM_ROM_WUA_DMC_PADRESTORE is always treated as b#1 rather than evaluating whether it has been set to b#0
or b#1. This affects boot ROM code DMC initialization from both the DPM restore registers and from OTP memory, causing DMC settings
to unnecessarily be restored.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
21. 19000024 - Boot Mode Disable Feature is Not Functional:
DESCRIPTION:
The OTP field bootModeDisable does not disable boot modes.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
22. 19000025 - RCU_BCODE Cannot be Restored Upon Returning From Hibernate Mode:
DESCRIPTION:
The WUA_BCODE bit in the DPM_RESTORE0 register is not functional. Therefore, the RCU_BCODE register cannot be restored when
waking from hibernate mode.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
NR004345B | Page 11 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
23. 19000026 - Secure SPI Master Boot Only Supported From Memory-Mapped SPI Devices on SPI2:
DESCRIPTION:
Secure SPI master boot can only be done in memory-mapped mode from SPI2. SPI0 and SPI1 do not support memory-mapped mode and
therefore cannot support secure SPI master boot. The same restriction applies when calling the ROM API to boot.
WORKAROUND:
If secure SPI boot is needed, always configure dBootCommand to use SPI2 in XIP mode. When calling the ROM API, ensure that the lowest
nibble (boot source device) of the boot command parameter is 0x7. The memory-mapped address where the boot needs to be started
also needs to be passed as a start address parameter. For example, the below ROM API call boots from SPI flash which is mapped to
0x40000000 in XIP mode using SPI2:
adi_rom_Boot(0x40000000,0,0,0,0x207);
APPLIES TO REVISION(S):
0.0
24. 19000027 - RCU_MSG Register Incorrectly Reports HALTONINIT Emulation Exception:
DESCRIPTION:
When an initcode routine is called the boot code stored in ROM should set the RCU_MSG.HALTONINIT bit, but instead it sets the
RCU_MSG.HALTONCALL bit.
WORKAROUND:
Trap HALTONCALL emulation exceptions rather than HALTONINIT exceptions when attempting to halt on an initcode call.
APPLIES TO REVISION(S):
0.0
25. 19000028 - The adi_rom_Boot API Only Allows Booting From SPI Flash Address 0x0:
DESCRIPTION:
The adi_rom_Boot API only allows booting to begin from address 0x0 of SPI flash memory when using SPI Master boot mode.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
26. 19000029 - Error Address in the Boot Config Struct is Incorrect:
DESCRIPTION:
After entering the boot ROM error handler, the errorReturn field of the ADI_ROM_BOOT_CONFIG struct will always point to 0x40025AC,
which is not the location of the error.
WORKAROUND:
Either workaround may be used:
1. Set a breakpoint at 0x40025AC and read the RETS register once the breakpoint is reached. RETS will contain the location of the failure.
2. Use the stack to find the trace back to the failing function.
APPLIES TO REVISION(S):
0.0
NR004345B | Page 12 of 14 | July 2014
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
27. 19000031 - CGU and DMC Settings Cannot be Restored From the DPM Upon Wake from Hibernate:
DESCRIPTION:
adi_rom_sysControl does not correctly restore CGU and DMC settings from the DPM_RESTORE registers after wake from hibernate.
WORKAROUND:
If the CGU and/or the DMC need to be initialized after wake from hibernate the required values should be programmed in the appropriate
OTP memory locations.
APPLIES TO REVISION(S):
0.0
28. 19000032 - Transactions to Certain SPU and SMPU MMR Regions Cause Erroneous Errors:
DESCRIPTION:
Non-secure reads or writes to the upper half of each SPU instance's MMR space will be erroneously blocked and cause a bus error when
the SPU is set as non-secure slave. The same is true for each SMPU instance. The affected MMR address range can be calculated for each
instance of the SPU and SMPU as follows:
Lower bound = Instance Address Offset + 0x800
Upper bound = Instance Address Offset + 0xFFF
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
29. 19000034 - The JUMPCCEN Enable Bit in the BP_CFG Register Defaults to b#0 Instead of b#1:
DESCRIPTION:
The branch predictor does not come out of reset with optimal settings for most general-purpose programs. The JUMPCCEN bit in BP_CFG
should be b#1 rather than b#0.
WORKAROUND:
Set BP_CFG.JUMPCCEN to b#1 as early as possible in a program.
This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
operating systems supported by Analog Devices, please consult the "Silicon Anomaly Tools Support" help page in the applicable
documentation and release notes for details.
For all other tool chains and operating systems, see the appropriate supporting documentation for details.
APPLIES TO REVISION(S):
0.0
30. 19000035 - SYS_RESOUT Fails to Drive Low During Hardware Reset and Hibernate:
DESCRIPTION:
The SYS_RESOUT output should drive low while the SYS_HWRST input is asserted and during the hibernate state. Instead, SYS_RESOUT
remains in a high impedance state any time SYS_HWRST is asserted or the hibernate state is entered.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
NR004345B | Page 13 of 14 | July 2014
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
31. 19000036 - System Reset Causes Emulator to Lose Connectivity:
DESCRIPTION:
Performing a system reset through the RCU (regardless of the source) causes the emulator to lose connectivity.
WORKAROUND:
There are two possible workarounds for this issue:
1. Re-connect the emulator if emulation is required after the system reset.
2. To maintain emulator connectivity a core-only reset can be performed instead of a system reset. In this case each peripheral and
infrastructure block that needs to be reset for the particular application will have to be individually reset as well.
APPLIES TO REVISION(S):
0.0
32. 19000038 - Writes to the SPI_SLVSEL Register Do Not Take Effect:
DESCRIPTION:
A single write to the SPI_SLVSEL register should change the state of the register and cause the modified software-controlled SPI slave
selects to assert or de-assert. Instead, a single write to SPI_SLVSEL has no effect.
WORKAROUND:
Any write to SPI_SLVSEL should be done twice (back-to-back) with the same value in order for the change to take effect.
APPLIES TO REVISION(S):
0.0
©2014 Analog Devices, Inc. All rights reserved. Trademarks and
registered trademarks are the property of their respective owners.
a
NR004345B | Page 14 of 14 | July 2014
www.analog.com
© Copyright 2024 ExpyDoc
