|
Hi Kevin The problem with any test is that if you dont know how to excercise a problem, you wont see the problem, and memory tests are no exception. In general the problem is that a problem can occur for almost any mix of 'previous-next' conditions and there are often simply too many of these to consider and test them all. Basically for a memory device you need to run a two level loop test that looks something like this. Note that by writing this in C, device specific timings are all but lost. This *really* needs to be re-cast into assembly on a case by case basis. for(x=0;x<size;x++) RAM[x] = DATA; // init the RAM //--------- for(x=0;x<size;x++) // outer loop { // pre = &RAM[x]; // init pre address post = RAM; // init post address *pre = !DATA // for(test=0;test<size;test++) // { // v0 = *pre; // should read back !DATA v1 = *post; // should read back DATA // v0b= *pre; // maybe do it again? // v1b= *post; // if(v0 != !DATA) fail(); // Do the test *after* so as not if(v1 != DATA) fail(); // to upset the read timings post++; // increment post address } // *pre = DATA; // Put back DATA in sea of data } As you can see this can be a very nasty and long N^2 test, not to mention that you would want to run the test with multiple test values! And we have not even begun to discuss how a cache or other mechanism might play into the problem at hand. The trick is to understand the topology of the RAM and the system that it works in. For example RAM is often internaly broken into blocks and these into rows and columns. These in turn helps create tests that isolate functional blocks of logic. Basically problems need to be 'tickled' into being visible so they can be worked on. And, keep in mind that tickling can take many forms like high/low temperature, supply voltage and clocking rates. We spent a lot of time learning the RAM on the early VC33. Basically one of the hallmark features of the C3x, its ability to 'dual access' RAM on two consecutive half cycles, is if anything atypical. The bottom line was that PG 1.0 and 1.1 silicon had some test holes that got plugged up early in PG 1.2. PG 1.3 silicon went a bit further by adding some features that made this a lot easier to manage in production. Best regards, Keith Larson ----- At 04:26 PM 12/3/03 -0000, you wrote: >First off, many thanks to Bill and Keith for the excellent suggestions which I have passed on to our customer. In response to Bill's request for more information. The board he is using is a commercial one - a FleXDS VC33 DSP module from DSP Research. I've also attached the linker file that he is using. > >The linker command line he is using is: -c -f 0x000 -o DSP1Code.out -stack 0x300 -x > >His program starts off with a self test which just tests the onboard DSP memory then jumps to -cinit00. The self test starts at 0x00809802 but he still gets the same problems if he starts directly at _cinit00. > >What concerns him is that it often goes to completely the wrong place. Basically he's having somewhat of a crisis of confidence with the development tools because he has also seen the debugger returning incorrect values like when using the watch window variable values can be different when traced through to when a break point is set and the code run at full speed. > >I'm trying to help him narrow down which problems are hardware related, which are related to his code and which are related to bugs in CC :-( > >Cheers, > >Kevin +-----------+ |Keith Larson | |Member Group Technical Staff | |Texas Instruments Incorporated | | | | 281-274-3288 | | | | www.micro.ti.com/~klarson | |-----------+ | TMS320C3x/C4x/VC33 Applications | | | | TMS320VC33 | | The lowest cost and lowest power 500 w/Mflop | | floating point DSP on the planet! | +-----------+ |