Using EMIF for data recording

Hi Alex,

The ARM MPU is your best choice to block CPU access to this region.  You can set the region for privilege/non-privilege access, no access/read only/read-write, etc.  I would recommend also configuring the ARM memory type as strongly ordered for this region.  Please reference ARM's Cortex R4 TRM for more details.

Other bus masters also include MPUs which can be used to block access to this region, though they do not have the full flexibility of the ARM MPU.

Regards,

Karl

Please also note that the EMIF CS0 is reserved for an SDRAM interface. You can use any of the other 3 chip selects (2, 3, or 4) to interface to a NOR flash.

Regards, Sunil

Alex,

To access to NOR flash correctly, you will also have to configure R4 MPU to access the memory region in either "strongly ordered" or "device" mode. I personally prefer  the "device" mode. It is more efficient in writing by enabling the write buffer.

Thanks and regards,

Zhaohong

Hi All,

I think I may have underestimated the complexity in accessing the memory / using EMIF.

Zhaohong, Could you explain the write procedure you referenced or point me to the TMR section which talks about write buffers etc, I assume this is part of the EMIF however I have not found the relevant part in the TMR.  To be honest from reading through the EMIF section it looked like the addresses could be accessed in the normal ways eg with a pointer where the EMIF module deals with the memory decives state machine (timings and orders).

Sunil, I can't seem to find any info on this in the TMR, but how does the operation of the EMIF differ when using CS0?

Kind regards,

Alex

Alex,

You can find the definitions of EMIF Slaves on Table2-1 (page 98) in TMS570LS31x/21x TRM.

R4 MPU provides two functions: access permission and access control. Karl has explained access permission in his email. R4 supports 3 access control modes: normal, strongly ordered and device. If you select normal mode, R4 CPU will consider the memory to be accessed as RAM. There could be repeated access for a single access instruction. To avoid repeated access, you need to configure access control to either strongly ordered or device so that CPU considers the access as to a "memory mapped peripheral". In device mode, some writer buffer in R4 CPU is enabled so that w write operation takes less CPU time.

Thanks and regards,

Zhaohong

Alex,

The EMIF issues SDRAM specific commands as soon as it comes out of reset, that is, as soon as system reset is released during initialization. The CS0 is asserted (low) whenever no other EMIF chip select is being asserted. This is described in table 7-2 on page 750 of SPNU499. Also, section 17.2.4.4 on page 756 describes the SDRAM auto-initialization sequence executed by the EMIF module, regardless of whether it is actually interfaced to an SDRAM or not.

Regards, Sunil

Hi Everyone,

Apologies for not stating which TMS570 I'm using in the first post, it seems to have lead to some confusion; I'm using the older TMS570LS20216.

How much of the EMIF info in the TMS570LS31/21 TMR can be applied to the TMS570LS20216? This confusion also explains why I could not find the information you've been referencing.  I will start reading through the EMIF section now.

Regards,

Alex

Alex,

In that case, you can ignore everything I said about the SDRAM interface and about EMIF CS0. The EMIF CS0 on LS20216 is also for an asynchronous memory interface, so you are fine in that regard.

Regards, Sunil

Hi,

I've set up the registers of the timings and the MPU to Device_Non-shareable and PRIV_RW_USER_RW_NOEXEC.

I need to write to specific address ranges, so i'm using the pointer method suggested by ARM at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3750.html

can you confirm this works in CCS, as i'm having issues accessing the external memory and the issues is either due to the timings i've set up or the use of this code.

cheers

alex

Alex,

When you set MPU, you also need to check if the start address and size for the region is set up correctly. You should be able to access external memory as long as the EMIF timing is correctly set. After setting up MPU and EMIF, you may want to view the memory from CCS memory window see if the values are consistent. They should not change each time you "refresh" the display.

Thanks and regards,

Zhaohong

Hi Zhaohong,

Sorry, forgot to mention that i had set the 64Mbit device as a 8Mbyte device with the default starting address for when using CS0.  The memory window consistantly shows all 1s which is what id expect, however im unable to write other data to the address.  i will look into the timings to see if i have made any errors.

kind regards,

alex

Alex,

You will not be able to directly write to a flash memory. You have to program it using the the programming sequence provided by the flash memory manufacture.

Thanks and regards,

Zhaohong

Hi,

yes the NOR flash is being writen to via the programming specified within the datasheet.  hopefully a change in timings will resolve the issue.

cheers,

alex

Hi all,

I will be testing the EMIF tomorrow morning to make sure it is interacting with the NOR correctly, while I'm doing this could you answer my next question?

To make the coding easier I'd like to set up an Array at the start of the CS0 address range, what alterations do I need to make in the sections configuration within the sys_link.cmd file?

How would I then link an array to this region, I've read that malloc creates an array in .sysmem, is this the best way forward and what there the overheads (if there are any)?

To alter the sys_link.cmd file I believe I need to add the following lines, the first line in MEMORY and the second one in SECTIONS

CS0 (RW) : origin=0x0x60000000 length=0x003FFFFF

.sysmem : () > CS0

let me know if I'm on the right track

Cheers,

Alex

Hi All,

I have tried to set up the "Emif_RevCdStat" register to 0xC00F0000 however when I view the register it has the value 0x800F0202, despite this not being the value I was expecting it is also not the value predicted by the TMR, i.e the LSB should be 1 for the minor revision.

On top of this I am not too sure what the major and minor revisions are meant to do as they are not discussed in the TMR or included in the TMR of the updated TMS570 design.

As there seems to be no link between the description used (i.e Emif_RevCdStat or RevCdStat) in the CSS Registers Window and what the compiler within CSS recognises, I've set up the following:

volatile unsigned int *RCSR = (volatile unsigned int *)0xFFFFE800;

volatile unsigned int *A1CR = (volatile unsigned int *)0xFFFFE810;

I have then write to the registers via:

*RCSR = 0xC00F0000;    (fails to write to register)

*A1CR = 0x00000001;    (writes to register, confirmed when trying other "widths")

To try and toggle the data pins I have used the following code:

void NOR_WRITE_TEST (void)
    {
        volatile unsigned short *p = (volatile unsigned short *)0x60000002;
        unsigned int i;
        for(i=0;i<0xFFFFFFFF;i++)
            {
                *p = 0xaaaa;    
                *p = 0x5555;
            }
    }

With this code running I have checked, via oscilloscope, the pins of the NOR, ADD0 is constantly high, all other address pins are low, and there is no signal on the CE/WE/OE/Data pins.

To reiterate, I have set the NOR address range within the MPU to Device_Non-shareable and PRIV_RW_USER_RW_NOEXEC.

I have also altered the timings to various values and still no signal can be seen coming out of the TMS570.

Alex,

Would you please double check the PINMUX settings? You can use the following code to set up PINMUX for EMIF.

/* --------------------------------------------------------------------- */
/*    Configure the IOMM for EMIF pins                                        */
/* --------------------------------------------------------------------- */
/*Unlock the IOMM Register*/
    *(int *) 0xFFFFEA38  = 0x83E70B13;
    *(int *) 0xFFFFEA3C  = 0x95A4F1E0;
/*Configure the IOMM Register*/
    *(int *) 0xFFFFFFA0  |= 0x80000000;
    *(int *) 0xFFFFEB14  = 0x02020101;//P1  //EMIF_DATA[5],EMIF_DATA[4]
    *(int *) 0xFFFFEB18  = 0x01010201;//P2  //EMIF_DATA[6]
    *(int *) 0xFFFFEB1C  = 0x02010102;//P3  //EMIF_DATA[8],EMIF_DATA[7]
    *(int *) 0xFFFFEB20  = 0x01010201;//P4  //EMIF_DATA[9]
    *(int *) 0xFFFFEB24  = 0x02010101;//P5  //EMIF_DATA[10]
    *(int *) 0xFFFFEB28  = 0x02010201;//P6  //EMIF_DATA[12],EMIF_DATA[11]
    *(int *) 0xFFFFEB2C  = 0x02010102;//P7  //EMIF_DATA[14],EMIF_DATA[13]
    *(int *) 0xFFFFEB30  = 0x02010101;//P8  //EMIF_DATA[15]
    *(int *) 0xFFFFEB38  = 0x02010201;//P10 //EMIF_DATA[2],EMIF_DATA[3]
    *(int *) 0xFFFFEB3C  = 0x01020101;//P11 //EMIF_DATA[1]
    *(int *) 0xFFFFEB40  = 0x01010201;//P12 //EMIF_DATA[0]
//    *(int *) 0xFFFFEB48  = 0x01020101;//P14 // EMIF_RNW Read not Write
    *(int *) 0xFFFFEB50  = 0x02010102;//P16 //EMIF_nOE,EMIF_BA[0]
    *(int *) 0xFFFFEB54  = 0x02010201;//P17 //EMIF_ADDR[5],EMIF_nDQM[1]
    *(int *) 0xFFFFEB5C  = 0x02020102;//P19 //EMIF_ADDR[3],EMIF_nDQM[0],EMIF_ADDR[4]
    *(int *) 0xFFFFEB68  = 0x02010101;//P22    //EMIF_ADDR[2]
    *(int *) 0xFFFFEB84  = 0x01010001;//P29    //EMIF_CLK writing 0 to the 8th bit of pinmux

Thanks and regards,

Zhaohong

Alex,

Please ignore my reply. I forgot that you are using TMS570LS20216. Let me do some other checking. Sorry for the confusion.

Thanks and regards,

Zhaohong

Hi Zhaohong,

In my previous message I wrote

volatile unsigned short * p = (volatile unsigned short *)0x60000002;

this should have been

volatile unsigned int * p = (volatile unsigned int *)0x60000002;

As for the setup of the mpu, I've looked through the code and I don't believe Halcogen initiates the MPU, so I've tried including _mpuInit_(); and _mpuEnable_(); but this just causes the TMS570 to hang at the following line in sys_intvecs.asm

dataEntry
        b   dataEntry

The only settings I have changed are in Region 5, I've attached the Halcogen file. 4336.EB-NOR.zip

Cheers,

Alex

Alex,

I found a TMS570LS20216 EVM with external async RAM. I tried CPU and DMA write and reads. They all work correctly.  I am guessing that you are accessing the NORFLASH control keys in wrong 16 bit address because the CPU is BIG Endian.  Would you please send the model number of the NORFLASH so that we can make more specific suggestions?

Thanks and regards,

Zhaohong

Hi Zhaohong,

The NOR flash is S29JL064H.

I'm having issues writing to RevCdStat (Revision Code and Status Register (RCSR)), using the method mentioned previously I seem to be able to write to Async1Cfg (Asynchronous Configuration Registers (A1CR)) but not RevCdStat, is there a reason for this?

Due to this I can't set the EMIF to half rate.

Cheers,

Alex

Though having said that, regardless of the endianness of the NOR.

I should still see the pins (especially the CE pin) moving but I'm not, CE,WE,OE,ADD0-21 and DAT0-15 are all stationary.

Alex

I Thought I would try and see what was happening to the pins while using the auto refresh in the memory window, it turns out this is able to exercise the NOR flash.

So, what is wrong with my setup or the way I am trying to write to the NOR flash?

Alex,

EMIF does not support unaligned access. You are doing 32 bit access at 16 bit address boundary. As indicated in your email, it causes data abort. To access 0x60000002, you have to define you pointer as "short".

I assume that you are using the word (16 bit) mode of S29JL064H and following the EMIF/memory connection block diagram of TI TRM. You need to use following definition for accessing the Flash control keys.

#define FLASH_CTL555            *( volatile short * )( FLASH_BASE + 0xAAA )

#define FLASH_CTL2AA            *( volatile short * )( FLASH_BASE + 0x554 )

The control addresses (0x555 and 0x2aa) in the S29JL064H spec need to be multiplied by 2 for R4 to access correctly.

When you enable MPU, you also have to set up EMIF and other memory mapped peripheral registers into a valid MPU region in device or strongly ordered mode. Otherwise,you will not be able to access them after MPU is enabled.

Please let me know if the above suggestions would solve your problem.

Thanks and regards,

Zhaohong

Hi Zhaohong,

I understand the issue with the TMS being 32bit aligned (something I had not noticed, new to this...) , in order to write to only 16bits of the 32bit structure could I not use a OR mask to differentiate between the upper and lower 16bit. 

Alternatively if the pointer option is easier/more efficient then I'll use that, however I don't understand how it works so could you explain?

Basically I don't understand how you can access an address with a 16 bit pointer when it is located at an address greater than the 16 bit range?  As I understand it if I point to 0x60000002 with a "short" it will truncate and point to 0x0002 instead?

Would you please explicitly state what the value of FLASH_BASE is?

As for the multiplication I now understand why this is needed too.

Even with the pointers would I still not need a mask to write only 16bit? alternatively how would the TMS570 behave if I wrote a full 32bits to an aligned address, would it first access the lower address on the NOR to write the lower 16bits and then access the next address to write the upper 16bits?

Thanks in advance,

Alex

Alex,

FLASH_BASE is the start address of the EMIF CS region used. Fro example, FLASH_BASE = 0x60000000 if CS0 is used.

Let me first explain the difference in pointer types in c-code. 32 bit and 16 bit pointers have the same range (32 bit) . C-compiler generates STR/LDR instructions from the C-code using 32 bit bit pointers. Data abort will be generated if the address is not 32 bit aligned (ending with 0, 4, 8,C).  For  C-code using 16 bit pointers, C-compiler generates STRH/LDRH instructions. Data abort will be generated if the address is not 16 bit aligned (ending with 0, 2,4,6 8,A,C,E).

If you write/read a full 32bit value to an aligned address, EMIF will automatically generate 2 16 bit accesses to external memory. It is OK for reading from Flash. You should not use such access in program/erase because additional access will mess up the program/erase command sequence.

If your Flash is in 16 bit mode, you have to use 16 bit access (STRH/LDRH) in any program/erase operations. Using 16 bit pointer will enable compiler to generate code correctly.

Please let me if the above answers your question.

Thanks and regards,

Zhaohong

Hi Zhaohong,

Thanks for clarifying all that for me!

I have set up the following pointers and constants:

volatile unsigned short *FLASH_BASE = (volatile unsigned short *)0x60000000;
unsigned short Cycle1 = 0x00AA;
unsigned short Cycle2 = 0x0055;
#define NOR_UNLK_555 *(volatile unsigned short *)(FLASH_BASE + 0xAAA)
#define NOR_UNLK_2AA *(volatile unsigned short *)(FLASH_BASE + 0x554)

I can now see the NOR pins being exercised which is good but they don't seem to be quite right.

With the following code, I tried to test the data pins.

for (i=0;i<0xFFFFFFFF;i++)
        {
        NOR_UNLK_555 = Cycle1;
        NOR_UNLK_2AA = Cycle1;
        }

This should have put 0x00AA on the data pins DAT0-15

While the program was running I observed some pins staying constant while others oscillated.

DATA0 - Oscillating, Low -> High

DATA1 - Oscillating, High -> Low

DATA2 - Constant Low

DATA3 - Oscillating, High -> Low

DATA4 - Constant Low

DATA5 - Constant High

DATA6 - Constant Low

DATA7 - Oscillating, High -> Low

I next tried the following code to write two different values in a consecutive manner to the same address.

for (i=0;i<0xFFFFFFFF;i++)
        {
        NOR_UNLK_555 = Cycle1; 
        NOR_UNLK_555 = Cycle2;
        }

This resulted in the TMS570 not exercising the NOR, all pins (CE,WE & Data) were constant.  The address pins instead had the address 0x0002CA applied.  This address was also being applied by the TMS570 when it was running the following code

for (i=0;i<0xFFFFFFFF;i++)
        {
        NOR_UNLK_2AA = Cycle1; 
        NOR_UNLK_2AA = Cycle2;
        }

While in reality I will never be write to the same address, I don't understand the behaviour of the EMIF, why does it ignore consecutive writes to the same address and more importantly why do some data pins oscillate when they should not?

This seems to be the reason why I cant get the NOR flash into program mode.

Kind regards,

Alex

Alex,

Would you please check (1) EMIF configuration and (2) your hardware? I am attaching a simple test which I have verified in reading and write to an external async RAM. You may want to compare the EMIF setting in this test and your test.

5344.EMIF_Throughput.zip

When you monitor EMIF signals with an oscilloscope, I would suggest checking CE,WE, EMIF CLK and one data pin. Use CE as the trigger to the oscilloscope. In this way, you can also check the timing of those important signals when you write to Flash. If needed, we can also help you in reviewing your schematics.

Thanks and regards,

Zhaohong

Hi Zhaohong,

I've had a look at the files you attached, while the EMIF file was helpful the MPU files are in assembly code which I have no experience in.

I tried to compile the code to see if it works but it aborts straight away, I've then spent the last few days trying to integrate it into my code but without success due to the changes in naming between your code and the code generated by Halcogen, simple substitution has not worked, nor anything else I tried.

With halcogen, assembly code is generated within _mpuEnable_ and _mpuSetRegion_ etc now I cannot see where this is called and CCS does not know how to deal with it (coding errors) when I call it myself.

The timing of the pins looks to ok, Its the function of them that seems to be the proble (see previous posts for details) I have not checked the EMIF CLK as it is not accessible (due to fbga) or used.  As for the connections, all are direct connections form one pin to its counterpart on the NOR flash with a a pull up on the NOR's reset pin.  This setup has been used successfully with a PIC18.

Cheers,

Alex

Alex,

Would you please double check the connection of address pins for 16 bit mode? It should to be following.

EMIF BA1 <-> Nor A0

EMIF A0 <-> Nor A1

EMIF A1 <-> Nor A2

... ...

EMIF A20 <-> Nor A21

You also need a pull up at BYTE# pin of norflash to enable 16 bit mode.

Thanks and regards,

Zhaohong

Hi Zhaohong,

Unfortunately it seems I missed that tiny footnote on page 334.  If TI are planning to update the TRM/Datasheet I highly recommend re-iterating and maybe expanding on this point, especially in the pin description of the datasheet which implies it is only for 8-bit access.

The hardware can not be changed so I am after a software solution, first I will have to change the MPU region to be a 16Mb device.

As for addressing there seems to be a bit of a mess, possibly due to how the EMIF interfaces/short/int etc

0xAAA on the TMS570 outputs 0x555 while for the other program address things do not work so well

0x552 produces 0x2A9

0x553 produces 0x2A9

0x554 produces 0x2AB

The address I need is between those two!

Can you confirm this for me?

Cheers,

Alex

Alex,

You are right for the address. Are you using 16 bit or 8 bit mode? This EMIf supports 16 bit mode.

Thanks and regards,

Zhaohong

Hi,

Yes I am using 16bit mode.

Alex

Hi Zhaohong,

This current situation does not make any sense, I've retested the the output from the TMS570 and can reconfirm the following:

Firstly, when a write is tried at 0x60000AAA, the NOR pins A[0:21] observe 0x00555.

Secondly, when a write is tried at 0x554, the NOR pins A[0:21] observe 0x002AB.

Now, this brings a few questions to mind:

If the NOR's A0 is meant to be connected to EMIF BA1, then why does the first write show the address 0x000555?  If the TMS570 was outputting on the pins EMIF BA1 and EMIF A[0:20], then the address observed by the NOR would be 0x0002AA.

This goes for the second write too, the NOR should observe 0x000155, rather than the 0x0002AB that it currently observes.

In addition it looks like the pin A0 is constantly pulled high, this is at all the addresses I've tried, I've checked and made sure it is not shorted to 3V3 or any of the other possible connections as well as making sure it is connected to the EMIF A0 pin.  I've also tested the address seen by the NOR chip when the TMS570 writes to 0x60000000, the output is 0x000001.

Why would the TMS570 be keeping EMIF A0 high?

Regards,

Alex

Alex,

If you can send your complete norflash test, I can re-run the test as is on a board with external async SRAM. I can check check the contents in RAM at locations you tried to write.

Thanks and regards,

Zhaoohong

Hi Zhaohong,

Here is my up-to-date project files.

0702.EB-EMIF-TI.zip

Cheers,

Alex

While experimenting with the code I have found scenarios where A0 is in the logic low state, but this only occurs when there is a malfunction with the EMIF, where it constantly outputs 0x00016A no matter what TMS570 address I write too.

Alex,

Would you please reorganize the project? There is one include path "D:\PhD\TI\Global Inculde" missing.

Thanks and regards,

Zhaohong

Hi,

Sure, this is much appreciated, the missing files are the files I borrowed from your example.

Here is the self contained project.

3554.EB-EMIF-TI.zip

Kind regards,

Alex

Alex,

It seems that there is something wrong with your software. It does not write into external memory in my test board. I need to debug at assembly level. I hope to find more details next week.

Thanks and regards,

Zhaohong

Hi Zhaohong,

I had a look at my code and yes there was something wrong with it, I've now corrected it, the project I'm now attaching shows the behaviour described in the previous posts.  I've tested the NOR but starting the address at 0x60000000 (0x000000) and incrementing it from there.  It shows that the BA1 pin is being toggled, or at least I assume so, the NOR does not observe a pin change until the address 0x60000004.

In one instance of testing the NOR flash (from a "Restart" in CCS) the address A0 became active (i.e as per the address accessed the pin showed either a 0 or 1), however after another "Restart" (with no change in code, break points or any other feature) the address became unresponsive once more and has remained so despite many "Restarts" since.

4774.EB-EMIF-TI.zip

Kind regards,

Alex

Alex,

"Restart" only sets PC to the location of "c_int00". To make the code execution repeatable, you need to have a clean start every time. I would suggest you always do an "advanced system reset" followed by a "CPU" reset. If your code is already programmed into Flash, you do not need to load it any more.

Thanks and regards,

Zhaohong

Hi Zhaohong,

Ok, I will use that procedure from now on.

To look closer at the function of the EMIF I've used the following project where I've either run NOR_READ or NOR_WRITE independently.

8400.EB-EMIF-TI (NOR_WR).zip

To add to the picture here are some shots of the oscilloscope.  The following image is for NOR_WRITE, where Blue = CE, Green = WE, Red = A0 and Yellow = A1, all signals have been moved on the voltage scale to allow for easier viewing and reducing the risk of one signal masking the other (eg CE and WE), while the noise on the yellow line is due to the probe.

I've also tested with Green = OE, just to see if anything was happening.

The following image is for NOR_READ, where Blue = CE, Green = OE, Red = A0 and Yellow = A1

Again I checked WE, Green = WE:

In all, the pins WE and OE are not functional (though I'm sure that at on point in this project they were).  For NOR_READ the CE is operating as expected, 2 cycles per A0 cycle.  While for the NOR_WRITE there is no logical reason for the asymmetrical behaviour of the CE pin, especially as the code is identical to NOR_READ.

Regards,

Alex

Alex,

I have tried the software you sent in the early morning. It can write to the external memory in my test board correctly. I wonder if there is a connection problem on WE between TMS570 and Norflash on your board. EMIF OE is a input signal. Norflash drives it to indicate data readiness during read operation. You should not see OE toggling during write operation.

Thanks and regards,

Zhaohong

Hi,

Yes, the OE should not toggle during write operations or vise versa, but as the TMS570 is not operating as expected I'm prepared to explore every avenue.

On the NOR flash the OE pin is an input. The TMS570 datasheet shows the OE pin as an I/O how can I turn it into an output and use it as one?

The WE connection has been tested as far as possible, with it confirmed form NOR pin to the fanout VIA before connection to the ball within the FBGA, the reflowed FBGA/PCB has also been x-rayed and there is no sign of any abnormality at that connection or those around it (which all function correctly).  The connection has also been confirmed pad to pad on non-populated boards.

Alex

Well there has been progress.  There's no reason for the progress (no change in settings), so I wont be surprised if it does not work when I boot it up tomorrow.  However I'm going to live in hope. 

Out of curiosity I downloaded and tried to run the project I posted this morning, it now works, without any changes.  In case it helps, to load a project I set it as "Active Project" then right click once more and select "Debug As" then "Debug Session".  Is the TMS570/ XDS100v2 @ 1MHZ a possible cause of the erratic TMS570 behaviour?

Anyway there are still issues with the signalling so here is the new project:

2642.EB-EMIF-TI - 21.zip

Here is an image of the signals for writing to the addresses 0x60001554, 0x60000AA8 and 0x60001554 (these are the program addresses (555,2AA and 555))

and the first read at 0x60000000

where Blue = CE, Red = A0, Green = WE and Yellow = OE

As you can see OE is perfect while WE is triggered 3 times per CE cycle with the last one occurring after A0 has changed, also 555 and 2AA are identical despite A0 should be 1 for 555 and 0 for 2AA.  Why is A0 changing mid write?

Regards,

Alex

Alex,

Three WE pulses for one write instruction indicates that the external memory space is configured in normal mode. Which version of Halcogen tool do you use? Can you try the assembly code I in the project I sent earlier?

Thanks and regards,

Zhaohong

Hi Zhaohong,

The version of Halcogen I'm using is 03.01.01

I'll try your code again once I get to the lab later.

When you say normal mode you mean the Normal/Strobe option in A1CR register?  Last night I also tried the strobe mode, I cant remember exactly but I'm pretty sure the WE pulses were the same, only the CE pulse changed.

Can you explain why there are 3 WE pulses, only 16 bits are being written to D0-16 at a single address, which to me should be one pulse.

Regards,

Alex

When the code is loaded it runs straight away but there are no signals observed on the line CE,WE,OE or A0.

When halt is clicked in CCS it halts at:

void pabort(void)
{
    while(1);    /* Do not return ... */
}

a break point placed at

Set_MPU_Region (0, 0, 0x2B, 0x308);    // 4MB

or

*(int *)0x60000000 = 0x12345678;
*(int *)0x60000000 = 0x0;
*(short *)0x60000001 = 0x12;

does not result in the code halting, further investigation shows that the system halts after running void System_Init(void)

Regards,

Alex

I can confirm that the EMIF was in normal mode in the previous image.

For Normal A1CR is 0x4C466231, while for Strobe it is 0xCC466231

The following image is of the TMS570 writing to the same three addresses but in strobe mode.

Alex,

I am sorry that I did not explain clearly in my earlier email.

You observed 3 WE pulses for one 16 bit write to Norflash. It is not an EMIf issue. It is caused by R4 CPU. As we discussed earlier in this thread, you have to set R4 MPU to "strongly ordered" or "device" modes for CPU to access norflash correctly. By default, external memory region is considered as "normal" by R4 CPU. It could generate more than one access for one read/write instruction because CPU considers the memory as RAM.

Please check your MPU seting for the norflash region. You see 3 WE pulses because it is set to "normal".

There could be numerous reasons for a test to become in-consistent. First of all, I would recommend performing a "system reset" before each test run. Another thing I normally do in debugging is to replace "b _cint00" at address 0x0 by "b #-8". Every time after reset, I want to make sure to see CPU is locked to address 0x0 without any intervention of debugger. It can be considered one indicator of if CPU is boot up correctly.

Would you please check the reset signals (poower-on-reset and nreset) along with 1.2 and 3.3V supplies. I did see that device could boot up partially (some modules do not come out of reset correctly)  if the rising edge of reset signals is too long. It is normally an intermittent behavior. You may want use TI EVM as a reference for H/W design.

In one of my early replies, I messed up OE with the ready signal. Sorry for the confusion.

Thanks and regards,

Zhaohong