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

Debug /trace imposible from Reset Handler (only 3 steps)

Im made a test program without function to test speed of the Cortex, downloader, debugger and compiler. MCB1700 board
Program worked well. To continue with testing i added some files to increase the size of the project (Hash functions). The files are included but the function is never real called. The call has been place at a location where the main program never comes.
So the function of the program should be the same as before.
No compile errors, no download errors, program is ready to run
Source

; Reset Handler

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  __main
                LDR     R0, =__main
                BX      R0
                ENDP


Disassembly

   124:                 LDR     R0, =__main
0x00000260 4808      LDR      r0,[pc,#32]  ; @0x00000284
   125:                 BX      R0
   126:                 ENDP
   127:
   126:                 ENDP
   127:
   128:
   129: ; Dummy Exception Handlers (infinite loops which can be modified)
   130:
   131: NMI_Handler     PROC
   132:                 EXPORT  NMI_Handler               [WEAK]
0x00000262 4700      BX       r0
   133:                 B       .
   134:                 ENDP


R15 (PC) = 0x00000260
Doing one assembler step and: R15 (pc) = 0x00000262, R0 = 0x000000cd
Why 0x000000cd ?? and not 0x00000284

Doing one more step and i am in the middel of one of my realtime routines? at an even adres.

  2293:    // Test mode
  2294:
0x000000CC F000F802  BL.W     __scatterload_rt2_thumb_only (0x000000D4)
  2122:                                      os_evt_set (mouse->InputsEvent, mouse->InputsTaskId);            //
0x000000D0 F000F8B6  BL.W     __rt_entry_sh (0x00000240)
0x000000D4 A00A      ADR      r0,{pc}+4  ; @0x00000100
  2297:    if (Config.mode == 1)             //
  2298:    {

Something is going wrong at compilation time i think and the reason must be the pre-init routines needed for RAM (done by the compiler), however this should never happen or is this another feature of the Cortex M3 i overlooked

0