TMS570LC4357-SEP: Running the Controller Above Max Clock

Hi Dhir,

Apologies for the delayed response.

Based on the technical documents provided, here is an analysis of your questions regarding clock speeds and flash programming errors on the TMS570LC43x device.

Operating the device beyond the specified maximum clock speeds is not recommended and can lead to unpredictable behavior and system failure. The standard SCI (UART) module on the TMS570LC43x has a maximum achievable baud rate of 3.125 Mbits/s when using a 100 MHz peripheral clock, making your 5 Mbps goal unattainable with this module under specified conditions. Higher data rates may be achieved by using other peripherals like the MibSPI or FlexRay.

The flash programming errors you are experiencing are characteristic of issues with the flash memory's Error Correcting Code (ECC). When the flash memory contains data with invalid ECC, the debugger can be prevented from writing to or verifying the memory, resulting in the errors you have described.

The datasheets for the TMS570LC43x family specify maximum operating frequencies for the CPU and peripherals to ensure reliable operation. For instance, the TMS570LC43x CPU is specified to run up to 300 MHz or 330 MHz depending on the specific device variant. Operating the microcontroller outside of these specified limits can result in timing violations, unpredictable program execution, and potential damage to the device. The device's behavior is not guaranteed when operated outside the datasheet's electrical characteristics.

The technical documents indicate that the standard SCI module cannot achieve a 5 Mbps data rate while operating within the specified peripheral clock limits.

• SCI Module Limitation: The SCI/LIN module features list explicitly states, "At 100-MHz peripheral clock, 3.125 Mbits/s is the Max Baud Rate achievable". This is the maximum specified capability for the standard UART communication.

To achieve higher serial data rates, you can consider using other on-chip peripherals:

• SPI as UART: The application report "Using the SPI as an Extra UART Transmitter" demonstrates how a MibSPI peripheral can be re-purposed to function as a UART transmitter. The MibSPI is designed for high-speed communications and may be capable of reaching the desired data rates with minimal software overhead.
• FlexRay Controller: The TMS570LC43x includes a FlexRay controller that supports communication rates of 10 Mbps per channel. While not a standard UART, it is a high-speed serial communication option available on the device.

The errors Memory region that is not writable and Verification failed during programming are strong indicators of an ECC-related issue within the flash memory.

The TMS570LC43x microcontroller's flash memory is protected by a Single Error Correction Double Error Detection (SECDED) ECC logic. This feature enhances reliability by correcting single-bit errors and detecting multi-bit errors during memory access.

• ECC Calculation: The 8-bit ECC is calculated based on a 64-bit data word and, importantly, also includes 19 bits of the memory address. This means the same data stored at different addresses will have different ECC values.
• Cause of Errors: When flash memory is erased, all bits (both data and ECC) are set to '1'. However, a block of all '1's for data and ECC is generally not a valid combination for most addresses. When the debugger or bootloader attempts to read an erased location before writing to it, the CPU's ECC logic detects an uncorrectable error because the stored ECC bits (0xFF) do not match the calculated ECC for that address. This causes the CPU to signal an error, which the debugger interprets as the memory being non-writable or failing verification. This can happen due to a previously failed programming attempt or an incomplete erase cycle.

The workaround of pressing the RESET button likely succeeds intermittently by altering the timing of the debug connection, sometimes allowing the debugger to issue a mass erase command before the ECC logic can halt the operation.

The fundamental solution is to perform a full erase of the flash memory. This will reset the entire flash bank, including all ECC data, to a clean state. Once the flash is fully erased, the debugger should be able to program the new application without encountering ECC errors.

--
Thanks & regards,
Jagadish.