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 REVID bits <31:28> of the TAPC0_IDCODE register can be
used to differentiate the revisions as shown below.
Silicon REVISION
TAPC0_IDCODE.REVID
1.0
0x1
0.0
0x0
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
02/29/2016
E
A
Added Anomalies: 19000055, 19000056, 19000057
05/17/2015
D
PrD
Added Silicon Revision 1.0
Added Anomalies: 19000051, 19000053, 19000054
Revised Anomalies: 19000047
11/20/2014
C
PrD
Added Anomalies: 19000039, 19000040, 19000041, 19000042,
19000043, 19000044, 19000045, 19000046, 19000047, 19000048,
19000049
Removed Anomaly: 19000015
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.
NR004345E
Document Feedback
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
©2016 Analog Devices, Inc. All rights reserved.
Technical Support
www.analog.com
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
Rev
0.0
Rev
1.0
1
19000002
2
19000003
Disabling Posted MMR Writes While Writes Are Outstanding May Cause Unpredictable Results
x
x
Invalid Opcode Does Not Cause Exception
x
x
3
4
19000004
SEQSTAT Parity Bits Can't be Cleared
x
x
19000005
Parity Error Status Registers May Capture the Incorrect Error Address
x
x
5
19000007
Reads of SPU_SECCHK by Non-secure Masters Result in an Erroneous Violation Interrupt
x
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
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
19000016
PKTE Hash Result Corruption in the Case of Data Output Buffer Full
x
.
13
19000017
Reading Certain PKTE Registers May Return Incorrect Data During Packet Processing
x
x
14
19000018
L1 Parity Checking Detects Spurious Parity Errors
x
.
15
19000019
Misaligned Accesses to L2 or L3 Memory Return Incorrect Data
x
.
16
19000020
L1 Cache and Parity Error Detection Are Disabled During Boot
x
.
17
19000021
CGU0_STAT.LWERR Bit Gets Erroneously Set Under Certain Conditions
x
.
18
19000022
Fill Blocks Not Functional During Secure Boot
x
.
19
19000023
adi_rom_sysControl Forces DMC_PADRESTORE Flag To True
x
.
20
19000024
Boot Mode Disable Feature is Not Functional
x
.
21
19000025
RCU_BCODE Cannot be Restored Upon Returning From Hibernate Mode
x
.
22
19000026
Secure SPI Master Boot Only Supported From Memory-Mapped SPI Devices on SPI2
x
x
23
19000027
RCU_MSG Register Incorrectly Reports HALTONINIT Emulation Exception
x
.
24
19000028
The adi_rom_Boot API Only Allows Booting From SPI Flash Address 0x0
x
.
25
19000029
Error Address in the Boot Config Struct is Incorrect
x
.
26
19000031
CGU and DMC Settings Cannot be Restored From the DPM Upon Wake from Hibernate
x
.
27
19000032
Transactions to Certain SPU and SMPU MMR Regions Cause Erroneous Errors
x
x
28
19000034
The JUMPCCEN Enable Bit in the BP_CFG Register Defaults to b#0 Instead of b#1
x
x
29
19000035
SYS_RESOUT Fails to Drive Low During Hardware Reset and Hibernate
x
.
30
19000036
System Reset Causes Emulator to Lose Connectivity
x
.
31
19000038
Writes to the SPI_SLVSEL Register Do Not Take Effect
x
x
32
19000039
Alternate SPT0_A Locations Not Functional on PA_12, PA_13, and PA_14
x
.
33
19000040
Deep Power Down Mode Exit for LPDDR Does Not Work as Expected
x
x
34
19000041
CYCLES Registers Do Not Count While Core is in IDLE
x
.
35
19000042
Self-Nested Interrupts Disable Further Interrupts
x
.
36
19000043
GP Timer Generates First Interrupt/Trigger One Edge Late in EXTCLK Mode
x
x
37
19000044
Dynamic Branch Prediction for RTS Instructions May Cause Data Loss
x
.
38
19000045
TESTSET Instruction May Cause Core Hang
x
x
39
19000046
The JTG_TRST Signal Erroneously Uses an Internal Pull-up Resistor
x
.
40
19000047
Dynamic Branch Prediction for Self-Modifying Code is Not Functional
x
x
41
19000048
User Mode Allows Access to MMRs and Protected Memory
x
.
NR004345E | Page 2 of 25 | February 2016
Silicon Anomaly List
No.
ID
Description
42
19000049
43
44
ADSP-BF700/701/702/703/704/705/706/707
Rev
0.0
Rev
1.0
Processor May Fail to Wake From Hibernate When the USB Cable is Disconnected
x
.
19000051
DLL in the DMC PHY May Not Lock to the New DCLK Frequency
x
x
19000053
ROM Code Erroneously Jumps to DMC Space During Wake From Hibernate
.
x
45
19000054
Dynamic Branch Prediction During Self-Nested ISRs Causes Unpredictable Results
x
x
46
19000055
Core Writes to CAN MMRs May Not Occur
x
x
47
19000056
High-Speed DMA Feature Not Implemented
x
.
48
19000057
Locked Processors Cannot be Unlocked by Emulator if Other Devices are Present in the JTAG Scan Chain
x
x
Key: x = anomaly exists in revision
. = Not applicable
NR004345E | Page 3 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
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, 1.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, 1.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, 1.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, 1.0
NR004345E | Page 4 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
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, 1.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
NR004345E | Page 5 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
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 shown 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 :
#include <cdefBF707.h>
//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 contents in software
NR004345E | Page 6 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
for (i=0; i<32; i++)
{
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, 1.0
NR004345E | Page 7 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
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
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 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 only when the PORTC_MUX/FER
registers are configured for four MSI Data lines (MSI_D0 - MSI_D3). This can happen 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-BF700/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
NR004345E | Page 8 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
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. 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
13. 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, 1.0
NR004345E | Page 9 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
14. 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
NR004345E | Page 10 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
15. 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
16. 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
17. 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
NR004345E | Page 11 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
18. 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
19. 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
20. 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
21. 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
NR004345E | Page 12 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
22. 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, 1.0
23. 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
24. 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. Calling the
ROM API to start booting from any other SPI flash address will fail.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
25. 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
NR004345E | Page 13 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
26. 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
27. 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, 1.0
28. 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, 1.0
29. 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
NR004345E | Page 14 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
30. 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
31. 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, 1.0
32. 19000039 - Alternate SPT0_A Locations Not Functional on PA_12, PA_13, and PA_14:
DESCRIPTION:
The following SPT0_A signals in the multiplexed function 2 column of port A are not functional:
Signal Name
Multiplexed Function 2
PA_12
SPT0_AFS
PA_13
SPT0_ACLK
PA_14
SPT0_AD0
WORKAROUND:
Use SPT0_A in its Port C location.
APPLIES TO REVISION(S):
0.0
NR004345E | Page 15 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
33. 19000040 - Deep Power Down Mode Exit for LPDDR Does Not Work as Expected:
DESCRIPTION:
The following steps show the intended DMC programming model for LPDDR deep power down mode exit:
1. Clear the DMC0_CTL.DPDREQ bit to exit from deep power down mode.
2. Wait for DMC0_STAT.DPDACK to be cleared.
3. Wait for DMC0_STAT.INITDONE to be set to make sure that the automatic initialization sequence is completed.
4. Now the LPDDR memory can be accessed.
The automatic initialization sequence in Step 3 may fail to correctly complete, though the DMC0_STAT.INITDONE bit will be set as if the
initialization had completed correctly. When the automatic initialization sequence does not complete as expected, unpredictable results
(e.g. data corruption) can occur during subsequent accesses to LPDDR memory.
WORKAROUND:
As shown below, a fresh memory initialization sequence must be explicitly initiated by user code after exiting deep power down mode:
1. Clear the DMC0_CTL.DPDREQ bit to exit deep power down mode.
2. Wait for DMC0_STAT.DPDACK to be cleared.
3. Wait for DMC0_STAT.INITDONE bit to be set (this does not guarantee that the automatic initialization sequence was successful, so
step 4 must be performed as well).
4. Set the DMC0_CTL.INIT bit and wait again for the DMC0_STAT.INITDONE to be set.
5. Now the LPDDR memory can be accessed.
The workaround steps are also available in C code:
#include <cdefBF707.h>
//1. Clear the DMC0_CTL.DPDREQ bit to exit from deep power down mode.
*pREG_DMC0_CTL&=~BITM_DMC_CTL_DPDREQ;
//2. Wait for DMC0_STAT.DPDACK to be cleared.
while((*pREG_DMC0_STAT&BITM_DMC_STAT_DPDACK)==1);
//3. Wait for DMC0_STAT.INITDONE bit to be set (this does not guarantee that the
//automatic initialization sequence was successful, so step 4 must be
//performed as well).
while((*pREG_DMC0_STAT&BITM_DMC_STAT_INITDONE)==0);
//4. Set the DMC0_CTL.INIT bit and wait again for the DMC0_STAT.INITDONE to be
//set.
*pREG_DMC0_CTL|=BITM_DMC_CTL_INIT;
while((*pREG_DMC0_STAT&BITM_DMC_STAT_INITDONE)==0);
//5. Now the LPDDR memory can be accessed.
APPLIES TO REVISION(S):
0.0, 1.0
34. 19000041 - CYCLES Registers Do Not Count While Core is in IDLE:
DESCRIPTION:
The CYCLES and CYCLES2 registers do not advance when the Blackfin+ core is in the IDLE state.
WORKAROUND:
There are two possible workarounds:
1. Use the core timer instead of the CYCLES registers to count CCLK cycles.
2. Don't use the IDLE instruction.
APPLIES TO REVISION(S):
0.0
NR004345E | Page 16 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
35. 19000042 - Self-Nested Interrupts Disable Further Interrupts:
DESCRIPTION:
From the core perspective, the System Event Controller (SEC) is a single source that raises interrupt requests on IVG11. In order to support
the SEC's ability to forward higher-priority interrupt requests to the core while the core is servicing a lower-priority interrupt, the IVG11
ISR must be able to be interrupted by itself, which means self-nesting must be enabled.
Consider the case where interrupt source A is higher-priority than interrupt source B coming from the SEC. When the IVG11 ISR is
servicing interrupt B, interrupt A occurs. Due to the self-nesting nature of the IVG11 ISR, the IVG11 ISR code is executed again to service
interrupt A. After interrupt A has been serviced, the ISR moves back to executing the service routine for interrupt B, which is where the
anomaly manifests. Typically, the following code would be used at the end of an interrupt service routine designed to support nested
interrupts:
RETI = [SP++];
RTI;
Writing the RETI register disables nested interrupts, and the RTI instruction is supposed to clear the global interrupt disable bit (IPEND[4]).
However, the anomaly is that when self-nesting is enabled, the IPEND[4] bit is not cleared. This results in interrupts being globally
disabled from that point forward.
WORKAROUND:
While software cannot directly access IPEND to recover from this condition, a forced soft exception can be added to the epilogue code for
a nested ISR to work around this issue:
RETI = [SP++];
EXCPT USER_EXCPT;
RTI;
// USER_EXCPT is an integer between 0 and 15
The exception handler code must be set up to service the soft exception raised above (EXCAUSE = USER_EXCPT), as follows:
[--SP] = R0;
[--SP] = ASTAT;
R0 = RETI;
CC = BITTST(R0,0);
if !CC jump _NOT_NESTED;
[--SP] = RETI; // clears IPEND[4]
BITCLR(R0,0);
RETX = R0;
SP+=4;
_NOT_NESTED:
ASTAT = [SP++];
R0 = [SP++];
RTX;
When RETI is pushed to the stack, the hardware sets bit 0 as a self-nested interrupt flag. Subsequently, when restored from the stack, bit 0
is cleared before being written back to the RETI register. The above code checks this flag bit. If the interrupt was nested, the RETX register
is overwritten with the RETI contents to bypass execution of the RTI instruction itself. That is, the RTX instruction will return to the original
ISR rather than to the nested ISR. Otherwise, the RTX instruction returns directly to the ISR that raised the exception, and the RTI
instruction in the ISR is executed normally.
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
NR004345E | Page 17 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
36. 19000043 - GP Timer Generates First Interrupt/Trigger One Edge Late in EXTCLK Mode:
DESCRIPTION:
When any GP Timer is configured in external clock mode the first interrupt/trigger should occur, along with the setting of the
corresponding TIMER_DATA_ILAT bit, after the TIMER_TMRn_CNT register reaches the value programmed in the TIMER_TMRn_PER
register. Instead, the interrupt/trigger and the setting of the TIMER_DATA_ILAT bit occur one signal edge later. At this point the
TIMER_TMRn_CNT register will have rolled over to 1. Subsequent interrupts/triggers occur after the correct number of edges.
For example, the TIMER_TMRn_PER register is configured to a value 7. After the timer has started, the first interrupt/trigger will occur
after the TIMER receives 8 signal edges externally. Subsequent interrupts/triggers will occur every 7 signal edges.
WORKAROUND:
For interrupts/triggers to occur every n edges of the external clock the TIMER_TMRn_PER register should be configured to n-1 for the
initial event and to n for subsequent events.
Pseudocode:
TIMER_TMRn_PER = n-1;
TIMER_RUN_SET = 1;
TIMER_TMRn_PER = n;
//Configure PERIOD register with n-1
//Enable the timer
//Configure PERIOD register with n
The update which sets TIMER_TMRn_PER = n will not take effect until the 2nd period.
APPLIES TO REVISION(S):
0.0, 1.0
37. 19000044 - Dynamic Branch Prediction for RTS Instructions May Cause Data Loss:
DESCRIPTION:
Dynamic branch prediction for RTS branches is not functional. Having dynamic branch prediction enabled for RTS branches can cause
data loss. Data loss occurs only if an RTS mispredict occurs and user code contains one of the following:
1. Core reads of system MMRs that have read side effects (meaning that the contents of the MMRs are altered by reading them).
2. Core reads of devices connected to the SMC that have read side effects (e.g. FIFOs).
In this situation the core may issue extra reads when mispredict occurs. When the core subsequently attempts to read the system MMR or
the SMC device, altered data will be read.
WORKAROUND:
The BP_CFG.RTSEN bit must be cleared (b#0) after booting. 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 (CrossCore Embedded Studio, the GNU Tool Chain, and the Linux
kernel), 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
38. 19000045 - TESTSET Instruction May Cause Core Hang:
DESCRIPTION:
The TESTSET instruction can cause the core to hang.
WORKAROUND:
Do not use TESTSET.
APPLIES TO REVISION(S):
0.0, 1.0
NR004345E | Page 18 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
39. 19000046 - The JTG_TRST Signal Erroneously Uses an Internal Pull-up Resistor:
DESCRIPTION:
The JTG_TRST signal erroneously uses an internal pull-up resistor. An internal pull-down should have been used instead to guarantee that
internal emulation logic will always be properly initialized during power-up reset.
WORKAROUND:
Use a 10kOhm external pull-down on JTG_TRST to overpower the internal pull-up.
APPLIES TO REVISION(S):
0.0
40. 19000047 - Dynamic Branch Prediction for Self-Modifying Code is Not Functional:
DESCRIPTION:
Dynamic branch prediction for self-modifying code is not functional and may cause unpredictable results.
WORKAROUND:
If self-modifying code is used, reset the branch predictor before each code modification. This pseudocode describes the procedure:
1. CSYNC instruction //Allows pending transactions to complete
2. Set BP_CFG.CLRBP //Begin clearing the prediction table
3. Clear SYSCFG.BPEN //Disable the branch predictor
4. Wait at least 150 CCLK cycles //Allows prediction table to clear
5. Set SYSCFG.BPEN //Re-enable the branch predictor
Even in the absence of this anomaly it is good programming practice to reset the branch predictor when code modifications occur. This
will clear invalid prediction tables and typically result in better performance.
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, 1.0
41. 19000048 - User Mode Allows Access to MMRs and Protected Memory:
DESCRIPTION:
User mode erroneously allows access to MMRs, as well as to regions of memory that are set by CPLBs to be protected from user mode
access. An exception still occurs when such an access happens, but the access is not prevented.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0
42. 19000049 - Processor May Fail to Wake From Hibernate When the USB Cable is Disconnected:
DESCRIPTION:
This issue occurs in USB device mode when the processor is in hibernate and set to wake from USB events. In this state, disconnecting the
USB cable should cause the processor to wake from hibernate, but may not do so. The reason is that the internal pull-down resistor on
USB_VBUS is erroneously disabled.
WORKAROUND:
Add a 200kOhm pull-down resistor to USB_VBUS if the processor needs to wake from hibernate when the USB cable is disconnected.
APPLIES TO REVISION(S):
0.0
NR004345E | Page 19 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
43. 19000051 - DLL in the DMC PHY May Not Lock to the New DCLK Frequency:
DESCRIPTION:
The DLL in the DMC PHY is responsible for generating the required phase between the strobe (DQS0/DQS1) and data (DQn) signals when
driven out of the controller. Whenever the DCLK frequency is modified using the CGU, the DLL is expected to lock automatically to the
new DCLK frequency. Because of this anomaly, the DLL may not lock to the new DCLK frequency and thus the controller may not
generate the required phase between the DQS0/DQS1 and DQn signals which can result in data corruption when trying to access a DDR2
or LPDDR memory device.
WORKAROUND:
To avoid the issue, the DLL must be held in reset during any CGU programming that results in a change to the DCLK frequency. Once a
valid Init_cgu function is in place, perform the workaround using the following C code:
*pREG_DMC_PHY_CTL0|=0x800; //Set bit number 11 of the DMC_PHY_CTL0 register
Init_cgu(); //Program the CGU to change the DCLK frequency
*pREG_DMC_PHY_CTL0&=~0x800; //Clear bit number 11 of the DMC_PHY_CTL0 register
APPLIES TO REVISION(S):
0.0, 1.0
NR004345E | Page 20 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
44. 19000053 - ROM Code Erroneously Jumps to DMC Space During Wake From Hibernate:
DESCRIPTION:
The boot code provides an option to restore CGU and DMC settings from the DPM restore registers via the wake-up action flag (WUA_EN)
upon wakeup from hibernate. When WUA_EN is set, the CGU and/or DMC registers are restored correctly from DPM after returning from
hibernate.
However, the processor subsequently jumps to DMC memory space (DDR2 or LPDDR memory) regardless of whether the
WUA_MEMBOOT flag is set. Therefore, the processor will only boot successfully after hibernate if code is preserved in DDR2 or LPDDR
memory during hibernate to facilitate the post-hibernate boot process. The correct behavior is to only boot from DMC memory space
when WUA_MEMBOOT is set.
To encounter this anomaly both of the following must be true:
1. Hibernate mode is used.
2. The WUA_EN flag is used to restore CGU and/or DMC settings from the DPM restore registers.
WORKAROUND:
There are several workarounds to consider depending on the desired behavior coming out of hibernate, whether DDR2/LPPDDR is used,
and whether the part is locked. The "Possible Workarounds List" includes all possible workarounds. Tables 1, 2, and 3 show which of the
possible workarounds should be used in each scenario.
For use cases in which DDR2 or LPDDR Memory is not present, the possible workarounds are listed in Table 1. In cases where there are two
workaround options the second option appears in the "Possible Workaround 2" column.
Table 1: DDR2 or LPDDR Memory is Not Present
CGU Setup Desired After Hibernate
Part Locked
Possible Workaround 1
Possible Workaround 2
Yes
No
A
C
Yes
Yes
A
For use cases with all of the following characteristics, the possible workarounds are listed in Table 2. In cases where there are two
workaround options the second option appears in the "Possible Workaround 2" column.
1. DDR2 or LPDDR memory is present.
2. DDR2 or LPDDR initialization is desired before the main application is booted when returning from hibernate.
3. Execution from DDR2 or LPDDR after returning from hibernate is not desired.
Table 2: DDR2/LPDDR Initialization Without Direct Execution
CGU Setup Desired After Hibernate
Part Locked
Possible Workaround 1
Possible Workaround 2
No
No
B
D
No
Yes
D
Yes
No
A and B
Yes
Yes
A and B
C and D
For use cases with all of the following characteristics use table 3 below to match up to the list of possible workarounds:
1. DDR2 or LPDDR memory is present.
2. When returning from hibernate mode initialization of the DDR2 or LPDDR is desired before the main application is booted.
3. Execution from DDR2 or LPDDR after returning from hibernate is desired.
Table 3: DDR2/LPDDR Initialization With Direct Execution
CGU Setup Desired After Hibernate
Part Locked
Workaround
No
No
E
No
Yes
E and F
Yes
No
E
Yes
Yes
E and F
Possible Workarounds List
A. Initialize CGU via OTP.
B. Initialize DMC via OTP.
NR004345E | Page 21 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
C.
D.
E.
F.
Silicon Anomaly List
Initialize CGU via initcode.
Initialize DMC via initcode.
Update Syscontrol.ulWUA_BootAddr to point to a routine in DDR2/LPDDR before self-refresh & hibernate
Program the cache disable bit (cacheDis) in OTP.
Since workaround E is most complicated a pseudocode example is provided below. In this example, the syscontrol.ulWUA_BootAddr is
updated to map to a function residing in the DMC (DDR2 or LPDDR) space. Upon wake from hibernate, the processor vectors to the
function in DMC space. Inside this function the SPU must be programmed to make the booting peripheral (SPI is used for the example)
secure. The ROM API is then called to boot the application.
Main()
{
DMC_Enter_Self_Refresh();
ADI_ROM_SYSCTRL Syscontrol;
// Use the pad restore option
Syscontrol.ulWUA_Flags = BITM_ROM_WUA_EN | BITM_ROM_WUA_DMC |
BITM_ROM_WUA_CGU | BITM_ROM_WUA_DMC_PADRESTORE |0xAD000000;
Syscontrol.ulWUA_BootAddr
= &Work_Around_Function;
uint32_t dActionflags1 = BITM_ROM_SYSCTRL_WUA_EN |
BITM_ROM_SYSCTRL_WUA_DPMWRITE | BITM_ROM_SYSCTRL_DDR_WRITE|
BITM_ROM_WUA_DMC_PADRESTORE | BITM_ROM_SYSCTRL_WUA_DMC |
BITM_ROM_SYSCTRL_WUA_CGU;
//Write the DMC registers into DPM block
adi_rom_dpmMgmt(dActionflags1, &Syscontrol, NULL);
//Configure the Wakeup sources
Config_Wakeups(WAKE0_PB07, ACTIVE_HIGH);
// Setup Power good counter
Setup_Pwgcnt(PWGD_4K_CYCLES);
//Enter Hibernate mode
Enter_Hibernate();
}
section ("dmc_bank0")
void Work_Around_Function()
{
//The SPU configuration and the ROM API parameters shown below are
//for SPI Master Boot Mode as an example
*pREG_SPU0_SECUREP51 = 0x3;
*pREG_SPU0_SECUREP52 = 0x3;
//Turn on optimization to have the bootrom_jumptable_boot_t pBoot mapped
// to L3.
adi_rom_Boot(0x40000000,0,0,0,0x207);
}
APPLIES TO REVISION(S):
1.0
NR004345E | Page 22 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
45. 19000054 - Dynamic Branch Prediction During Self-Nested ISRs Causes Unpredictable Results:
DESCRIPTION:
The System Event Controller (SEC) is a single source that raises interrupt requests to the core at level 11 (IVG11). In order to support the
SEC's ability to forward higher-priority interrupt requests to the core while the core is servicing a lower-priority interrupt, the IVG11 ISR
must be able to be interrupted by itself, which means self-nesting must be enabled.
Consider the case where interrupt source A is higher-priority than interrupt source B coming from the SEC. When the IVG11 ISR is
servicing interrupt B, interrupt A occurs. Due to the self-nesting nature of the IVG11 ISR, the IVG11 ISR code is executed again to service
interrupt A. If dynamic branch prediction is enabled during this execution, and the nested interrupt occurs exactly between the source
and destination instructions of a branch (JUMPs, CALLs, or RTS) in the interrupt handler, the self-nesting state of the ISR can be lost, thus
resulting in unpredictable code flow, which can lead to various run-time failures (including exceptions).
WORKAROUND:
The simplest workaround is to globally disable dynamic branch prediction by clearing the SYSCFG.BPEN bit. However, this may lead to
reduced core performance.
An alternative is to disable dynamic prediction only in self-nested interrupt service routines. This can be accomplished by modifying the
interrupt dispatcher code that is the wrapper for the IVG11 ISR. The code should use two global variables - one to keep track of the ISR
nesting level and one to store the BP-enable bit in the outermost ISR. The workaround requires that code be added to both the prologue
and the epilogue for each self-nesting ISR.
In the self-nesting ISR prologue:
// Keep a count of how deeply nested the application is running at
R0 = [_isr_nest_count];
CC = R0;
R0 += 1;
[_isr_nest_count] = R0;
// Save the BPEN bit for the outer ISR only, and disable BPEN.
IF CC JUMP _already_nested;
R0 = SYSCFG;
R1 = BITM_SYSCFG_BPEN;
R1 = R0 & R1;
[_prev_bp_enable] = R1;
// Save the BPEN bit
BITCLR(R0, BITP_SYSCFG_BPEN);
CSYNC;
// Make sure pipeline is clear before disabling BP
SYSCFG = R0;
_already_nested:
// Normal dispatcher code goes here
Then, in the self-nesting ISR epilogue:
// Decrement nest count and restore BP enable bit at the outermost level
R0 = [_isr_nest_count];
R0 += -1;
CC = R0;
[_isr_nest_count] = R0;
IF CC JUMP _still_nested;
R1 = [_prev_bp_enable];
R0 = SYSCFG;
R0 = R0 | R1;
SYSCFG = R0;
_still_nested:
// Rest of dispatcher epilogue goes here
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, 1.0
NR004345E | Page 23 of 25 | February 2016
ADSP-BF700/701/702/703/704/705/706/707
Silicon Anomaly List
46. 19000055 - Core Writes to CAN MMRs May Not Occur:
DESCRIPTION:
When the CAN bus is active, all frames are sampled whether or not the CAN is configured to receive the message or respond to a remote
frame request. An internal mailbox comparison run is initiated after the frame header is latched (during the r0 bit for standard frames, and
during the r1 bit for extended frames) to determine whether or not the active message is a match to any enabled receive mailbox in the
CAN block. During this sensitive window where the internal scan is taking place, core writes to the CAN MMR address space may not
occur, and lost writes will go undetected.
Core reads of the CAN MMR space are not affected by this anomaly.
WORKAROUND:
The anomaly does not occur when the CAN module is electrically disconnected from the CAN bus.
When electrically connected to the CAN bus, it is impossible to determine when the internal comparison run is taking place. As a result, all
writes to the CAN MMR space must be implemented as an atomic triple-write access in order to guarantee that the write occurs outside
the sensitive window, per the following pseudo-code:
CAN_TRIPLE_WRITE(CAN_MMR_ADDRESS, Value):
DISABLE_INTERRUPTS;
CAN_MMR_ADDRESS = Value;
CAN_MMR_ADDRESS = Value;
CAN_MMR_ADDRESS = Value;
SSYNC;
ENABLE_INTERRUPTS;
While this workaround guarantees that all core writes will occur properly to the CAN MMR space, it introduces the potential for multiple
writes to occur where only a single write should have been made. Though not an issue in most cases, this is problematic when
considering writes to W1C registers like CAN_RMP and CAN_MBRIF when processing a received message. For these registers, if one of the
first two writes occurs properly and the hardware then resets the same bit due to the arrival of the next message to the same mailbox, a
subsequent write from the workaround code will now erroneously clear the status bit again immediately without actually processing the
newly arrived data, and there will be no indication that the second message was not processed. For this case, software can further utilize
the Temporary Mailbox Disable feature prior to writing the CAN_RMP or CAN_MBRIF registers (e.g., for clearing the RMP bit for RX mailbox
2):
CAN_TRIPLE_WRITE(REG_CAN0_MBTD, (BITM_CAN_MBTD_TDR|MB_NUM)); // MB_NUM = 0x2
while(!(*pREG_CAN0_MBTD & BITM_CAN_MBTD_TDA));
// Poll for ACK
CAN_TRIPLE_WRITE(REG_CAN0_RMP1, BITM_CAN_RMP1_MB02);
// Clear RMP2
With this additional code, a second message destined for the same receive mailbox as the first message will not result in an undetected
lost message due to the required workaround code. If the 2nd message is in the process of being stored at the time that the temporary
disable request is executed, it will be received completely (and the appropriate CAN_RML bit will be set). However, if the temporary
disable request occurs before the second message becomes ongoing (at the start of the DLC field of the active message), then a second
receive mailbox must also be enabled to receive the same message ID as the first message, otherwise the second message will not be
received due to there being no match to an enabled RX mailbox in the comparison run that establishes which message center to store to.
APPLIES TO REVISION(S):
0.0, 1.0
47. 19000056 - High-Speed DMA Feature Not Implemented:
DESCRIPTION:
The high-speed DMA (HSDA) feature described in the processor hardware reference manual is not implemented on older revisions of
silicon.
WORKAROUND:
None.
APPLIES TO REVISION(S):
0.0
NR004345E | Page 24 of 25 | February 2016
Silicon Anomaly List
ADSP-BF700/701/702/703/704/705/706/707
48. 19000057 - Locked Processors Cannot be Unlocked by Emulator if Other Devices are Present in the JTAG
Scan Chain:
DESCRIPTION:
This issue occurs only if the processor has been locked by using the Lock API to write to OTP memory. Once the processor has been
locked, it cannot be unlocked by the emulator if any other devices are present in the JTAG scan chain.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0, 1.0
©2016 Analog Devices, Inc. All rights reserved. Trademarks and
registered trademarks are the property of their respective owners.
a
NR004345E | Page 25 of 25 | February 2016
www.analog.com