We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
> Why 0x000000cd ?? and not 0x00000284
The comment "; @0x00000284" refers to the address being loaded, that is, "PC+4+32"; if you look at address 0x284 you'll probably see "DCD 0x000000cd". I think that in your image '__main' starts at 0xcd.
> i think and the reason must be the pre-init routines needed for RAM
I think you're right. You seem to be in the scatter-loading/data-initialization code. Possibly you've added some global variables that need initializing?
Thanks for the little info about the command. Downloaded the instruction set from the ARM website to see the exact function of the commands. Indeed the command LDR r0,[pc,#32] ; @0x00000284 loads the value of 0x000000cd and jumps to 0x000000cc everything is right so far.
But then it seems that there is a bug in the compiler somewhere. The assembly code seems alright and looks like the code form _main_stk /_main_scatterload / _scatterload_rt2 functions but the comment mixed in is from my main program.
The (dis)assembly code has nothing to do with the parts of the source code!
Still looking for the real bug/reason why the compiler itself generates init ram/rom code without warnings but fails to reach the main() afterwards.
Note that it need not be a compiler problem when the disassembly doesn't look correct. Maybe a problem with the debug information, making the debugger picking up wrong addresses for symbols etc.
I agree i don't know what exactly the problem is but it is strange when stetting up a project from scratch and adding some own files, compile it and try to debug it, it ends op with showing the source (c) code from somewhere else. I rebuilded my eval program again folowing the guides but during debug/stepping thru the comment from my main file is shown instead of the internal (ram) init files (of which no source is abailable beacuse it's in a library??) í will continue evaluating the board and software and let you know if something is found.
Make sure that you have the 'Browse Information' box checked in the Output Tab. It sounds like you are displaying files built from a previous build. Bradford
'Browse Information' box was checked and if i do a total rebuild it's all from the new build. (in the notes i read: Evaluation version of the RealView ARM tools do not support linker scatter file. I don't know if there is any relationship between this and the xx_scatterxx routines. )
Whatever the reason is I think it's stange, i will put a note in my eval report and have a look at this at a later time. Maybe when doing some more tests and getting more experience with the complete package and evaluation board it all becomes clear.