0, A, B, E, F

The factory function InitAnalogSystemClock() is provided for the purpose of configuring the clock ratio used by the Analog Subsystem and returning its status. A successful, properly configured device will return the success code 0xA005.

For affected devices, InitAnalogSystemClock() is missing one step, which may misconfigure the Analog Subsystem clocking scheme and return a code not equal to 0xA005.

A misconfigured Analog Subsystem clocking scheme may lead to random ACIB faults. Under such error conditions, all of the following symptoms are exhibited:

1. Reads from the Analog Subsystem return unexpected values. In the vast majority of cases, the reads return the value of 0x0000.
2. Writes to the Analog Subsystem appear to have no effect.
3. The ACIBERR bit in the NMIFLG registers are set.
4. The CIBSTATUS registers show no error:
   • CIBSTATUS[15:8] increments freely
   • CIBSTATUS[7:0] = 0x01
5. ACIB activity can be recovered by an ACIB reset initiated by the Master Subsystem.

Manually complete the clock initialization sequence with an additional step in the user software immediately prior to calling the InitAnalogSystemClock() function from the Control Subsystem. This extra step is required for every instance where InitAnalogSystemClock() is called by user software.

The additional step will assign the value of 7 to the C28x memory space at address 0x4E58. The following code is an example of how the workaround can be implemented for a device where the desired clock ratio between the Control Subsystem and Analog Subsystem is 4-to-1:

Once the workaround is in place, InitAnalogSystemClock() should be expected to return the success code of 0xA005 and no further actions will be necessary for proper ACIB behavior.

0, A, B, E, F

The factory functions AnalogClockEnable() and AnalogClockDisable() are provided for the purpose of configuring the peripheral clocks of the analog modules. When an analog clock configuration attempt succeeds, the function returns the value of 0.

Due to configuration latencies between the Control Subsystem and Analog Subsystem, the desired clock configuration will not be effective immediately after the function returns. A race condition may be encountered if user software attempts to use a module before the clock configuration is complete.

Further, the factory function InitAnalogSystemClock() expects that the analog clock configurations are static during execution. If AnalogClockEnable() or AnalogClockDisable() is executed immediately before InitAnalogSystemClock(), the initialization sequence may be corrupted because the analog clock configuration is not static during execution. For such a scenario, the return value of InitAnalogSystemClock() will not be 0xA005 as expected. If the initialization sequence is corrupted, the device may require a reset to recover from the error condition.

The AnalogClockEnable() and AnalogClockDisable() functions support back-to-back executions so a race condition between calls is not possible when these analog clock configuration functions are executed immediately after each other.

After executing one or more calls to AnalogClockEnable() or AnalogClockDisable(), flush the analog clock configuration sequence by executing the factory function ReadAnalogClockStatus().

The read operation of ReadAnalogClockStatus() is automatically queued behind pending analog clock configuration updates so its return from execution can be used to definitively verify that the desired clock configuration sequence has completed.

For example, the following code will enable the ADC module clocks with AnalogClockEnable() calls, and it will flush the clock configuration operations with ReadAnalogClockStatus() before resetting the ADC modules:

0, A, B, E, F

When the ADC conversions are initiated by any source of trigger in either sequential or simultaneous sampling mode, the first sample may not be the correct conversion result.

For sequential mode, discard the first sample at the beginning of every series of conversions. For instance, if the application calls for a given series of conversions, SOC0→SOC1→SOC2, to initiate periodically, then set up the series instead as SOC0→SOC1→SOC2→SOC3 and only use the last three conversions, ADCRESULT1, ADCRESULT2, ADCRESULT3, thereby discarding ADCRESULT0.

For simultaneous sample mode, discard the first sample of both the A and B channels at the beginning of every series of conversions.

User application should validate if this workaround is acceptable in their application.

This issue is fixed completely by writing a 1 to the ADCNONOVERLAP bit in the ADCTRL2 register, which only allows the sampling of ADC channels when the ADC is finished with any pending conversion.

0, A, B, E, F

Each on-chip ADC takes 13 ADC clock cycles to complete a conversion after the sampling phase has ended. The result is then presented to the bus controller on the 14th cycle post-sampling and latched on the 15th cycle into the ADC result registers. If the next conversion's sampling phase terminates on this 14th cycle, the results latched by the bus controller into the result register are not assured to be valid across all operating conditions.

Some workarounds are as follows:

• Due to the nature of the sampling and conversion phases of the ADC, there are only two values of ACQPS (which controls the sampling window) that would result in the above condition occurring—ACQPS = 6 or 7. One solution is to avoid using these values in ACQPS.
• When the ADCNONOVERLAP feature (bit 1 in ADCTRL2 register) is used, the above condition will never be met; so the user is free to use any value of ACQPS desired.
• Depending on the frequency of ADC sampling used in the system, the user can determine if their system will hit the above condition if the system requires the use of ACQPS = 6 or 7. For instance, if the converter is continuously converting with ACQPS = 6, the above condition will never be met because the end of the sampling phase will always fall on the 13th cycle of the current conversion in progress.

0, A, B, E, F

The factory offset calibration from Device_cal() may not ensure that each ADC's offset remains within specifications under all operating conditions in the customer's system.

• To ensure that the offset remains within the data sheet's “single recalibration” specifications, perform the AdcxOffsetSelfCal() function after Device_cal() has completed and the ADC has been configured.
• To ensure that the offset remains within the data sheet's “periodic recalibration” specifications, perform the AdcxOffsetSelfCal() function periodically with respect to temperature drift.

For more details on AdcxOffsetSelfCal(), refer to the “ADC Zero Offset Calibration” section in the Analog Subsystem chapter of the Concerto F28M36x Technical Reference Manual.

0, A, B, E, F

The ADC can get into a non-responsive state when the ADCCTL2[ADCNONOVERLAP] is modified while a conversion is in progress. When in this condition, no further conversion from the ADC will be possible without a device reset.

There are two different ways to cause this condition:

• Writing to ADCCTL2[ADCNONOVERLAP] while a conversion is in progress.
• Writing to ADCCTL1[RESET] while a conversion is in progress.

Follow this sequence to modify ADCCTL2[ADCNONOVERLAP] or write ADCCTL1[RESET]:

1. Set all SOC trigger sources ADCSOCxCTL[TRIGSEL] to 0.
2. Set all ADCINTSOCSEL1/2 to 0.
3. Ensure there is not another SOC pending (This can be accomplished by polling SOC Flags).
4. Wait for all conversions to complete.
   1. ADCCTL2[CLKDIV2EN] = 0, ADCCTL2[CLKDIV4EN] = x → (ACQPS + 13 ) * 1 SYSCLKs
   2. ADCCTL2[CLKDIV2EN] = 1, ADCCTL2[CLKDIV4EN] = 0 → (ACQPS + 13 ) * 2 SYSCLKs
   3. ADCCTL2[CLKDIV2EN] = 1, ADCCTL2[CLKDIV4EN] = 1 → (ACQPS + 13 ) * 4 SYSCLKs
5. Modify ADCCTL2[ADCNONOVERLAP] or write ADCCTL1[RESET].

An example code follows.

0, A, B, E, F

The VREG "Warn Lo/High" feature should not be used or enabled in the device. Do not set the VREGWARNE bit in the MNMICFG register as it could negatively affect the VREG output voltage.

None

0, A, B, E, F

This advisory only applies to systems that tie the VREG12EN pin high and use an external regulator for the 1.2-V V_DD supply.

During power up of the 3.3-V V_DDIO, the internal Voltage Regulator (VREG) will be active until the 1.2-V V_DD supply reaches approximately 0.7 V. After this time, the state of the VREG12EN pin will either keep the internal VREG active (if low) or disable the internal VREG (if high).

None

0, A, B, E, F

If any of the eQEP input pins are configured for GPIO asynchronous input mode via the GPxQSELn registers, the eQEP module may not operate properly. For example, QPOSCNT may not reset or latch properly, and pulses on the input pins may be missed. This is because the eQEP peripheral assumes the presence of external synchronization to SYSCLKOUT on inputs to the module.

For proper operation of the eQEP module, input GPIO pins should be configured via the GPxQSELn registers for synchronous input mode (with or without qualification). This is the default state of the GPxQSEL registers at reset. All existing eQEP peripheral examples supplied by TI also configure the GPIO inputs for synchronous input mode.

The asynchronous mode should not be used for eQEP module input pins.

Configure GPIO inputs configured as eQEP pins for non-asynchronous mode (any GPxQSELn register option except “11b = Asynchronous”).

0, A, B, E, F

While using the PCRM = 0 configuration, if the direction change occurs when the index input is active, the position counter (QPOSCNT) could be reset erroneously, resulting in an unexpected change in the counter value. This could result in a change of up to ±4 counts from the expected value of the position counter and lead to unexpected subsequent setting of the error flags.

While using the PCRM = 0 configuration [that is, Position Counter Reset on Index Event (QEPCTL[PCRM] = 00)], if the index event occurs during the forward movement, then the position counter is reset to 0 on the next eQEP clock. If the index event occurs during the reverse movement, then the position counter is reset to the value in the QPOSMAX register on the next eQEP clock. The eQEP peripheral records the occurrence of the first index marker (QEPSTS[FIMF]) and direction on the first index event marker (QEPSTS[FIDF]) in QEPSTS registers. It also remembers the quadrature edge on the first index marker so that same relative quadrature transition is used for index event reset operation.

If the direction change occurs while the index pulse is active, the module would still continue to look for the relative quadrature transition for performing the position counter reset. This results in an unexpected change in the position counter value.

The next index event without a simultaneous direction change will reset the counter properly and work as expected.

Do not use the PCRM = 0 configuration if the direction change could occur while the index is active and the resultant change of the position counter value could affect the application.

Other options for performing position counter reset, if appropriate for the application [such as Index Event Initialization (IEI)], do not have this issue.

0, A, B, E, F

The PLL may not start properly at device power up. The PLLSTS[PLLLOCKS] lock counter bit is set, but the PLL does not produce a clock. Once the PLL has properly started, the PLL can be disabled and reenabled with no issues and will stay locked. However, the PLL lock problem could reoccur on a subsequent power-up cycle. If the PLLSYSCLK has not properly started and is selected as the CPU clock source, the CPU will stop executing instructions. The occurrence rate of this transient issue is low and after an initial occurrence, this issue may not be subsequently observed in the system again. Implementation of the workaround reduces the rate of occurrence.

This advisory applies to both PLLs.

System PLL Workaround

Repeated lock attempts will reduce the likelihood of seeing the condition on the final attempt. TI recommends a minimum of five lock sequences in succession when the PLL is configured the first time after a power up. A lock sequence means disabling the PLL, starting the PLL locking, and waiting for the PLLLOCKS lock counter bit to set. After the final sequence, the Watchdog is enabled and the clock source is switched to use the PLL output as normal.

The Watchdog timer is used to detect if the condition has occurred because it is not clocked by the PLL output. The Watchdog should be enabled before selecting the PLL as the clock source and configured to reset the device. If the PLL is not producing a clock, the Watchdog will reset the device and the user initialization software will therefore repeat the PLL initialization.

Many applications do not have a different initialization sequence for a Watchdog-initiated reset; for these applications, no further action is required. For applications that do use a different device initialization sequence when a Watchdog reset is detected, a flag can be set in RAM prior to initializing the PLL. This flag can be used to identify a PLL lock failure as the Watchdog reset cause and allow the retry to occur.

See the controlSUITE™ SysCtlClockPllConfig() function for an example implementation of this workaround.

The workaround can also be applied at the System level by a supervisor resetting the device if it is not responding.

USB PLL Workaround

The workaround for the USB PLL is similar to that for the System PLL except the Watchdog cannot be used to detect a PLL lock failure on the final attempt. The application must detect a USB clocking failure at the system level and issue a reset to the device for another USB PLL lock attempt.

See the controlSUITE SysCtlUSBPLLConfigSet() function for an example implementation of this workaround.

0, A, B, E, F

The Synchronous Serial Interface (SSI) module does not support the Microwire frame format. SSI and SPI frame formats are not affected.

None

0, A, B, E, F

The RTRIS (UART Receive Time-Out Raw Interrupt Status) bit in the UART Raw Interrupt Status (UARTRIS) register should be set when a receive time-out occurs, regardless of the state of the RTIM enable bit in the UART Interrupt Mask (UARTIM) register. However, currently the RTIM bit must be set in order for the RTRIS bit to be set when a receive time-out occurs.

For applications that require polled operation, the RTIM bit can be set while the UART interrupt is disabled in the NVIC using the IntDisable(n) function in the StellarisWare® Peripheral Driver Library, where n is 21, 22, or 49, depending on whether UART0, UART1, or UART2 is used. With this configuration, software can poll the RTRIS bit, but the interrupt is not reported to the NVIC.

0, A, B, E, F

During execution of a Cortex-M3 or C28x PBIST, all Cortex-M3 or C28x accesses to ROM on the device will fail. This does not impact a PBIST of the ROM itself, which will work as expected.

Do not access ROM during a PBIST execution.

0, A, B, E, F

The TXFFIL (Transmit FIFO Interrupt Level) bits in the I2C Transmit FIFO (I2CFFTX) register and the RXFFIL (Receive FIFO Interrupt Level) bits in the I2C Receive FIFO (I2CFFRX) register are capped to a maximum value of 7. Writes of values greater than 7 to these fields will be truncated to the lower 3 bits.

Applications can poll the TXFFST (Transmit FIFO Status) and RXFFST (Receive FIFO Status) bits in the I2CFFTX and I2CFFRX registers, respectively, for an accurate count of the number of items in the FIFOs. Applications wishing to use I2C FIFO interrupts must set the interrupt levels to 7 or less.

0, A, B, E, F

The ePWM7 is clocked by C28x CPUCLK. When the CPUCLK stops, ePWM7 will also stop. The C28x (and ePWM7) will stop during:

• C28x low-power IDLE mode
• C28x debugger halt

Other ePWM modules are clocked by SYSCLK, which does not stop during IDLE or debugger halt.

None. Use other ePWM modules if the IDLE mode is used or ePWM must remain active during debugger HALT.

0, A, B, E, F

ePWM dead-band delay value cannot be set to 0 when using Shadow Load Mode for rising-edge delay (RED) and falling-edge delay (FED).

1. Use Immediate Load Mode if DBRED/DBFED = 0.
2. Do not use DBRED/DBFED = 0 if in Shadow Load Mode.

This is for both RED and FED.

0, A, B, E, F

The blanking window is typically used to mask any PWM trip events during transitions which would be false trips to the system. If an ePWM trip event remains active for less than three ePWM clocks after the end of the blanking window cycles, there can be an undesired glitch at the ePWM output.

Figure 3 illustrates the time period which could result in an undesired ePWM output.

Figure 3. Undesired Trip Event and Blanking Window Expiration

Figure 4 illustrates the two potential ePWM outputs possible if the trip event ends within 1 cycle before or 3 cycles after the blanking window closes.

Figure 4. Resulting Undesired ePWM Outputs Possible

Extend or reduce the blanking window to avoid any undesired trip action.

0, A, B, E, F

The Blanking Window will not blank trip events for the first 3 cycles after the start of a Blanking Window. DCEVTFILT may continue to reflect changes in the DCxEVTy signals. If DCEVTFILT is enabled, this may impact subsequent subsystems that are configured (for example, the Trip Zone submodule, TZ interrupts, ADC SOC, or the PWM output).

Start the Blanking Window 3 cycles before blanking is required. If a Blanking Window is needed at a period boundary, start the Blanking Window 3 cycles before the beginning of the next period. This works because Blanking Windows persist across period boundaries.

0, A, B, E, F

If the X1 crystal oscillator is slow to start, a Missing Clock Detect (MCD) event can occur. This will switch the clock source to the internal 10-MHz INTOSC.

The Boot ROM NMI ISR to service the CLOCKFAIL clears the MNMIFLG[CLOCKFAIL] bit to prevent an NMIWD reset. On start-up, the application code will not have an opportunity to execute a custom NMIWD ISR since the interrupt has already been serviced. The MCLKSTS[MCLKFLG] will be set correctly and must be polled by software to detect the MCD condition on start-up.

Check the MCLKSTS[MCLKFLG] bit in the initialization code. The application should respond according to the system requirements of a missing clock source situation.

Most applications can tolerate a slow crystal start-up. For these applications, a Watchdog reset can be forced. A Watchdog reset will be held for 512 clocks on the X1 clock input and the device will be held in reset until the crystal is active.

0, A, B, E, F

The Watchdog and NMI Watchdog resets will always be asserted for 512 cycles of the external X1 clock source. If the X1 clock source is permanently absent, this will result in a persistent assertion of XRS low for a Missing Clock Detect (MCD) event.

NOTE: The term "Watchdog" in this advisory applies to all Cortex-M3 watchdog timers: MNMIWD, WDT0, and WDT1.

The application code should contain an NMIWD ISR, which properly shuts down the system when an MCD event occurs. NOTE: MCD switches the clock source to the
10-MHz INTOSC and code will be executed using this clock.

The NMIWD CLOCKFAIL ISR should:

• Service the Watchdog to prevent a device watchdog reset before system shutdown code is executed.
• Perform system shutdown.
• Optionally use the Watchdog to force a reset if the desired state is for the device to be held in reset due to an MCD.

NOTE: If the application response to an MCD must avoid putting the device in reset, then there is a window of vulnerability between the MCD and a Watchdog expiration. If a watchdog timer configured to cause a reset expires before the NMIWD ISR services the watchdog, a persistent reset cannot be avoided.

0, A, B, E, F

This advisory applies when the write phase of a CPU-to-FPU register write coincides with the execution phase of the F32TOUI32, FRACF32, or UI16TOF32 instructions. If the F32TOUI32 instruction execution and CPU-to-FPU register write operation occur in the same cycle, the target register (of the CPU-to-FPU register write operation) gets overwritten with the output of the F32TOUI32 instruction instead of the data present on the C28x data write bus. This scenario also applies to the following instructions:

• F32TOUI32 RaH, RbH
• FRACF32 RaH , RbH
• UI16TOF32 RaH , mem16
• UI16TOF32 RaH , RbH

A CPU-to-FPU register write must be followed by a gap of five NOPs or non-conflicting instructions before F32TOUI32, FRACF32, or UI16TOF32 can be used.

The C28x code generation tools v6.0.5 (for the 6.0.x branch), v6.1.2 (for the 6.1.x branch), and later check for this scenario.

Example of Problem:

Example of Workaround:

0, A, B, E, F

This advisory applies when a multi-cycle (2p) FPU instruction is followed by a FPU-to-CPU register transfer. If the FPU-to-CPU read instruction source register is the same as the 2p instruction destination, then the read may be of the value of the FPU register before the 2p instruction completes. This occurs because the 2p instructions rely on data-forwarding of the result during the E3 phase of the pipeline. If a pipeline stall happens to occur in the E3 phase, the result does not get forwarded in time for the read instruction.

The 2p instructions impacted by this advisory are MPYF32, ADDF32, SUBF32, and MACF32. The destination of the FPU register read must be a CPU register (ACC, P, T, XAR0...XAR7). This advisory does not apply if the register read is a FPU-to-FPU register transfer.

In the example below, the 2p instruction, MPYF32, uses R6H as its destination. The FPU register read, MOV32, uses the same register, R6H, as its source, and a CPU register as the destination. If a stall occurs in the E3 pipeline phase, then MOV32 will read the value of R6H before the MPYF32 instruction completes.

Example of Problem:

Figure 5 shows the pipeline diagram of the issue when there are no stalls in the pipeline.

Figure 5. Pipeline Diagram of the Issue When There are no Stalls in the Pipeline

Figure 6 shows the pipeline diagram of the issue if there is a stall in the E3 slot of the instruction I1.

Figure 6. Pipeline Diagram of the Issue if There is a Stall in the E3 Slot of the Instruction I1

Treat MPYF32, ADDF32, SUBF32, and MACF32 in this scenario as 3p-cycle instructions. Three NOPs or non-conflicting instructions must be placed in the delay slot of the instruction.

The C28x Code Generation Tools v.6.2.0 and later will both generate the correct instruction sequence and detect the error in assembly code. In previous versions, v6.0.5 (for the 6.0.x branch) and v.6.1.2 (for the 6.1.x branch), the compiler will generate the correct instruction sequence but the assembler will not detect the error in assembly code.

Example of Workaround:

Figure 7 shows the pipeline diagram with the workaround in place.

Figure 7. Pipeline Diagram With Workaround in Place

0, A, B, E, F

The C28x CPU prefetches instructions beyond those currently active in its pipeline. If the prefetch occurs past the end of valid memory, then the CPU may receive an invalid opcode.

The prefetch queue is 8 x16 words in depth. Therefore, code should not come within 8 words of the end of valid memory. This restriction applies to all memory regions and all memory types (flash, OTP, SARAM) on the device. Prefetching across the boundary between two valid memory blocks is all right.

Example 1: M1 ends at address 0x7FF and is not followed by another memory block. Code in M1 should be stored no farther than address 0x7F7. Addresses 0x7F8-0x7FF should not be used for code.

Example 2: M0 ends at address 0x3FF and valid memory (M1) follows it. Code in M0 can be stored up to and including address 0x3FF. Code can also cross into M1 up to and including address 0x7F7.

0, A, B, E, F

The SDA and SCL outputs are implemented with push-pull 3-state output buffers rather than open-drain output buffers as required by I2C. While it is possible for the push-pull 3-state output buffers to behave as open-drain outputs, an internal timing skew issue causes the outputs to drive a logic-high for a duration of 0–5 ns before the outputs are disabled. The unexpected high-level pulse will only occur when the SCL or SDA outputs transition from a driven low state to a high-impedance state and there is sufficient internal timing skew on the respective I2C output.

This short high-level pulse injects energy in the I2C signals traces, which causes the I2C signals to sustain a period of ringing as a result of multiple transmission line reflections. This ringing should not cause an issue on the SDA signal because it only occurs at times when SDA is expected to be changing logic levels and the ringing will have time to damp before data is latched by the receiving device. The ringing may have enough amplitude to cross the SCL input buffer switching threshold several times during the first few nanoseconds of this ringing period, which may cause clock glitches. This ringing should not cause a problem if the amplitude is damped within the first 50 ns because I2C devices are required to filter their SCL inputs to remove clock glitches. Therefore, it is important to design the PCB signal traces to limit the duration of the ringing to less than 50 ns. One possible solution is to insert series termination resistors near the SCL and SDA terminals to attenuate transmission line reflections.

This issue may also cause the SDA output to be in contention with the slave SDA output for the duration of the unexpected high-level pulse when the slave begins its ACK cycle. This occurs because the slave may already be driving SDA low before the unexpected high-level pulse occurs. The glitch that occurs on SDA as a result of this short period of contention does not cause any I2C protocol issue but the peak current applies unwanted stress to both I2C devices and potentially increases power supply noise. Therefore, a series termination resistor located near the respective SDA terminal is required to limit the current during the short period of contention.

A similar contention problem can occur on SCL when connected to I2C slave devices that support clock stretching. This occurs because the slave is driving SCL low before the unexpected high-level pulse occurs. The glitch that occurs on SCL as a result of this short period of contention does not cause any I2C protocol issue because I2C devices are required to apply a glitch filter to their SCL inputs. However, the peak current applies unwanted stress to both I2C devices and potentially increases power supply noise. Therefore, a series termination resistor located near the respective SCL terminal is required to limit the current during the short period of contention.

If another master is connected, the unexpected high-level pulses on the SCL and SDA outputs can cause contention during clock synchronization and arbitration. The series termination resistors described above will also limit the contention current in this use case without creating any I2C protocol issue.

Insert series termination resistors on the SCL and SDA signals and locate them near the SCL and SDA terminals. The SCL and SDA pullup resistors should also be located near the SCL and SDA terminals. The placement of the series termination resistor and pullup resistor should be connected as shown in Figure 8.

Figure 8. Placement of Series Termination Resistor and Pullup Resistor

Table 6 provides series termination and pullup resistor value recommendations. The I2C signal level and respective V_DDIO power supply voltage is shown in the first column. Two resistor value combination options are provided for each voltage. One option supports a maximum high-level input current of 200 uA to all attached I2C devices, while the other option supports a maximum high-level input current of 100 uA to all attached I2C devices.

0, A, B, E, F

The Cortex-M3 HWBIST and C28x HWBIST can only be run when both M3SSCLK and C28SYSCLK are at or below the maximum frequency given in Table 7.

Set the device clock frequencies per Table 7 if using HWBIST. The maximum frequency depends on if the C28x-to-Cortex-M3 clock ratio is 2:1 or 1:1, and if the HWBIST is executed on only one CPU or both CPUs.

For part numbers with lower maximum frequencies than shown in Table 7, the lower frequency that is in the F28M36x Concerto™ Microcontrollers Data Manual still applies.

0, A, B, E, F

Execution of C28x HWBIST with EPI enabled could result in unexpected device behavior. This advisory does not apply if the EPI is disabled.

1. The C28x may stall (C28x code execution will not resume) after HWBIST is executed when the C28x has write access to the EPI. The only recovery from the stalled condition is a reset of the C28x subsystem.
2. Spurious writes may occur on the EPI pins.

Either of two workarounds listed below must be implemented before initiating a C28x HWBIST test interval.

1. The Cortex-M3 should disable C28x write access to the EPI by setting the MEMPROT register (0x400F_B938) to 0x55.

If the EPI interrupt (INT12.6) has been enabled in PIE in the C28x application, it must be disabled before starting HWBIST. After HWBIST completion, the user should clear the MEMPROTERR flag in the CEPISTATUS register and the status bit for INT6 in the PIEIFR12 register, and then reenable the PIE interrupt for EPI.

2. The Cortex-M3 should disable the EPI. The EPI peripheral clock can be disabled by using the Driverlib function SysCtlPeripheralDisable(SYSCTL_PERIPH_EPI0) found in controlSUITE™.

The EPI can be restored to its original configuration after the C28x completes the HWBIST test interval.

A, B, E, F

The Real-Time Window (RTW) module may get reset when a C28x HWBIST is in progress.

The RTW feature of the EPI must be disabled before executing a HWBIST. After executing the HWBIST, the RTW needs to be reconfigured.

A, B, E, F

The C28x and C28x DMA AHB bridge may get reset during HWBIST execution.

All pending EPI accesses should be completed from the C28x and C28x DMA, and the CEPISTATUS register should be cleared before entering HWBIST. There is no restriction on the Cortex-M3 use of the EPI during C28x HWBIST execution.

0, A, B

Using the HWBIST feature on the C28x CPU can cause unpredictable behavior in the C28x subsystem.

None. The C28x HWBIST should not be used on the revisions affected.

0, A, B, E, F

There is a potential signal latch-up to V_SS condition identified on pins GPIO38 and GPIO46. In this condition, an on-chip path to V_SS is turned on, which can bring down the logic level of these pins below V_IL and V_OL. The condition can occur when the pin is in input or output mode and with any of the alternate functions muxed on to this pin.

The condition is more likely to occur at high temperatures and has not been observed below 85°C under normal operating use cases. The triggering event is dependent on board design and the speed of signals switching on these pins, with fast-switching transients more likely to induce the condition. The condition has only been observed when the signal at the device pin has a rise time or fall time faster than 2 ns (measured 10% to 90% of V_DDIO).

The condition will resolve upon toggle of the IO at a lower temperature.

Try one of these two options:

• Option 1:

Avoid the use of these pins in the revisions affected.

• Option 2:

This condition is not seen on all products. Many PCB designs have enough capacitance and slow enough edge rates that the condition does not occur. If the application can be tested and functions correctly with the temperature margin above the end-use temperature, then no action may be required. If the issue is seen or additional margin is desired, then the following can be applied.

If the pin is configured as an output without any other pullup or driver connected:

• Place a capacitor of 56 pF or greater between each of these pins and ground, placed as closely as possible to the device. This will slow down the fast transient and avoid triggering the condition. Larger capacitors will be more effective at filtering the transient but must be balanced against the PCB level timing requirements of these pins.

If the pin is configured as an input:

• Connect a resistor in series with any other components on the board such that the total resistance of the driver plus the resistor is 1 kΩ or greater. This will serve two purposes:
  1. Eliminate the fast voltage transient seen at the pin.
  2. Limit the DC current if the shunt to V_SS is activated.

0, A, B, E, F

Each GPIO can be configured to an open-drain mode using the GPIOODR register. (Note that the open-drain feature is only supported on Master Subsystem GPIOs.) However, an internal device timing issue may cause the GPIO to drive a logic-high for up to 0–10 ns during the transition into or out of the high-impedance state.

This undesired high-level may cause the GPIO to be in contention with another open-drain driver on the line if the other driver is simultaneously driving low. The contention is undesirable because it applies stress to both devices and results in a brief intermediate voltage level on the signal. This intermediate voltage level may be incorrectly interpreted as a high level if there is not sufficient logic-filtering present in the receiver logic to filter this brief pulse.

If contention is a concern, do not use the open-drain functionality of the GPIOs; instead, emulate open-drain mode in software. Open-drain emulation can be achieved by setting the GPIO data (GPIODATA) to a static 0 and toggling the GPIO direction bit (GPIODIR) to enable and disable the drive low.

0

Pins GPIO38 and GPIO46 can only be used as USB0VBUS and USB0ID. GPIO and other functions are not available.

None. This is fixed in Revision A silicon.

0

The Cortex-M3 core reads the GPIO state as ‘0’ when the GPIO is mapped to the C28x core. Conversely, the C28x core reads the GPIO state as ‘0’ when the GPIO is mapped to the Cortex-M3 core.

None. This is fixed in Revision A silicon.

0, A, B, E, F

When a single-bit ECC error is detected, the CPU executes the single-bit-error interrupt service routine (ISR). When the ISR returns, the same instruction that caused the first error is fetched again. If the ECC error threshold (ERR_THRESHOLD.THRESHOLD) is 0, then the same error is detected and another ISR is executed. This continues in an endless loop. This sequence of events only occurs if the error is caused by a program fetch operation, not a data read.

Set the error threshold bit-field (ERR_THRESHOLD.THRESHOLD) to a value greater than or equal to 1. Note that the default value of the threshold bit-field is 0.

0

When the flash prefetch is enabled, the SBF and BF instructions will not be correctly fetched from the Flash.

Compile the application code with the –me option to avoid the SBF and BF instructions.

This is fixed in Revision A silicon.

E, F

On silicon revision E, there is a logic change to prevent one CPU from powering down the Flash Pump while the other CPU is using it.

As a consequence of this change, both the Cortex-M3 and the C28x CPU must each power down the Flash Pump without any Flash accesses in between. The Flash Pump will not enter low-power mode if this sequence is not followed.

The F28M3xx_examples_Dual\Sleep_Low_Power_Mode_Wakeup example in controlSUITE can be used as a reference.

Along with the automatic power down, the Flash bank can be forced into its low-power mode. To force the Flash to power down completely, execute the following procedure from RAM (and not from Flash):

1. When the system is ready to power down the Flash completely, synchronize the Cortex-M3 and C28x CPUs. The Cortex-M3 will enter its Flash power-down phase (steps 2 and 3) while the C28x will be waiting for it to complete.
2. Change the Cortex-M3 Flash Bank Fall Back power mode to Sleep: M3_FBFALLBACK.BNKPWR = 0.
3. Change the Cortex-M3 Flash Charge Pump Fall Back power mode to Sleep: M3_FPAC1.PMPPWR = 0.

The Cortex-M3 should notify the C28x that it has completed the above sequence. It should wait until the C28x completes steps 4, 5, and 6.

4. Acquire the Pump Semaphore with the C28x.
5. Change the C28x Flash Bank Fall Back power mode to Sleep: C28_FBFALLBACK.BNKPWR = 0.
6. Change the C28x Flash Charge Pump Fall Back power mode to Sleep: C28_FPAC1.PMPPWR = 0.
7. Release the Pump Semaphore from the C28x.

The C28x should notify the Cortex-M3 that it has completed the power-down sequence so that both subsystems may continue. Also note that the PUMPRDY bit in the M3-FMC register space can be used by the application software to identify the current power mode status of the pump. The PUMPRDY bit (and also PMPPWR bit) in the C28x-FMC cannot be used for that purpose.

0, A, B

The maximum ESR values are reduced. For the revisions affected, the data in Table 8 supersedes the data given in the "Crystal Equivalent Series Resistance (ESR) Requirements" table in the F28M36x Concerto™ Microcontrollers Data Manual. The differences between the two tables are highlighted in Table 8.

None

0, A, B

During device power up, the XRS pin may toggle high prematurely. After the V_DDIO and V_DD supplies reach the recommended operating conditions, the XRS pin behavior will be as described in the F28M36x Concerto™ Microcontrollers Data Manual. This is only an issue with the external state of the XRS pin. Internally, the device will be held in reset until the supplies are within an acceptable range and XRS is high.

Disregard XRS activity on the board before the supplies reach the recommended operating conditions.

0, A, B

If the C28x Subsystem is reset while it owns the flash pump semaphore, then the flash pump itself will also reset. Since the flash pump is also used by the Cortex-M3 Subsystem, any instruction fetch or data read from flash by the Cortex-M3 will return invalid data. This will result in a hard fault, incorrect program execution, Cortex-M3 core hang condition, or an unspecified error in the application.

This erratum does not apply if the C28x Subsystem never writes to the CPUMPREQUEST register to take ownership of the flash pump semaphore.

The Cortex-M3 must not access flash while the C28x holds the flash pump semaphore ownership. The following steps describe how this can be achieved:

1. At application start-up, the C28x reads the CPUMPREQUEST semaphore register. If it is the owner, the C28x relinquishes the flash pump semaphore.
2. When the C28x wants to own the flash pump semaphore, it must notify the Cortex-M3 and wait for an acknowledgement.
3. The Cortex-M3 application branches to RAM and notifies the C28x that it has done so. Any data being accessed by the Cortex-M3 must also reside in RAM at this time.
4. The C28x takes ownership of the semaphore.
5. The Cortex-M3 will refrain from accessing the flash until the C28x releases ownership of the flash pump semaphore.

0

When the USB controller is operating as a Host and a low-speed packet is sent to a device through a hub, the subsequent Start-of-Frame is corrupted. After a period of time, this corruption causes the USB controller to lose synchronization with the hub, which results in data corruption.

None. This is fixed in Revision A silicon.

0

On Revision 0 silicon, the Control Subsystem (C28x core) cannot access the EPI. Only the Master Subsystem (M3 core) can. Starting with Revision A silicon, the C28x has read and write data access to the EPI peripheral. Note that C28x use of the EPI for program execution is not supported in any silicon revision.

This is fixed in Revision A silicon.