| ||||||||
Technical Support Support Resources Product Information | GENERAL: UV2 DEBUGGER AND TRISCEND E5 - OUTPUT FILE DOWNLOADInformation in this article applies to:
QUESTIONWhen using µVision debugger with Triscend E5 DLL ( TE5_UV2.DLL ) for target debugging, what memory is used to download your code when you hit the start debugging session? Apparently there's no option to define what kind of memory I'm working with ( SRAM, internal, Flash, etc). How can I choose it? ANSWERThe memory that your program is going to download is defined by a series of procedures that involve Keil µVision debugger and Triscend FastChip Device Link ( FDL ). The standard E5 debugging model that Triscend currently recommends to users is as follows. #1 - Use FDL (or CSoC in command-line mode) to configure memory and then download the cfg file to the target. #2 - Use µVision to start debugging ( triggering a code download ). If the target memory is Flash, you must follow steps #1 and #2 every time you change your program and want to debug it. This is necessary, because µVision does not know how to program Flash memory. If the target memory is SRAM, you must, at least for the first time, follow step #1. This is necessary because FastChip infers the correct E5 code and data mapper system register settings, which are not understood by µVision per se. Without step #1, your program may not even be able to fetch the first instruction properly after reset, as the code mapper may not be properly set up. However, during subsequent iterative code development, you may download directly from µVision via te5_uv2.dll to SRAM. This should work in many cases. However, a bad program may disturb the code and data mapper settings inadvertently. When in doubt, do steps #1 and #2. When the target memory is Flash, and downloading (by selecting menu item Debug | Start/Stop Debug Session) causes "download verification" error(s), it is most likely that you are trying to download (a version of) a program that is not the same as the one already programmed in Flash. Again, the best way is to go through steps #1 and #2. RESOLUTIONIn order to avoid debugging problems, it is recommended to always follow step #1 and then step #2 for all target memories. MORE INFORMATIONSEE ALSOLast Reviewed: Wednesday, June 30, 2004 | |||||||
| ||||||||