c6x | Please help me with this bad DSK 6211 problem!

I've purchased an old DSK6211 on eBay, and I'm having great difficulty running the samples. The samples compile and link, but I one or more `Data Verification Failed at address 0x8000xxxx' (right in the DSK SDRAM memory space) and the program refuses to run correctly. Rebuilding the samples to turn off the L2 cache and fitting all sections into the on-chip L2 memory, the samples (those I can make fit into 64K ram) work just fine and I can program, run and debug as usual if I only use on-chip memory. But as soon as the loader needs to load into SDRAM memory, I get these error and nothing works as it should. Checking things further (with a simple program that fits into L2 to read / write into SDRAM memory), I find that 1/4 of my writes are not being written correctly into SDRAM. If, for example I write a pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, 0x05, 0x05, 0x06, 0x07 and so on. If on the other hand I write the same memory pattern backward (starting from end going toward 0x8000000), then the pattern is written fine! Looking into the GEL file, I've noticed small differences in the EMIF timings between 1.05 and 2.21, but switching back and forth makes no difference! I'm about to pull my hair out as I've been struggling with this for at least 30 hours! Any ideas anyone?? A million thanks for any advice Jean-Pierre (The same problem occurs with Code Composer 1.05 that came with it, and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of RAM, and the DSK jumpers appear set to their default)

Are you sure that there is no problem with the underlying memory SDRAM in external memory. You can run dsktxt.exe which comes with CCS. Regds JS > jeanpierrepoulin wrote: > > I've purchased an old DSK6211 on eBay, and I'm having great > difficulty running the samples. The samples compile and link, but I > one or more `Data Verification Failed at address 0x8000xxxx' (right > in the DSK SDRAM memory space) and the program refuses to run > correctly. > > Rebuilding the samples to turn off the L2 cache and fitting all > sections into the on-chip L2 memory, the samples (those I can make > fit into 64K ram) work just fine and I can program, run and debug as > usual if I only use on-chip memory. But as soon as the loader needs > to load into SDRAM memory, I get these error and nothing works as it > should. > > Checking things further (with a simple program that fits into L2 to > read / write into SDRAM memory), I find that 1/4 of my writes are > not being written correctly into SDRAM. If, for example I write a > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > 0x05, 0x05, 0x06, 0x07 and so on. > > If on the other hand I write the same memory pattern backward > (starting from end going toward 0x8000000), then the pattern is > written fine! > > Looking into the GEL file, I've noticed small differences in the > EMIF timings between 1.05 and 2.21, but switching back and forth > makes no difference! > > I'm about to pull my hair out as I've been struggling with this for > at least 30 hours! Any ideas anyone?? > > A million thanks for any advice? > > Jean-Pierre > > (The same problem occurs with Code Composer 1.05 that came with it, > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > RAM, and the DSK jumpers appear set to their default) >

I have had a bad SDRAM on a 6211 DSK in the past. The symptoms you are describing sound an awful lot like that same problem. Unfortunately, the memory test that comes with the 6211 DSK is not thorough enough to catch the problems that can be encountered - you need a more robust memory test such as one described by Michael Barr in the Embedded System Programming journal, which does an Address Bus test, Data Bus test, and a Device test. I don't know if you can get servicing from TI on the unit now since it's fairly old, but you might want to try.. g. ----- Original Message ----- From: "jeanpierrepoulin" <> To: <> Sent: Thursday, March 17, 2005 9:24 PM Subject: [c6x] Please help me with this bad DSK 6211 problem! I've purchased an old DSK6211 on eBay, and I'm having great difficulty running the samples. The samples compile and link, but I one or more `Data Verification Failed at address 0x8000xxxx' (right in the DSK SDRAM memory space) and the program refuses to run correctly. Rebuilding the samples to turn off the L2 cache and fitting all sections into the on-chip L2 memory, the samples (those I can make fit into 64K ram) work just fine and I can program, run and debug as usual if I only use on-chip memory. But as soon as the loader needs to load into SDRAM memory, I get these error and nothing works as it should. Checking things further (with a simple program that fits into L2 to read / write into SDRAM memory), I find that 1/4 of my writes are not being written correctly into SDRAM. If, for example I write a pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, 0x05, 0x05, 0x06, 0x07 and so on. If on the other hand I write the same memory pattern backward (starting from end going toward 0x8000000), then the pattern is written fine! Looking into the GEL file, I've noticed small differences in the EMIF timings between 1.05 and 2.21, but switching back and forth makes no difference! I'm about to pull my hair out as I've been struggling with this for at least 30 hours! Any ideas anyone?? A million thanks for any advice. Jean-Pierre (The same problem occurs with Code Composer 1.05 that came with it, and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of RAM, and the DSK jumpers appear set to their default)

Thanks for that advice. Testing out the dsk6xtst application, the test does indeed fail, mostly during HPI write. Compiling the source code and tracing through the application, the board does indeed appear to have SDRAM access problem, and I'm not sure what to do at this point. (Maybe I'll look for spare SDRAM parts I have lying about and replace the things) Beware what you buy on eBay!! Thanks for taking the time. It set me off in a new direction and I can now do more scientific testing! Cheers! Jean-Pierre P.S. Anyone with a modern (working) DSK or EVM for sale?? -----Original Message----- From: [mailto:] On Behalf Of Jagadeesh Sankaran Sent: Friday, March 18, 2005 10:42 AM To: jeanpierrepoulin Cc: Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! Are you sure that there is no problem with the underlying memory SDRAM in external memory. You can run dsktxt.exe which comes with CCS. Regds JS > jeanpierrepoulin wrote: > > I've purchased an old DSK6211 on eBay, and I'm having great > difficulty running the samples. The samples compile and link, but I > one or more `Data Verification Failed at address 0x8000xxxx' (right > in the DSK SDRAM memory space) and the program refuses to run > correctly. > > Rebuilding the samples to turn off the L2 cache and fitting all > sections into the on-chip L2 memory, the samples (those I can make > fit into 64K ram) work just fine and I can program, run and debug as > usual if I only use on-chip memory. But as soon as the loader needs > to load into SDRAM memory, I get these error and nothing works as it > should. > > Checking things further (with a simple program that fits into L2 to > read / write into SDRAM memory), I find that 1/4 of my writes are > not being written correctly into SDRAM. If, for example I write a > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > 0x05, 0x05, 0x06, 0x07 and so on. > > If on the other hand I write the same memory pattern backward > (starting from end going toward 0x8000000), then the pattern is > written fine! > > Looking into the GEL file, I've noticed small differences in the > EMIF timings between 1.05 and 2.21, but switching back and forth > makes no difference! > > I'm about to pull my hair out as I've been struggling with this for > at least 30 hours! Any ideas anyone?? > > A million thanks for any advice? > > Jean-Pierre > > (The same problem occurs with Code Composer 1.05 that came with it, > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > RAM, and the DSK jumpers appear set to their default) >

Jean-- I would recommend you to check with this following software for any SDRAM memory related problems(physical) first up...there is also complete health check up option in the software...We have seen few of those bad eggs at our labs...10 of them to be precise! :-( http://eceserv0.ece.wisc.edu/~morrow/software/winDSK6_3_0_3_0.zip --Bhooshan On Fri, 18 Mar 2005 03:24:13 -0000, jeanpierrepoulin <> wrote: > > > I've purchased an old DSK6211 on eBay, and I'm having great > difficulty running the samples. The samples compile and link, but I > one or more `Data Verification Failed at address 0x8000xxxx' (right > in the DSK SDRAM memory space) and the program refuses to run > correctly. > > Rebuilding the samples to turn off the L2 cache and fitting all > sections into the on-chip L2 memory, the samples (those I can make > fit into 64K ram) work just fine and I can program, run and debug as > usual if I only use on-chip memory. But as soon as the loader needs > to load into SDRAM memory, I get these error and nothing works as it > should. > > Checking things further (with a simple program that fits into L2 to > read / write into SDRAM memory), I find that 1/4 of my writes are > not being written correctly into SDRAM. If, for example I write a > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > 0x05, 0x05, 0x06, 0x07 and so on. > > If on the other hand I write the same memory pattern backward > (starting from end going toward 0x8000000), then the pattern is > written fine! > > Looking into the GEL file, I've noticed small differences in the > EMIF timings between 1.05 and 2.21, but switching back and forth > makes no difference! > > I'm about to pull my hair out as I've been struggling with this for > at least 30 hours! Any ideas anyone?? > > A million thanks for any advice… > > Jean-Pierre > > (The same problem occurs with Code Composer 1.05 that came with it, > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > RAM, and the DSK jumpers appear set to their default) > >

Jean-Pierre Poulin- > Testing out the dsk6xtst application, the test does indeed fail, mostly > during HPI write. > > Compiling the source code and tracing through the application, the board > does indeed appear to have SDRAM access problem, and I'm not sure what to do > at this point. (Maybe I'll look for spare SDRAM parts I have lying about > and replace the things) > > Beware what you buy on eBay!! > > Thanks for taking the time. It set me off in a new direction and I can now > do more scientific testing! What .gel file are you using with CCS; i.e. if you go into the CCS Setup program, what's the Initial Gel file set for? -Jeff > -----Original Message----- > From: [mailto:] On > Behalf Of Jagadeesh Sankaran > Sent: Friday, March 18, 2005 10:42 AM > To: jeanpierrepoulin > Cc: > Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > Are you sure that there is no problem with the underlying memory SDRAM > in external memory. You can run dsktxt.exe which comes with CCS. > > Regds > JS > > > jeanpierrepoulin wrote: > > > > I've purchased an old DSK6211 on eBay, and I'm having great > > difficulty running the samples. The samples compile and link, but I > > one or more `Data Verification Failed at address 0x8000xxxx' (right > > in the DSK SDRAM memory space) and the program refuses to run > > correctly. > > > > Rebuilding the samples to turn off the L2 cache and fitting all > > sections into the on-chip L2 memory, the samples (those I can make > > fit into 64K ram) work just fine and I can program, run and debug as > > usual if I only use on-chip memory. But as soon as the loader needs > > to load into SDRAM memory, I get these error and nothing works as it > > should. > > > > Checking things further (with a simple program that fits into L2 to > > read / write into SDRAM memory), I find that 1/4 of my writes are > > not being written correctly into SDRAM. If, for example I write a > > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > > 0x05, 0x05, 0x06, 0x07 and so on. > > > > If on the other hand I write the same memory pattern backward > > (starting from end going toward 0x8000000), then the pattern is > > written fine! > > > > Looking into the GEL file, I've noticed small differences in the > > EMIF timings between 1.05 and 2.21, but switching back and forth > > makes no difference! > > > > I'm about to pull my hair out as I've been struggling with this for > > at least 30 hours! Any ideas anyone?? > > > > A million thanks for any advice? > > > > Jean-Pierre > > > > (The same problem occurs with Code Composer 1.05 that came with it, > > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > > RAM, and the DSK jumpers appear set to their default) > > > > > > > > > > > >

Jean-Pierre- > From my CCS V 2.20 installation, the filename used for the DSK6211 is called > 'dsk6x11spp378.cfg'. Does this file give you the information you need? No... you have to look at the last screen of the CCS Setup wizard and find the current Gel file setting. There's a way to check that in CCS also, maybe a CCS super-guru like Bhooshan will jump in and help. -Jeff > -----Original Message----- > From: Jeff Brower [mailto:] > Sent: Friday, March 18, 2005 4:09 PM > To: Jean-Pierre Poulin > Cc: > Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > Jean-Pierre Poulin- > > > Testing out the dsk6xtst application, the test does indeed fail, mostly > > during HPI write. > > > > Compiling the source code and tracing through the application, the board > > does indeed appear to have SDRAM access problem, and I'm not sure what to > do > > at this point. (Maybe I'll look for spare SDRAM parts I have lying about > > and replace the things) > > > > Beware what you buy on eBay!! > > > > Thanks for taking the time. It set me off in a new direction and I can > now > > do more scientific testing! > > What .gel file are you using with CCS; i.e. if you go into the CCS Setup > program, > what's the Initial Gel file set for? > > -Jeff > > > -----Original Message----- > > From: [mailto:] On > > Behalf Of Jagadeesh Sankaran > > Sent: Friday, March 18, 2005 10:42 AM > > To: jeanpierrepoulin > > Cc: > > Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > > > Are you sure that there is no problem with the underlying memory SDRAM > > in external memory. You can run dsktxt.exe which comes with CCS. > > > > Regds > > JS > > > > > jeanpierrepoulin wrote: > > > > > > I've purchased an old DSK6211 on eBay, and I'm having great > > > difficulty running the samples. The samples compile and link, but I > > > one or more `Data Verification Failed at address 0x8000xxxx' (right > > > in the DSK SDRAM memory space) and the program refuses to run > > > correctly. > > > > > > Rebuilding the samples to turn off the L2 cache and fitting all > > > sections into the on-chip L2 memory, the samples (those I can make > > > fit into 64K ram) work just fine and I can program, run and debug as > > > usual if I only use on-chip memory. But as soon as the loader needs > > > to load into SDRAM memory, I get these error and nothing works as it > > > should. > > > > > > Checking things further (with a simple program that fits into L2 to > > > read / write into SDRAM memory), I find that 1/4 of my writes are > > > not being written correctly into SDRAM. If, for example I write a > > > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > > > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > > > 0x05, 0x05, 0x06, 0x07 and so on. > > > > > > If on the other hand I write the same memory pattern backward > > > (starting from end going toward 0x8000000), then the pattern is > > > written fine! > > > > > > Looking into the GEL file, I've noticed small differences in the > > > EMIF timings between 1.05 and 2.21, but switching back and forth > > > makes no difference! > > > > > > I'm about to pull my hair out as I've been struggling with this for > > > at least 30 hours! Any ideas anyone?? > > > > > > A million thanks for any advice? > > > > > > Jean-Pierre > > > > > > (The same problem occurs with Code Composer 1.05 that came with it, > > > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > > > RAM, and the DSK jumpers appear set to their default)

Hi Jeff & Bhooshan... Loading the gel file in an editor, the version displayed on the first line of code of 'DSK6211_6711.gel' is '11.29.2000mld' Hope this is the right version! Also, running the (rather impressive) WinDSK utility that Bhooshan sent a link to (neat utility, thanks!), all aspects of the confidence test fails except for the external SDRAM one (Error Code 66666666) and the 'Parallel Port Bandwidth Test' (Dialog pops up with 'Address: 8000000 Expected: 00000000 Read from DSK: 00000003') I'm trying to determine if it would help to replace the SDRAM or if the DSP EMIF itself is damaged... (I never plugged in any daughtercards, but previous owner might have fried something out) any thoughts on how I could find out? According to Bhooshan, this is a common problem with external memory with these boards?? I wonder if slowing down the EMIF delays and slowing down the ECLKOUT from 100Mhz (default) to 75Mhz (using on-dsk PLL) would change anything... Thanks again for taking the time to help me out! (I badly need this board to work and it not working is killing my schedule at a very inopportune time! Must be Murphy's Law again...) Jean-Pierre -----Original Message----- From: Bhooshan Iyer [mailto:] Jean-- I would recommend you to check with this following software for any SDRAM memory related problems(physical) first up...there is also complete health check up option in the software...We have seen few of those bad eggs at our labs...10 of them to be precise! :-( http://eceserv0.ece.wisc.edu/~morrow/software/winDSK6_3_0_3_0.zip --Bhooshan -----Original Message----- From: Jeff Brower [mailto:] Jean-Pierre- > From my CCS V 2.20 installation, the filename used for the DSK6211 is called 'dsk6x11spp378.cfg'. Does this file give you the information you need? No... you have to look at the last screen of the CCS Setup wizard and find the current Gel file setting. There's a way to check that in CCS also, maybe a CCS super-guru like Bhooshan will jump in and help. -Jeff ======================================== > Jean-Pierre Poulin- > > > Testing out the dsk6xtst application, the test does indeed fail, mostly > > during HPI write. > > > > Compiling the source code and tracing through the application, the board > > does indeed appear to have SDRAM access problem, and I'm not sure what to > do > > at this point. (Maybe I'll look for spare SDRAM parts I have lying about > > and replace the things) > > > > Beware what you buy on eBay!! > > > > Thanks for taking the time. It set me off in a new direction and I can > now > > do more scientific testing! > > What .gel file are you using with CCS; i.e. if you go into the CCS Setup > program, > what's the Initial Gel file set for? > > -Jeff > > > > > Are you sure that there is no problem with the underlying memory SDRAM > > in external memory. You can run dsktxt.exe which comes with CCS. > > > > Regds > > JS > > > > > jeanpierrepoulin wrote: > > > > > > I've purchased an old DSK6211 on eBay, and I'm having great > > > difficulty running the samples. The samples compile and link, but I > > > one or more `Data Verification Failed at address 0x8000xxxx' (right > > > in the DSK SDRAM memory space) and the program refuses to run > > > correctly. > > > > > > Rebuilding the samples to turn off the L2 cache and fitting all > > > sections into the on-chip L2 memory, the samples (those I can make > > > fit into 64K ram) work just fine and I can program, run and debug as > > > usual if I only use on-chip memory. But as soon as the loader needs > > > to load into SDRAM memory, I get these error and nothing works as it > > > should. > > > > > > Checking things further (with a simple program that fits into L2 to > > > read / write into SDRAM memory), I find that 1/4 of my writes are > > > not being written correctly into SDRAM. If, for example I write a > > > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > > > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > > > 0x05, 0x05, 0x06, 0x07 and so on. > > > > > > If on the other hand I write the same memory pattern backward > > > (starting from end going toward 0x8000000), then the pattern is > > > written fine! > > > > > > Looking into the GEL file, I've noticed small differences in the > > > EMIF timings between 1.05 and 2.21, but switching back and forth > > > makes no difference! > > > > > > I'm about to pull my hair out as I've been struggling with this for > > > at least 30 hours! Any ideas anyone?? > > > > > > A million thanks for any advice? > > > > > > Jean-Pierre > > > > > > (The same problem occurs with Code Composer 1.05 that came with it, > > > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > > > RAM, and the DSK jumpers appear set to their default)

Jean-Pierre: What Jeff is referring to is a GEL file. It will have a .gel extension on it. The GEL file is typically used for initialization of the EMIF (External Memory Interface), and C6x reset. The EMIF contains registers which define the memory timings and other characteristics (row size, column size, etc.). Chances are if you haven't heard too much about the .GEL file, you're probably using the default one, which I believe is something either like DSP621x_671x.gel or DSK6211.gel or dsk6xinit.gel. Inside the .gel file you're using, for a DSK unit you should have a function called something like emif_init() or init_emif(): emif_init() { /*-- -*/ /* EMIF REGISTERS */ /*-- -*/ #define EMIF_GCTL 0x01800000 #define EMIF_CE1 0x01800004 #define EMIF_CE0 0x01800008 #define EMIF_CE2 0x01800010 #define EMIF_CE3 0x01800014 #define EMIF_SDRAMCTL 0x01800018 #define EMIF_SDRAMTIMING 0x0180001C #define EMIF_SDRAMEXT 0x01800020 /*-- -*/ /* EMIF REGISTER VALUES - these should be verified with TARGET hardware */ /*-- -*/ *(int *)EMIF_GCTL = 0x00003040;/* EMIF global control register */ *(int *)EMIF_CE1 = 0xFFFFFF23; /* CE1 - 32-bit asynch access after boot*/ *(int *)EMIF_CE0 = 0xFFFFFF30; /* CE0 - SDRAM */ *(int *)EMIF_CE2 = 0xFFFFFF23; /* CE2 - 32-bit asynch on daughterboard */ *(int *)EMIF_CE3 = 0xFFFFFF23; /* CE3 - 32-bit asynch on daughterboard */ *(int *)EMIF_SDRAMCTL = 0x07117000; /* SDRAM control register (100 MHz)*/ *(int *)EMIF_SDRAMTIMING = 0x0000061A; /* SDRAM Timing register */ } The EMIF SDRAM registers are the ones that are most critical - the EMIF_SDRAMCTL register, as the name implies, has alot to do with the control settings for the SDRAM (items like row & column size), and the EMIF_SDRAMTIMING register contains the value for the SDRAM refresh period. The above <should> be the right values for either a 6211 or 6711 DSK. Invalid values can lead to problems. But, like I said, chances are if you've never heard of the GEL file, you <probably> have those values already. But, I could be wrong. Thanks Jeff for pointing that out! g. ----- Original Message ----- From: "Jeff Brower" <> To: "Jean-Pierre Poulin" <> Cc: <> Sent: Friday, March 18, 2005 5:35 PM Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > Jean-Pierre- > > > From my CCS V 2.20 installation, the filename used for the DSK6211 is called > > 'dsk6x11spp378.cfg'. Does this file give you the information you need? > > No... you have to look at the last screen of the CCS Setup wizard and find the > current Gel file setting. There's a way to check that in CCS also, maybe a CCS > super-guru like Bhooshan will jump in and help. > > -Jeff > > > -----Original Message----- > > From: Jeff Brower [mailto:] > > Sent: Friday, March 18, 2005 4:09 PM > > To: Jean-Pierre Poulin > > Cc: > > Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > > > Jean-Pierre Poulin- > > > > > Testing out the dsk6xtst application, the test does indeed fail, mostly > > > during HPI write. > > > > > > Compiling the source code and tracing through the application, the board > > > does indeed appear to have SDRAM access problem, and I'm not sure what to > > do > > > at this point. (Maybe I'll look for spare SDRAM parts I have lying about > > > and replace the things) > > > > > > Beware what you buy on eBay!! > > > > > > Thanks for taking the time. It set me off in a new direction and I can > > now > > > do more scientific testing! > > > > What .gel file are you using with CCS; i.e. if you go into the CCS Setup > > program, > > what's the Initial Gel file set for? > > > > -Jeff > > > > > -----Original Message----- > > > From: [mailto:] On > > > Behalf Of Jagadeesh Sankaran > > > Sent: Friday, March 18, 2005 10:42 AM > > > To: jeanpierrepoulin > > > Cc: > > > Subject: Re: [c6x] Please help me with this bad DSK 6211 problem! > > > > > > Are you sure that there is no problem with the underlying memory SDRAM > > > in external memory. You can run dsktxt.exe which comes with CCS. > > > > > > Regds > > > JS > > > > > > > jeanpierrepoulin wrote: > > > > > > > > I've purchased an old DSK6211 on eBay, and I'm having great > > > > difficulty running the samples. The samples compile and link, but I > > > > one or more `Data Verification Failed at address 0x8000xxxx' (right > > > > in the DSK SDRAM memory space) and the program refuses to run > > > > correctly. > > > > > > > > Rebuilding the samples to turn off the L2 cache and fitting all > > > > sections into the on-chip L2 memory, the samples (those I can make > > > > fit into 64K ram) work just fine and I can program, run and debug as > > > > usual if I only use on-chip memory. But as soon as the loader needs > > > > to load into SDRAM memory, I get these error and nothing works as it > > > > should. > > > > > > > > Checking things further (with a simple program that fits into L2 to > > > > read / write into SDRAM memory), I find that 1/4 of my writes are > > > > not being written correctly into SDRAM. If, for example I write a > > > > pattern such as 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 etc > > > > into SDRAM memory past 0x8000000, I will see 0x01, 0x01, 0x02, 0x03, > > > > 0x05, 0x05, 0x06, 0x07 and so on. > > > > > > > > If on the other hand I write the same memory pattern backward > > > > (starting from end going toward 0x8000000), then the pattern is > > > > written fine! > > > > > > > > Looking into the GEL file, I've noticed small differences in the > > > > EMIF timings between 1.05 and 2.21, but switching back and forth > > > > makes no difference! > > > > > > > > I'm about to pull my hair out as I've been struggling with this for > > > > at least 30 hours! Any ideas anyone?? > > > > > > > > A million thanks for any advice? > > > > > > > > Jean-Pierre > > > > > > > > (The same problem occurs with Code Composer 1.05 that came with it, > > > > and with CCS2.21 as well. This is a revision 1 board with 4Mbyte of > > > > RAM, and the DSK jumpers appear set to their default) > >

Please help me with this bad DSK 6211 problem!

Sign in

Search forums

Free PDF Downloads

Blogs - Hall of Fame

Discussion Groups

Quick Links

About DSPRelated.com

The Related Sites