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

MDK ARM9 - it doesn't compile my main code at all.?!

I made a simple application for MCBSTR9 (ARM9 based demo board, but nvm really).
I have the startup and interrupt handler code included in the project (91x_it.c), it compiles and executes/sets up the processor properly, but when it comes to start up my code in the disassembly windows it's just rubish like:


0x000001D0  00000000  ANDEQ     R0,R0,R0
     8:   GPIO_DeInit(GPIO7);
0x000001D4  00000000  ANDEQ     R0,R0,R0
0x000001D8  00000000  ANDEQ     R0,R0,R0
     9:   GPIO_InitStruct.GPIO_Direction = GPIO_PinOutput;
0x000001DC  00000000  ANDEQ     R0,R0,R0
0x000001E0  00000000  ANDEQ     R0,R0,R0
    10:   GPIO_InitStruct.GPIO_Pin = GPIO_Pin_All;
0x000001E4  00000000  ANDEQ     R0,R0,R0
0x000001E8  00000000  ANDEQ     R0,R0,R0
    11:   GPIO_InitStruct.GPIO_Type = GPIO_Type_PushPull ;

- it doesn't seem to compile my code at all. There are no reported errors during the project build....What am I missing??

Parents
  • This is an interesting thought. I'm not sure how could I check if it loads the code or not. I think that the target options are fine.

    It does load the initialisation routine, and it does work, the mess comes up when it's enering the C code.

       680: ; Enter the C code
       681:
       682:                 IMPORT  __main
    

    The adress of the jump after the initialisation is correct (checked the objects on the map file), but the code just isn't there!

    0x000001A0  E5801020  STR       R1,[R0,#0x0020]
                     __main:
    0x000001A4  E5801020  STR       R1,[R0,#0x0020]
                     _main_scatterload:
    0x000001A8  E5801020  STR       R1,[R0,#0x0020]
                     __main_after_scatterload:
    0x000001AC  E5801020  STR       R1,[R0,#0x0020]
    0x000001B0  E5801020  STR       R1,[R0,#0x0020]
    

Reply
  • This is an interesting thought. I'm not sure how could I check if it loads the code or not. I think that the target options are fine.

    It does load the initialisation routine, and it does work, the mess comes up when it's enering the C code.

       680: ; Enter the C code
       681:
       682:                 IMPORT  __main
    

    The adress of the jump after the initialisation is correct (checked the objects on the map file), but the code just isn't there!

    0x000001A0  E5801020  STR       R1,[R0,#0x0020]
                     __main:
    0x000001A4  E5801020  STR       R1,[R0,#0x0020]
                     _main_scatterload:
    0x000001A8  E5801020  STR       R1,[R0,#0x0020]
                     __main_after_scatterload:
    0x000001AC  E5801020  STR       R1,[R0,#0x0020]
    0x000001B0  E5801020  STR       R1,[R0,#0x0020]
    

Children
  • Still no luck with this. My highest hope afte days of diging was to uncheck the Use Memory Layout from Target Dialog checkbox - for the Eval version of the build tool does not support this, but nothing really happend
    Contacted support, I hope to get some help from them.

  • But this can't just be a project memory layout issue. Because both linker and debugger should see the same memory layout settings. So the linker should position the code at the same place that the debugger expects to find it.

    Your disassembly indicates that the debugger do not find the code where expected. So maybe there aren't any memory there. Or the memory hasn't been initialized correctly. Or something overwrites the memory. Or the memory is write-protected. Or you have the wrong algorithm for programming the memory.

    Your main step really must be to figure out where the map file indicates your code is.
    And if the map file indicates "good" addresses.
    And if the contents at these addresses corresponds with what should have been sent to the chip.

  • Dear Per,

    Thanks for Your reply.
    I've checked most of these things.
    First, I exclude the possibility that this is a debugger issue. The simple code that I wrote only initialises the GPIO7 port to be output, gives it a proper function then lits every 2nd LED connected to it (yes, they work :) ). None of this happens, that's why I'm sure it's not being executed at all, but then again the startup routine is being executed quite correctly.
    I've also checked the map file, it does point to the entry point if my code (which isn't there) from the startup routine.
    I'm also looking at the example projects given by the vendor for about a month now, they work absolutely correct, but I just can't tell the difference between the example projects and my own setup. If I delete the source from the example projects and insert my own, it also works properly.
    But I can't just leave it on that.
    I'd say that I'm missing one tiny, silly but major issue here that leads to the loss of my code between compiling and loading and I just can't tell what.
    I tripple (and more) checked the memory map setup, it should be fine, as declared by the chip vendor, and as I can tell it's the same setup as on the example projects - which actually drives me crazy, there isn't any difference except that my setup doesn't work.

    Regards,
    Istvan

  • Issue solved. THe problem was my include paths for the 91x_lib.
    Funnily the compiler didn't object to this, just left out a part ove the user code, regardless that I have set the Warnings option to All.