Keil Logo


Information in this article applies to:

  • C51 Version 7.01
  • Triscend Fast Device Link Utility 2.5.0


When 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?


The 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.


In order to avoid debugging problems, it is recommended to always follow step #1 and then step #2 for all target memories.



Last Reviewed: Wednesday, June 30, 2004

Did this article provide the answer you needed?
Not Sure
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.