TMS570LS3137 HDK - Running software into SDRAM via the EMIF - Stuck in prefetchEntry state at first instruction

Benjamin,
Thank you for the detailed information.
One question for you is this: Doesn't your SDRAM section overlap STACK and RAM sections? If so, I wonder if you are over-writing stuff you need.
Best Regards,
Kevin Lavery

You should confirm that the code is copied to the SDRAM correctly first.

Make sure you can open a memory window to view SDRAM and see the code get copied.

If you have a timing problem or configuration problem in your SDRAM setup in HalCoGen, it may either get copied incorrectly or with errors.

The HDK also has a jumper on it which physically disables the SDRAM you should make sure this jumper is off.

Performance when running code from SDRAM is going to be poor on this device.   SDRAM is included mainly for data storage / large buffers for DMA based peripherals.  

If you need to execute code from SDRAM - the TMS570LC4357 or RM57L843 are the parts I would suggest from the Hercules family.   The 32K instruction cache makes execution from SDRAM a lot more practical.

-Anthony

Kevin Lavery said:

One question for you is this: Doesn't your SDRAM section overlap STACK and RAM sections? If so, I wonder if you are over-writing stuff you need.
 

Hi Kevin,

Thanks for your response.

Regarding to my "MEMORY" section in the linker command file, the SDRAM seems not to overlap any of the other sections. RAM & STACK are located at base address 0x0800 0000 and the SDRAM is at 0x8000 0000.

Anthony F. Seely said:

You should confirm that the code is copied to the SDRAM correctly first.

Make sure you can open a memory window to view SDRAM and see the code get copied.

If you have a timing problem or configuration problem in your SDRAM setup in HalCoGen, it may either get copied incorrectly or with errors.

The HDK also has a jumper on it which physically disables the SDRAM you should make sure this jumper is off.

Performance when running code from SDRAM is going to be poor on this device.   SDRAM is included mainly for data storage / large buffers for DMA based peripherals.  

If you need to execute code from SDRAM - the TMS570LC4357 or RM57L843 are the parts I would suggest from the Hercules family.   The 32K instruction cache makes execution from SDRAM a lot more practical.

-Anthony

Hi Anthony,

Memory window + Software check are OK : the code is copied correctly from "DhrystoneLoadStart" (0x0000 0020 First address of FLASH) to "DhrystoneStartAddr" (0x8000 0000 First address of SDRAM).

for(i=0;i<size;i++)
	{
	    ((char *)&DhrystoneStartAddr)[i] = 0x00;
	}
	UART_PRINT("Memory reseted");
	for(i=0;i<size;i++)
    {
        ((char *)&DhrystoneStartAddr)[i] =((char *)&DhrystoneLoadStart)[i];
    }
	UART_PRINT("Memory Copied");
	for(i=0;i<size;i++)
    {
        if(((char *)&DhrystoneStartAddr)[i] !=((char *)&DhrystoneLoadStart)[i])
        {
        	UART_PRINT("BAD COPY !!!");
        }
    }

The jumper is also clear.

Regarding to the hardware question, I am aware the EMIF is not good for running any code (10x slower), I need to have a measurement of that performance.

I did some digging in ARM abort online troubleshooting and I read that Prefetch Abort occurs when you try to execute code from non-existing memory regions. Why 0x8000 0000 is considered as non-existent memory region ? is it because the EMIF address Width is 16bit ?

After the abort occurs, the LR(purpose register 14) value = 0x80000004

                            CPSR                    value = 0x60000397

hoping these informations may be useful to solve my problem.

best Regards,

Benjamin.

This may be the culprit.

From section A3.5.7 of the ARM v7 - AR arch. manual:

 Any instruction fetch must access only Normal memory. If it accesses Device or Strongly-ordered
memory, the result is UNPREDICTABLE. For example, instruction fetches must not be performed to an
area of memory that contains read-sensitive devices, because there is no ordering requirement
between instruction fetches and explicit accesses.

In which case if you want to execute from SDRAM you would change the type to Normal.

And if you do change to normal, you probably need a DSB barrier instruction between the last data write after the 'copy' and the first instruction fetch...

nice one, That could have been the solution,

I tried these different configurations in HalCoGen :

type : STRONGLYORDERED_SHAREABLE | Permission : PRIV_RW_USER_RW_EXEC

type : NORMAL_OINC_NONSHARED     | Permission : PRIV_RW_USER_RW_EXEC

type : NORMAL_OINC_SHARED        | Permission : PRIV_RW_USER_RW_EXEC

none of these seems to work

I attached my HalCoGen config 8446.HalCoGen Config RunInSDRAM.zip

edit : I just saw your DSB idea. I am not aware of the behavior. I just tried this with no result :

    .text

    .arm

    .def _DSB_

    .asmfunc

_DSB_

        dsb

    .endasmfunc

Hi Benjamin,

Would it be possible for you to send the whole project so we can try to execute / debug it?

sure,

here is my project : 6177.Benchmark_In_Memory.zip

thank you very much for your help btw.

Anthony,

Thank you very much !
This was my problem here.

I wasn't aware of the MPU's initialization needs.

(1) I see the "example_emif_sdram.c" given by HalCoGen is made without MPU initialization. Is this an omission ?

________________________________________________________________________________
I have two more questions, maybe it deserve its own topic...
- I have to develop an application using this TMS570 with a 128Mb SDRAM via the EMIF.
- I need a way to access the Embedded Trace Macrocell (ETM) traces

As I can tell :
- the ETM[8:31] and the EMIF share the same pins. So I can't have full access to ETM signals
- I saw on this forum that with such configuration (19 pins ETM & 330MHz CPU) there is FIFO overflow for full data access.
- The Hercules products did not include ETM trace buffer (ETB) so I can't access the traces via JTAG

(2) Can you confirm the possibility to access some of the ETM traces with only 8 pins ?
(3) Is there a way to allocate a memory space as an ETB (buffer) ?




Best Regards,

Benjamin

Hi Benjamin,

Great questions - unfortunately though you've got a good understanding of the issue.

I'll look into whether the example has an omission or not. I think it may not be *needed* for that example but is probably a good idea given the issue you ran into.

You've got a clear understanding of EMIF v.s. ETM I'm afraid. No on chip ETB and no way to direct the ETM port at RAM.
The ETM has 8 dedicated data lines - so you'll get lots of FIFO overruns if you try to trace everything.

In your specific case - if you are actually executing from SDRAM then it may be that your program runs so slowly on the 3137 that 8 trace data pins would be fine. I think this is probably the case.

The 330MHz device actually has been designed for EMIF || ETM but in a larger package that we have not yet designed :(. In the 337ZWT it has the same limitations on ETM/EMIF.

Best Regards,
Anthony