I use a XC161CJ board with external RAM on 0x0000. In the internal FLASH at 0xC00000 I have the srec-file of my application linked to run from external RAM and a routine to copy this srec-file to RAM on reset.
If I do this under Taskings Crossview with OCDS It works perfect.
Reset -> Startup from FLASH -> copyroutine -> adjust VECSEG -> Jump to Resetvector (singlestepping) -> application runs.
If I start the board without the debugger connected, I can see via "LED-Debugging" that the copyroutine finished its work. But then nothings else happens, it seems that the application is not starting.
I have no idea what the difference is between debugged-run an normal run or how i can find out what is going wrong after the "RAM-Restart"?
Yes. The startup code in flashrom does setup for the RAM. (Only busmode and timing, because I use CS0) In fact I use exactly the same settings for the "copy-application" and the application that is copied into ram. The only difference is the location of the VECTAB and the ROM-area.
We use the XC164CS as replacement for the C166. After 1.5 years of development it still happens that we spend days struggling with new silicone bugs.
One of them we recently detected is that the TCONCS1 register (bus timing) looses its content under very mysterios circumstances.
For a very long time i was not able to get my project running from internal flash, while it worked in RAM. So i did it the way you try: Link the project for ext. RAM, add an offset to put it in internal flash, then program it to internal flash together with a small copy routine. This routine copies it to RAM after startup and jumps to address 0 (all this before executing einit). Worked fine.
Finally i got my programs working from internal flash. I do not know exactly what was the problem. I took a sample from Keil Software which was designed for some phytec 167 board. This sample worked, so merged the configuration to mine until it was stable.
Now i have a kind of self made "BIOS" in internal flash which is able to load software modules from external flash or mass storage (MMC/SD) to RAM and launch it.
As i mentioned there was some trouble with bus configuration. When the cpu was reset during heavy RAM access, it fell into some state which let it forget the TCONCS1 value immediately after EINIT. This caused the cpu to acess the external Flash much too fast, so the boot process failed. This state was preserved even after removing power supply! After booting the device with bootstrap loader, OCDS debugger or from external mass storage, the behavior was normal again. The content of the external and internal flash definitely was not changed when the system was in the errneous state.
We fixed the problem by reconfiguring TCONCS1 after EINIT (security mode must be inhibited first).
After telling You my own story i can try to give some hints: Check the settings of your OCDS debugger. I use the Keil tools, so i dont know how this is with Tasking, but probably the debugger does some bus configuration in order to load your program into RAM. Check if your Startup code also contains that configuration. (EBCMODx, FCONCSx, TCONCSx and ADDRSELx registers may be necessary to configure, depending on Your Hardware)
I do not exactly about the 161, but it should be quite similar because i think all of the XCs are derivated from the XC167 V2 core.
If everything is setup correct, check the newest errata sheet (this will take some time, due to its length). Be sure you have the newest, i recently downloaded an errata sheet from july 2002 from infineon, while already on august 2003 was a new errata sheet released.
If you do not find any error which points to your problem, this does not neccessarily mean there is no such error.
Try and play with the configuration.
I find it almost impossible to determine the correct configuration values by reading the datasheet. It is errneous, especially the reset values. I tried it that way and failed, finally managed it by trial and error.
By the way: Do you verify the copying? Are you sure the code you try to launch is where you expect? If so, add some different blinking to the begin of the program you launch.
best regards manuel
Thies Moeller wrote in news:bngvlm$l15$ snipped-for-privacy@nathan.rz.tu-harburg.de:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.