I am developing a program that is loaded from flash and run from RAM. I am also using the EEPROM example files in my program. The example program to copy sections from on-chip flash to ram uses memcpy(), while the EEPROM example uses MemCopy() to run the FLASH API from RAM. I noticed the EEPROM example is 3 years old, so is MemCopy not recommended to use anymore?
Also I am trying to figure out if I have enough space to run the program from RAM. With the older version that used DSP28xxx_Section_Copy_nonBios.asm, I could see the Ram space being used in the memory map file. However with the newer example the RAM used remains 0 in the memory map. I know I am a bit borderline with space if I choose to run all the sections from RAM, can you please tell me what I need to do to see it in the map file again, and what the current recommended method is for copying sections to RAM?
Daniel, I'm a bit confused by your assistance. You keep bringing up the control suite, and an example that points to a controller that I'm not using.The examples I have been using all have passwords.asm, and a section that is allocated specifically for the CSM in the memory linker file.
I am not sure why I am losing chips once in a while, but at this point I am thinking maybe it was related to either the watchdog software problem or that I was using a debugger through a USB hub? I had nothing else to try to do besides trying to rebuild the software from scratch so I found an updated example to which to build from.
It's unfortunate that a locked chip can not be reset. Maybe I can return the locked control cards (8 pcs) ? By the way, I never changed the passwords to the CSM, I have no intention of locking it.
First off, yes, Memcopy is not recommended for use. memcpy is faster and is a standard function across many different platforms...not just C2000.
Second, The map file will show you RAM usage if you link the program correctly. If you fix that double allocation problem I told you about earlier in your command file you should start to see the RAM usage go up. Unless you have some special requirements, there is no reason to run the entire application from RAM. If you have some speed critical code portions, those may be placed into RAM to improve performance but there is no reason to put things like initialization code in RAM.
What controller are you using? There are examples in controlSUITE for all of our current devices, but if you are using an older device you may have to look elsewhere. From the sounds of it you are probably using a device that isn't supported in controlSUITE. The controlSUITE software has improved a lot over the past few years and much of it can easily be back ported to the older devices.
I cannot comment on controlCard returns, but I don't think it is something we typically do. I completely believe you were not trying to lock your flash, but the flash will not just lock itself...the password locations must be programmed for the flash to lock. You probably did so unknowingly somehow. My advice would be that if it happens again, save the .out file that caused the flash to be locked. You can use the hex2000 utility in the compiler directory to generate an s record or hex file and you can find the passwords that were programmed. Then you can use those passwords to unlock and erase the device. Once again, the assembly language tools guide has some useful information for how to use the hex2000 utility.
Hope that helps,
I would like to update this post after a few more weeks of testing. I had verified that I was not locking the chip by looking at the hex files and confirming that only 0xFFFF keys were being written to the CSM password location. I now realize that the chips were not being locked, but actually were failing from some kind of improper ground loop. Unfortunately I was chasing the wrong problem because the error I was getting from CCS or blackhawk flashburn was that the controller seemed to be locked.
I found this out by realizing I was only losing chips on a specific test bench and no where else. I am thinking of buying an isolator to prevent this from happening again.
Thanks for your help,
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.