Problem: Restart after FLASH to RAM copy on XC161CJ

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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.

After copying, which is succesfull, I execute

; adjust vector segment
#pragma asm
VECSEG = 0x00
; flush pipeline
JMPS 0x00,0x00
#pragma endasm

to start the application from RAM.

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

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

Thies Moeller

Re: Problem: Restart after FLASH to RAM copy on XC161CJ

do you setup the bus for RAM before copy ?

Thies Moeller schrieb:
Quoted text here. Click to load it

Re: Problem: Restart after FLASH to RAM copy on XC161CJ
Quoted text here. Click to load it
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.

Quoted text here. Click to load it

Re: Problem: Restart after FLASH to RAM copy on XC161CJ

please contact:

Provide your serial number and send the project as ZIP attachment.
Please also provide information about the hardware in use.


Quoted text here. Click to load it

Re: Problem: Restart after FLASH to RAM copy on XC161CJ
Hi Thies!

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

Quoted text here. Click to load it

Site Timeline