This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Storing GPIF Constants in XDATA

Hi there!

I am using the evaluation version (4k) of the C51 compiler with a Cypress CY7C64603 device. I am trying to use the GPIF section of this device using a set of variables stored as:

const char xdata WaveDesc[128]={...};

When I store this many constants in xdata the code does not run; there are no errors during compilation, it just doesnt work. I know the values I am using are correct, as I have implemented the initialisation of the GPIF using an un-rolled version and it works correcly ie:-

Dest++ = 0x00;
Dest++ = 0x00;
...
Dest++ = 0x00;

rather than the much more compact

for(x=0; x<128; x++){
Dest++ = Source++;
}

where Source is a pointer to a char in WaveDesc and Dest points to the appropriate register.

I have also determined that it is definatly to do with the amount of constants in memory, as a piece of code which works without it does not work if the array is defined, even though the code does not use the array.

The code and values are produce by the Cypress GPIF tool, so they should be correct (they look OK to me).

I have found that any array greater than 16 digits in length will stop it working.

Does anybody have any ideas as to what is going wrong? I dont entirly understand the memory structure of this device yet so it could well be somthing simple, but I cant see it!

Thanks in advance

Richard

  • shouldn't you be dereferencing those pointers?

  • Neither this:

    Dest++ = 0x00;
    Dest++ = 0x00;
    nor this:
    for(x=0; x<128; x++){
     Dest++ = Source++;
    }
    can possibly be the actual code you're using --- they both contain massive syntax errors. So, what does your code really look like?

    I have found that any array greater than 16 digits in length will stop it working.

    16 digits meaning what? You can't be talking about 16 digits in the usual sense here, for various reasons, including the fact that the 4K eval version cannot possibly produce anything of that size..

  • OK, sorry for the mis-understanding.

    In my actual code I have done this

    *Dest++ = 0x00;

    and

    *Dest++ = *Source++;

    By 16 digits I meant an array of 16 characters.

    Hope this clears things up!

    Thanks again

    Richard

  • It clears up a bit, but not enough. The description of what your code is doing is still very round-about and vague.

    A minimal, but self-sufficient example would be better.

    You say your code "doesn't work" --- but how does it fail to work? How far does it get, after a reboot? What happens if you try it in the simulator?

    The fact that it fails by just adding an array to xdata (and the initializer array to CODE) causes the program to fail points at some piece of the remainder of the code being the real source of this problem. The additional memory usage may just trigger a hidden bug.

  • "The additional memory usage may just trigger a hidden bug."

    Have you checked the Linker listing ("map" file)?

    If you haven't set your linker options properly, or your device has some peculiarities in its memory map, it's possible that the linker won't spot when you've run off the end of available RAM, or placed something at a location that should be reserved?

  • What I am trying to achieve is the copying of a constant array of 128 characters, to 128 consecutive registers in external data space. The example given uses the following form:-

    const char xdata Wave_Data[128] = {0xFF, ..., 0x00};
    unsigned char xdata *Dest;
    ussigned char xdata *Source;
    
    
    Source = WaveData;		// Transfer the GPIF Tool generated data
    	Dest = &WFDESC[0];
    
    	for (x = 0; x < 128; x++)
    			*Dest++ = *Source++;
    
    
    The device is the Cypress CY7C64603 and the registers I am writing to are the waveform descriptors (for the GPIF hardware), address range 0x7900 - 0x797F.

    Using this method there were no errors or warnings from the compiler, the code just did nothing (I have the serial line working and it does not do anything either).

    I then tried the alternative method of writing a value to each register in turn, using the same values for the registers:-

    WFDESC[0] = 0xFF;
    .
    .
    .
    WFDESC[127] = 0x00;
    

    This works with no problems, the GPIF hardware generates the correct waveform to communicate to the peripheral (a CPLD) and the serial UART can send and receive characters. This is fairly heavy on program memory, so I would like to use the first method. I have also tried a method which combines these two methods, with two short arrays holding data, which is written to with pointer manipulation, and the few registers which require different values are written by array indexing.

    const char xdata Wave1[] = {0x0F,0x17,0x1F,0x27,0x2F,0x37,0x3F,0x07};
    const char xdata Wave2[] = {0x00,0x09,0x12,0x1B,0x24,0x2D,0x36,0x3F};
    
    	Dest = &WFDESC[0];
    	for(y = 0; y < 2; y++){
    		Source = &Wave1[0];
    		for (x = 0; x < 8; x++)
    				*Dest++ = *Source++;
    		for (x = 0; x < 8; x++)
    				*Dest++ = 0x00;
    		for (x = 0; x < 8; x++)
    				*Dest++ = 0xFF;
    		 	Source = &Wave2[0];
    		for (x = 0; x < 8; x++)
    				*Dest++ = *Source++;
    	}
    // there is more, but this gives the idea
    
    	WFDESC[66] = 0x04;
    	WFDESC[71] = 0x07;
    	WFDESC[74] = 0x02;
    
    This is where it gets _really_ wierd!
    If I include the line
    	printf("0xbb trying to make this work");
    
    the GPIF works, but the string sent to the PC is "'/7?" (The Com. Port is definatly set correctly).
    If I alter the length of the string in any way the entire code does not function (again no errors or warnings, it just does nothing when loaded).

    SO...
    Looking at the map file I can see no problems with the memory layout. Wave1 and Wave2 are placed at X:0000 and X:0008 respectivly, and code starts at C:0082. (I believe code and data share the same physical RAM address's so there must be no overlap- any clarification on this point would be appreciated).
    Any help will be much appreciated, as my head is now spinning!

    Thanks again

    Richard

  • Have you examined the generated assembler?

    Could there be a timing issue here?

    "I believe code and data share the same physical RAM address's [sic] so there must be no overlap- any clarification on this point would be appreciated)"

    The 8051 has separate code & data address spaces.