TMS570LC4357: Boot Problems

Hello Trey,

1. The spna106 is for Cortex-R4. Please use example_safetylib.c for LC4357 as example. This file is in HALCOGen example folder:

C:\ti\Hercules\HALCoGen\v04.07.01\examples\TMS570LC43x

2. Does the device get data abort or instruction abort? If yes, please find the abort status and abort address:

    CCS --> Registers window --> CP15 register --> Data fault status register, and data fault address register.

3. what are the values of ESM status registers when the problem happens?

we have two sets of code we are experimenting with

one is the provided code in this post, and one is something we wrote based on that functionality 

with or without JTAG attached 

in our code we work correctly on a second manually applied reset, but generally never on a power on reset

nPORRST is generated by a watchdog supervisor (pair of TPS3703) looking at correct level of 3.3, 1.2, and then held low for either 10 or 100 ms

on nRST we have a 2.2K/10nF cap

in this case it's manualReset-->TPS3703.MR-->nPORRST

In the provided code we generally work correctly (that is proceed to main) in either case of power on, or manual reset however sometimes we also observe

that sometimes the processor will take a data abort early on when attaching via the jtag, with PC at 0x10, but other times proceed on to main

I'm still trying to get CP15 registers in the case where we have data abort, when in this state and using CCS

going to CCS->Registers window->CP15 sometimes shows a list of undefined registers, or other times just does not let us open that tree of registers.

in the case of the data abort the behavior is similar to this description

https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/680951?Data-abort-right-after-NPORST-enabling

 I've not looked at the 1.2/3.3/nPORRST timing it shows reset is low initially and is released after all voltages are up

we have the rev B part

I've also looked at the OSC clock provided to the part, and it seems to be up during the time the voltages are reaching their final levels

so a couple questions ->

(1) On our board we have nRST generated by 2.2K/10nF cap on nRST, on your dev board it's 10K/1uF, and on the launchpad it's something similar to ours

On power on case does it matter when nRST is released ? Should it be before nPORRST, after or what ?

(2) any ideas on the early data abort case ?

We found the problem after some head scratching - it's exactly the case

We had a code construct to write a register, but in building the value for that write we accessed memory space which was not initialized

IE pre bss copy/constant copy was not yet run

Moving that memory init to earlier on fixes the problem

Normally in this situation one would see a wrong value built up for write, but in the case of this CPU the memory read generates an ECC fail

I'll look a bit further through the dissasembly to see if was a stack access or constant access - I would not expect stack since a write happens first.