TMS570LS3137: TMS570ls3137 Processor errata Rev C

Hello,

Please find my comments in blue.

CORTEX-R4#27

Debug Reset Does Not Reset DBGDSCR When In Standby Mode.

The debug reset input, PRESETDBGn, resets the processor's debug registers as specified in the ARMv7R Architecture. The debug reset is commonly used to set the debug registers to a known state when a debugger is attached to the target processor. When the processor is in Standby Mode and the clock has been gated off, PRESETDBGn fails to reset the Debug Status and Control Register (DBGDSCR).

CORTEX-R4#33
Processor Can Deadlock When Debug Mode Enables Cleared.

The Cortex-R4 processor supports two different debugging modes: Halt-mode and Monitor-mode. Both modes can be disabled. Bits [15:14] in the Debug Status and
Control Register (DBGDSCR) control which, if any, mode is enabled. Additionally, debug events can only occur if the invasive debug enable pin, DBGEN is asserted. Deadlocks
should not occur when the debug mode is changed. Issue If there are active breakpoints or watchpoints at the time when the debugging modes are
disabled via the DBGDSCR or DBGEN, this issue can cause the processor to deadlock (in the case of a breakpoint) or lose data (in the case of a watchpoint).

The move mentioned issues are pertained to Debug mode, so were the workarounds implemented in CCS10.1.1 tool?

>> I will have to check with the debugger team to confirm if these workarounds are implemented in CCS.

DEVICE#B071

Writes to peripheral registers or peripheral RAM should happen correctly using any of the supported ARM/Thumb2 assembly instructions.

For the above mentioned issue workaround has been given as "Do not perform a burst write to peripheral registers or peripheral RAM using a storemultiple (STMxx, VSTM, VPUSH) instruction concurrent to DMA transactions."

if the C project is written in C and the assembler will convert the C code in to assembly code. Is the workaround addressed in assembler generated code?  

>> That is correct. The compiler can still generate burst write instructions for certain types of code (array copy, structure copy, etc.). The TI ARM compiler has a switch that disables generation of these burst write operations. See this thread for more details: https://e2e.ti.com/support/tools/ccs/f/81/t/523235

CORTEX-R4#67:
Watchpoint On A Load Or Store Multiple May Be Missed.

ALL the following conditions to be satisfied in order to this failure occur,

1. A load or store multiple instruction is executed with at least 5 registers in the register list.
2. The address range accessed corresponds to Strongly-Ordered or Device memory.
3. A watchpoint match is generated for an access that does not correspond to either the first two or the last two registers in the list.

as per workaround "TI recommends the use of the address range masking functionality provided to set watchpoints on an entire region"

How to set breakpoints for masked region?

The "--no_stm" option does only work at a file level already. You could place all code doing memory copies or array management within a specific file on which you use this option.

The performance impact is obviously based on the number of such accesses required in your application.

From within CCS, right-click on the C source file and choose "Show Build Settings", or even "Properties".

Then you can click on the "ARM Compiler" properties under the "CCS Build" option. Click on the 'Edit Flags" button and type in the "--no_stm" option flag for that specific file.

Please ignore the message from CCS. The "--no_stm" flag will still be applied to the compile of this source file.

I will ask the CCS team to comment on the two other issues.