This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

URGENT: Problems when Running Code from IDATA for Programming Boot Loader (for C161U)

1. Programming Boot Loader in External FLASH for execution in External RAM: Running Code From Internal RAM

My company has developed a powerline adapter prototype.

This prototype is based on the C161U microcontroller and we are using
the uVision v4.27 product.

We would like to program a "Boot Loader" in order to start the execution in an external FLASH and then to copy our "Application"
from external FLASH to external RAM, where the program will be executed.

Please, can anybody provide me any technical information concerning to the execution problem form Internal RAM that we have detected and it is explained below with detail?.

The solution of this problem is VERY PRIORITY for us.

2. Execution Problems from IRAM

We use only one uVision project which include the "Boot Loader" files and
the "Application" files which external memory map is:

RAM: start: 0x0000 size: 0x10000
ROM: start 0x10000 size:0x10000


CS definition:

CS0: 0x0000 - 0x20000 (connected to an external FLASH of 128 Kbytes)
CS1: 0x40000 - 0x60000 (connected to an external RAM is 128Kwords, only A17-A1 lines are used for addressing this memory)

When the code copy from external FLASH to external RAM is finished we write
three instructions in internal RAM positions (0xF200-0xF20B) in order to modify
the definition of CS1 and then to jump to the function main of our Application .
For the execution of the Application we redefine CS1 for the address range 0x0000 - 0x20000 .

MOV ADDRSEL1, #0x005

For the writing and execution from IRAM we have used the information provided from your technical support page

http://www.keil.com/support/docs/209.htm,

but I think there is some important detail that additionally it is necessary to specify .


3. Simple Example for the Evaluation Board EASY UTAH including the C161U.

We have executed a simple example (please see uVision attached) using the Keil monitor (through the serial port) and
running the program in External RAM in order to check if the programming internal RAM and code execution from Internal RAM is correct.
We have executed this example in the evaluation board EASY UTAH and also in our prototype including C161U. In both cases the problem
is the same.

PROBLEM: We have observed that when we execute the instruction in Internal RAM, that is when we change the definition for the generation of CS1

MOV ADDRSEL1, #0x005

the program execution is stopped and it is broken the communication to the monitor. Additionally,
the CS1 goes high and CS0 does down.

The writting code of the IRAM is the following:

      MOV     R6,#0F200H              ; destination in on-chip RAM

      MOV R5,#0CE6H	          MOV ADDRSEL1,
     MOV     [R6],R5
     ADD     R6,#02H

      MOV R5,#0005H	          ;...0x5
      MOV     [R6],R5
     ADD     R6,#02H

      MOV     R5,#0CCH                ; Opcode: NOP
       MOV     [R6],R5
       ADD     R6,#02H


       ; JMPS to the @main
        MOV     R5,#01FAH                ;JMPS = FA
        MOV     [R6],R5
        ADD     R6,#02h

        MOV     R5,#00A2h
       MOV     [R6],R5


We have test the same example, running the program in the external FLASH and the execution problem
in the IRAM is the same, thus we think it is not a keil monitor problem.


Please, send us any information about this problem. Thank you very much for your help and attention.

Thank you very much

  • Hi Paloma,

    From your explaination of the problem I got the idea that you were debugging your application with Keil's Monitor166. For its operation Monitor166 must have its code area (in RAM or ROM), data area (in RAM), and interrupt vectors (NMI and maybe ASC0.) If any of that changes, the monitor dies miserably. As far as I can see, the MOV ADDRSEL1, #0x005 instruction can affect all of those. If that's the case, it's no surprise that Monitor166 stops working.

    - mike