OMAP5 uevm NOR flash access

In OMAP5 TRM section "29.3.7.3 XIP memory" you can find the characteristics for XIP memories.

I have next questions to you, if possible to share the answer, if not they could help you to know what could be missing. they are more to the part of NOR specification.

- How big of a region can you see starting at 0x08000000? Is there more than just 0xFFFFFFFF so you can tell if you can see the full size and not shadows?
- Have you issued the unlock command to the parts sector to enable writing?
- When you try to write will the block shift into status modes (showing some data writes made it out?)

I must say that questions were made by other Engineer in order to get more information about the issue.

I tried to find more information but I only found TRM's information in chapter 29, the other questions that could be made like the previous ones are contained in the NOR memory specification that you are using.

Thanks for helping.

About your questions:

- The region is starting at 0x08000000 and ends at 0x09000000, it is 16 MiB NOR flash, at this point everything is seems OK.

- About unlock command. All what I could find is the WP pin connection between board and NOR flash. The output signal is controls via GPMC register. This is it or there is some kind of another write protect mechanism available?

- I do not know what exactly you are meaning with block shifting, but as I can see there is no any additional actions happens at GPMC registers while I'm trying to write.

I found another interesting thing. If I configure SYSBOOT pins start booting from fast XIP mode (0b1111) I can see very similar GPMC register configurations, and NOR flash region which is full of 0xFF. XIP mode (0b1100) do almost the same but maps region to 0x0 not 0x08000000 (GPMC_CONFIG7_0 = 0xF40). I've tried to copy parameters similar to that what ROM code sets, and setup them manually after iboot loads into RAM but as result I have a region with continuously iterative data (0x0, 0x1, 0x2, ..., 0xFFFF) and I think this is not a data on my flash, and again I can't modify it. Very strange that ROM code in XIP mode maps NOR flash with wrong address, or may be there are some conditions why this happens.

I think that configuration parameters is OK, but I miss some very simple step about turning on something.

So finally I solve my issue. The problem was that I do not set correct timing factor during GPMC configure. After I do this I found correct initial NOR flash data. Writing and other commands are working fine.

Thanks for helping.

Hi again.

There is some strange thing. When I try to read CFI flash table, after writting 0x98 to 0x08000154 I got next data:

0x08000000: 0x00010001 0x227E227E 0x00000000 0xFFAFFFAF
0x08000010: 0x00010001 0x00000001 0x00010001 0x00000001
0x08000020: 0x00000001 0x00000001 0x00000001 0x00000001
0x08000030: 0x22422242 0x00000000 0x22212221 0x22012201
0x08000040: 0x00510051 0x00520052 0x00590059 0x00520052
0x08000050: 0x00000051 0x00400040 0x00000041 0x00000041
0x08000060: 0x00000041 0x00000041 0x00000000 0x00270027
0x08000070: 0x00200024 0x00000051 0x00000041 0x00080008

and so on.

Every x32 word consist of two the same x16 words (there is some interference). The same situation is with data. When I wrote for example 0x1234 to 0x08000000 I got this and 0x1234 at 0x08000002 too. The GPMC is configured in x16 mode, the NOR flash is also works only in this mode. I thought I will find something like this, but the first half of the x32 word will be filled with zeros (e.g. 0x00001234) because I have x16 device attached to x32 bus. I'm right? But this situation seems like I have two x16 devices which are used in parallel.

I have seen similar effect in 2 cases,

1. the HW address lines are twisted or one is not correctly connected, probably is not the case but it reminded me it.

2. the Hex viewer needs to be configured to use 16 bits word long, if not some issues visualizing the data could appear or it is reading 32 registers were data is mirrored from lower word.

I am trying to remember what could be the returned value when reading 32bits from 16bits, but I need to check it what could happen in this case.

For regular reading non-CIF flash table, is read data correct?I mean you should have programmed some ASO to access CIF flash table.

I have ready to use microcircuit with NOR chip and I don't think there is some twisted lines, at least I hope =)

Actually this data was made with pointer access via printf() function. I have GPMC region starting at 0x08000000 and read every word of 4 bytes and print it. The same picture is when I read every 2 bytes word.

So as I understand there are some problems with data displaying or mapping. But the address space on NOR chip is expected to be correct. The data are somehow mirrored. So if I somehow will program it with bootloader data, will It work as expected if I boot from XIP?

I still need to finish reading the NOR specification, but I was thinking in some test to do in the writing code to be reflected when reading it, but I noted that you are reading fixed bytes from internal memory, that means you didn't wrote them and the issue should be in the reading procedure or memory access procedure, at least it is what I can think of it.

Next is only a comment trying to find what is wrong but it doesn't mean an action path, just a comment for what I thought it could be a twisted address lines issue.

The strange thing is that the mirrored pattern is not happening in all the cases, for example 0x08000034 and 0x08000050 they are not duplicating the information from lower word to upper word. Depending on used endianness the addresses could change but there is one pattern.

it is one
0x08000014 - 0x00000001

it is five contiguous

0x0800001C - 0x00000001

0x08000020 - 0x00000001

0x08000024 - 0x00000001

0x08000028 - 0x00000001

0x0800002C - 0x00000001

then it is repeated again

0x08000050 - 0x00000051

and five again, last is zero then it is not possible to know for certain,

0x08000058 - 0x00000041

0x0800005C - 0x00000041

0x08000060 - 0x00000041

0x08000064 - 0x00000041

0x08000068 - 0x00000000

trying to find the next is not visible, only these three but then it is lost not following the same sequence as the previous ones, it is 3 not 4 and the address doesn't seems to show a possible twisted line since there is no pattern that matches this behavior.

0x08000070: 0x00200024 0x00000051 0x00000041

By using this view process is difficult to know if writing process was correct or not, I mean if it was needed to check by finding a pattern in the reading process to know if writing is correct or not. Something I am thinking is in the write process maybe adding a check code to read the written byte in a verification way, I mean reading will be using the the same configuration than when writing, but it would vary depending on writing method, just an idea.

Have you tried using JTAG? the Engineer that helped with the questions about memory access told me that it may include some scripts to write to memories, but I don't have much information about it.

Sorry for not being able to help much.

What I can tell about this strange repeats. There are several situations:

• When there is Flash Memory Array address and I try to write some data using Embedded Algorithm (EA), for example 16 bit word (0x1234) at start address 0x08000000 it repeats at 0x08000002, look like 0x12341234. Sometimes if I change a data to write, it writes not the new data, but previous.

• If I write 512 bit buffer, for example a counter, there can be gaps in the data, e.c. first four 32 bit words are zeros, the next are iterative, but again only repeated odd numbers (0x00010001 0x00030003 ...).

• When I read ID/CFI table there is the most interesting. All data are again repeats, but the low 16 bit are not constant, they are changed. Via JTAG this is look like blinking with data. If I read a sector the data i different samples are different. There are for example two serial data reads (16 bit word).

0x08000000: 0x0001 0x0001 0x227E 0x227E 0x0000 0x8000 0xFFAF 0xFFAF
0x08000010: 0x0001 0x0000 0x0001 0x0000 0x0001 0x0001 0x0001 0x0001
0x08000020: 0x0001 0x0001 0x0000 0x0001 0x0001 0x0000 0x0001 0x0000
0x08000030: 0x2272 0x2242 0x0000 0x0001 0x2221 0x2221 0x2201 0x2201
0x08000040: 0x0051 0x0051 0x0052 0x0052 0x0059 0x0059 0x0052 0x0002
0x08000050: 0x0051 0x0051 0x0040 0x0040 0x0000 0x0041 0x0041 0x0000
0x08000060: 0x0051 0x0000 0x0041 0x0000 0x0041 0x0041 0x0027 0x0007
0x08000070: 0x0026 0x0026 0x0000 0x0001 0x0051 0x0000 0x0008 0x0008
0x08000080: 0x0002 0x0002 0x0002 0x0002 0x0018 0x0018 0x0001 0x0009
0x08000090: 0x000A 0x0002 0x000B 0x0003 0x0008 0x0018 0x0001 0x0000
0x080000A0: 0x0009 0x0009 0x0000 0x0000 0x0000 0x0000 0x0000 0x0001
0x080000B0: 0x0009 0x0001 0x007F 0x007F 0x0001 0x0001 0x0000 0x0001

0x08000000: 0x0001 0x0001 0x227E 0x227E 0x0000 0x0000 0xFFAF 0xFFAF
0x08000010: 0x0001 0x0001 0x0000 0x0001 0x0001 0x0000 0x0001 0x0000
0x08000020: 0x0001 0x0001 0x0000 0x0001 0x0000 0x0001 0x0000 0x0001
0x08000030: 0x2272 0x0000 0x0001 0x0000 0x2221 0x2221 0x2201 0x2201
0x08000040: 0x0051 0x0051 0x0052 0x0052 0x0059 0x0059 0x0052 0x0002
0x08000050: 0x0051 0x0000 0x0040 0x0040 0x0051 0x0051 0x0000 0x0041
0x08000060: 0x0041 0x0051 0x0000 0x0041 0x0051 0x0000 0x0006 0x0027
0x08000070: 0x0027 0x0020 0x0051 0x0041 0x0001 0x0041 0x0008 0x0008
0x08000080: 0x0002 0x0002 0x0002 0x0003 0x0018 0x0018 0x0009 0x0001
0x08000090: 0x000A 0x000A 0x0003 0x000B 0x0018 0x0008 0x0000 0x0001
0x080000A0: 0x0009 0x0001 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000
0x080000B0: 0x0009 0x0009 0x007F 0x007F 0x0009 0x0000 0x0001 0x0000

Manuel Contreras said:

in the write process maybe adding a check code to read the written byte in a verification way

I implemented such a code. After EA commands executing I'm waiting for their success status. There are results, for chip erase EA I got 0xFFFF0000 status and for buffer program EA 0x00000040. There is no mirroring seems.

I do not have any scripts for memory access via JTAG, all what I do is dumping selected region. Also I write sequence of commands to access different Address Space Overlays, but they are the same as mentioned in TRM for Spansion S29GL128S. For now I read memory maps using printf() function.

So this is all what I have and I have no idea where can be an issue. But as I understand from your answer there might be an issue with line connections.

Whatever is it, thank you for helping!

My comment about the twisted connections is not happening, or at least I cannot probe it base in the provided Hex dump, that was one idea I had after seeing the data dump, doesn't mean it is happening I must clarify it.

From you last comment about printf I have one idea, using printf to access the values directly from the memory address could be tricky about the use of the pointers. Maybe storing the information in temporal variables then printing them, it could be done using fixed variables to store values from memory then use those values to be assigned to pValue3 and pValue3 not being a pointer. (maybe checking carry bit in shift operation with & 0xFFFF0000)

#include <stdio.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>

int main (int argc, char *argv[]) {
    unsigned char cData[] = { 0x00, 0x01, 0x02, 0x03,
                              0x04, 0x05, 0x06, 0x07,
                              0x08, 0x09, 0x0A, 0x0B,
                              0x0C, 0x0D, 0x0E, 0x0F};
    unsigned short *pValue1      = NULL;
    unsigned short *pValue2      = NULL;
    unsigned int nValue3        = 0x00000000;
    unsigned int *pValue3        = &nValue3;
    int i=0;

    printf("printing integers using unsigned short values %d %d %d\n",
          (int)sizeof(unsigned int), (int)sizeof(cData),
          (int)(sizeof(cData)/sizeof(unsigned int)));
    pValue1 = (unsigned short*)cData;
    pValue2 = pValue1 + 1;

    for ( i = 0; i < (sizeof(cData)/sizeof(unsigned int)); i++) {
        *pValue3 = ((unsigned int)(*pValue1));
        *pValue3 |= (((unsigned int)(*pValue2)) << 16);
        printf("*pValue1 0x%04x *pValue2 0x%04x *pValue3 0x%08x\n",
            (unsigned int)(*pValue1), (unsigned int)(*pValue2),
            (unsigned int)(*pValue3));
        pValue1 += 2;
        pValue2 += 2;
    }
    return 0;
}

This because the way that printf code is compiled and how it uses a "signed int" or "unsigned int" pointer variable to read a 16 bits data value could not be that specific, maybe reading assembler code to see how it was compiled, or similar issue with the pointers.

The output from previous program is:

printing integers using unsigned short values 4 16 4
*pValue1 0x0100 *pValue2 0x0302 *pValue3 0x03020100
*pValue1 0x0504 *pValue2 0x0706 *pValue3 0x07060504
*pValue1 0x0908 *pValue2 0x0b0a *pValue3 0x0b0a0908
*pValue1 0x0d0c *pValue2 0x0f0e *pValue3 0x0f0e0d0c

I found where was the problem. Address lines was shifted by 1 on the flash, A1 line was missed.

Thank you for your help!

It sounds excellent news, thanks for sharing it.