RM57L843: Cold boot prefetch error

Hi Matthew,

I would like to verify your application code, is it possible to share it or at least a simplest project with the issue?

You can send it through the private message, if required.

--
Thanks & regards,
Jagadish.

I have sent full project code.  Proprietary function has been removed, but all startup and initialization functions are present. I have confirmed this version has same issue.

Hi Matthew,

I ran your code into my demo board and i don't see any issues at my end.

Do we need to do anything else like sending some particular data etc to trigger the prefetch abort?

Matthew Bevacqua said:

On approximately 40% of them I receive a prefetch error

This looks confusion to me as well, why only some 40% boards getting this issue if the code is same for all the boards.

I don't think they will have separate hardware.

Are you making any configuration differences in CCS?

I hope you disabled the Auto ECC generation option, because this is not required as you manually generating the ECC in linker cmd file.

--
Thanks & regards,
Jagadish.

Thank you for looking at the code. I also find it very strange that the problem only occurs on some boards.  It could be hardware issue, but I do not see how.  All boards are Class III inspected during manufacture and verified.  I will check power again.  

What I am having difficulty with is determining exactly what the processor is doing at the time the issue occurs.  I thought, it may have a dabort exception and then the prefetch error was being thrown during the dabort exception handler.  To test, I put in the following while(1); trap in the dabort handler.  Doing this caused it to get stuck in the undef exception handler instead of the prefetch handler.

What is the best way on the ARM to tell if an exception was actually thrown, or if, for some reason, it is simply running the code from these exception handlers instead of the correct entry point.

Hi Matthew,

(+) [FAQ] TMS570LC4357: Troubleshooting the Abort Exceptions on Hercules Devices - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

In above FAQ my colleague discussed how to troubleshoot the exception, can you please refer above thread, and can you please try to find out exactly which address causing the exception. And verify the corresponding address in map file and you can find out exactly which function causing the issue.

--

Thanks & regards,
Jagadish.

Thank you for that.  I removed the interrupt vector mapping from my application so I can confirm no interrupt handler was causing the issue and that the processor is actually in an abort state.  Unfortunately, I am still very confused.  I am familiar with using the status registers to understand where an abort exception occurs.  However, the information does not make sense to me in this case.  The Instruction Fault Address Register reads "0xFFFFFFFE" which is the very end of the memory (and empty).  The R14 register read 0x02 which is the entry point of the program. Also the SPSR_ABT register shows the mode as "abort" which seems to indicate its previous state was "Abort" before it entered "Abort".

I now believe this has to be hardware/power startup issue.  By delaying code execution for an arbitrary 2000 cycles with the below assembly loop the application executes properly.

movs  r0, #1000

loop:

subs  r0, r0, #1

bne   loop

Hi Matthew,

Matthew Bevacqua said:

I now believe this has to be hardware/power startup issue.  By delaying code execution for an arbitrary 2000 cycles with the below assembly loop the application executes properly.

movs  r0, #1000

loop:

subs  r0, r0, #1

bne   loop

This is a great finding.

Matthew Bevacqua said:

On approximately 40% of them I receive a prefetch error when starting from a power-off cold state. 

Did you check any simple LED blinky project on these 40% of boards without the above-mentioned delay work around?

On my understanding if it is due to hardware, it should also occur for this simple project also.

--
Thanks & regards,
Jagadish.

The simplest program I can make is below.  It also exhibits the problem and requires the same work around.  It seems odd that code execution is beginning but the chip is not fully operational.  Will need to look into datasheet to see if I can find anything to explain it.

/* Initialize L2RAM to avoid ECC errors right after power on */
_memInit_();

/* Initialize Core Registers to avoid CCM Error */
SL_Init_R5Registers();

/* Initialize Stack Pointers */
SL_Init_StackPointers();

/* Enable CPU Event Export */
_coreEnableEventBusExport_();

/* Initialize System - Clock, Flash settings with Efuse self check */
systemInit();

/*Peripherals and ports cannot be initialized before system*/
gioInit();

/*Blink Light*/
while(1) 
{
      gioSetBit(gioPORTB, 6, 1);
      for(i=0 ; i<2000000; i++){;}
      gioSetBit(gioPORTB, 6, 0);
}

Hi Matthew,

LED_Blink_TEST_RM57_Launchpad.zip

I tested the above simplest code on my RM57 Launchpad, and it worked without any issues. Can you please check this project on your and can you please let me know if this project also requires workaround that you mentioned?

--
Thanks & regards,
Jagadish.

Confirmed.  Same problem.  Same workaround.

Hi Matthew,

Matthew Bevacqua said:

Confirmed.  Same problem.  Same workaround.

jagadish gundavarapu said:

I now believe this has to be hardware/power startup issue. 

So, i think you are correct it must be due hardware/power startup.

But i never see this kind of issues on our controllers before. I will try to investigate further and will provide my updates.

--
Thanks & regards,
Jagadish.

As a reference, this is my voltage curve on startup.  There is about 43ms from when the IO voltage is in range to when the core voltage is in range.  The data sheet specifically says the onboard power monitor should not start the startup sequence until both are in range and the order is not important.

Hi Matthew,

You are correct, this might be creating the issue?

Is it possible to capture for other working board which doesn't need delay workaround? If we compare for both of them, we can get some idea?

And also, we should need to verify the external components (resistors and capacitors) between 1.2V regulated supply and controller core supply pin. I am suspecting that external components might also affect the power supply curve.

--
Thanks & regards,
Jagadish.

Rise time for 1.2v is the same for working and non-working units.  There is about 116uF of capacitance between the core voltage and ground plus 9ma of load for a voltage sense feedback resistor.  No other components are present.

Hi Matthew,

Matthew Bevacqua said:

Rise time for 1.2v is the same for working and non-working units.

Then it should not be an issue, right?

I will check with my senior colleague once, whether he had any idea about this issue.

--
Thanks & regards,
Jagadish.