• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 1034 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to debug the exams of ARM side in quickStartOMAPL1x_rCSL ?

jian gong61581
Prodigy 200 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138, TMS320C6748

Dear!
   When I run the example of "C:\Program Files\Texas Instruments\quickStartOMAPL1x_rCSL\OMAPL1x\rCSL_examples\evmOMAPL138\ARM_examples\timer\TIMER_interrupt_armL138".
In the function "static void init_OMAPL138 (void)",I step into/over the statement "_call_swi(ARM_PRIV_MODE_KEY);".The PC is always jump to 0x00000008. I found in the command file  OMAPL138_ARM.cmd,the linker put the section .intvecs to ARM's RAM 0xFFFF0000.
   I'm confused that why the PC don't jump to 0xFFFF0000 when step into "_call_swi(ARM_PRIV_MODE_KEY);".
   In OMAPL138_ARM.cmd,I also don't understand the statements "--retain=INT_VECS and --diag_remark=10063"

 In this project, I didn't use the ARM side .gel files .Because My OMAPL138 don't have ARM side .gel file.
   Thanks for everyone's time and help!

 

  • 0
    TI__Mastermind 30805 points

    Hi Jian,

    At the occurrence of a software exception for the ARM926EJS, the PC will either jump to 0x00000008 or 0xFFFF0008 depending on the state of the "V" bit (bit 13) in the ARM system control coprocessor C1 register. The "V" bit is configured on reset depending on the state of the "VINITHI" signal. If the signal is high, the PC will jump to the 0xFFFF0008; and if the signal is low, the PC will jump to 0x00000008.

    The ARM on OMAPL138 is configured with the "VINITHI" signal high; thus, the PC should jump to 0xFFFF0008 by default unless the software modifies the "V" bit. You can find this information in section 2.4 in the OMAPL138 reference guide (http://www.ti.com/lit/pdf/sprugm7).

    The "--retain=INT_VECS" is necessary because the project is built in the ELF format and does not directly reference the assembly code in "ARM9_intvecs.asm". Under the ELF format, the linker aggressively finds and removes sections that are not directly referenced. The "--diag_remark=10063" can be removed if you wish, but was added to remove a warning from the compiler that the project had an entry point other than "_c_int00". The new entry point is "_init_stack" which is also defined in the linker command file.

    I was unable to replicate your issue by importing the project and building using CCS. Did you also import the example or are you trying to build using the source files with possibly some modifications? I attached a screen shot of what occurrs when I step into "_call_swi(ARM_PRIV_MODE_KEY);".

    Hope this helps!

    Regards,
    Kevin

  • 0 in reply to Kevin S
    Prodigy 200 points

    Hi Scholz!

         Thanks for  your quickly reply to my question. I didn't make any change to the exam in "\rCSL_examples\evmOMAPL138". What I only do is import the project to my workplace.

       My project is under the conditions of:

      1) use xds100v2   2)CCSv4.1.2    3)I have not ARM side .gel file 4)I use two different OMAPL138 boards: hawkboard and SEED-OSK138,the question is all the same.

        I set two breakpoints below INT_VECS:

    After I builded the exam . I hit , then the program directly run to main().

    I want to know why the program don't  halt at the first breakpoint  _c_int00 when connect to target L138. Then I step into init_OMAPL138(),

    and then continue step into the program.

     then I hit "Run"   and push the Reset button on my board,

    ARM9_0: Trouble Reading Memory Block at 0xfffefffc on Page 0 of Length 0x41: 0x00000004/-2030 @ marker 1746953576 Error during: Register,  Access to an unknown or invalid register was attempted. 
    ARM9_0: Trouble Reading Memory Block at 0xfffefffc on Page 0 of Length 0x39: 0x00000004/-2030 @ marker 1746953576 Error during: Register,  Access to an unknown or invalid register was attempted.

    why at address start from 0xffff0000 is ????????

    when I connect my target ,I can watch the content from 0xFFFF0000

     

    My company order the TMDSEVML138/OMAP-L138/TMS320C6748 from anvet recently,It about wait for 6-8 weeks.

     

  • 0 in reply to jian gong61581
    Prodigy 200 points

    Hi Scholz!

           Maybe the problem is that upon powering up the board ,the OMAPL138 run the u-boot,maybe the  "V" bit (bit 13) in the ARM system control coprocessor C1 register was modefied by u-boot.

  • 0 in reply to jian gong61581
    TI__Mastermind 30805 points

    Hi Jian,

    My answers to your questions:

    "I want to know why the program don't  halt at the first breakpoint  _c_int00 when connect to target L138. Then I step into init_OMAPL138(),"

    When you loaded your program, the program did not halt at "_c_int00" because your breakpoint is at the reset exception (0xFFFF0000) rather than the beginning of the "_c_int00" function. You can search for "_c_int00" in your disassembly window to see where in memory the function is located. I attached a snapshot of an example where "_c_int00" is located at 0x800047b4. Thus, any calls to "_c_int00" will jump to this location rather than 0xFFFF0000. I believe there is a feature in CCS that allows you to run to a particular point in your code other than "main" when you connect; you may look at the CCS wiki for more information: http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v4.

    "why at address start from 0xffff0000 is ????????"

    I am not sure why your window shows "????????"; that could possibly be something related to your version of CCS. On my window, I see 0x00000000 when I push the reset button on my board. This is because the hardware reset on the board clears out the ARM RAM. Would you mind using a software reset in CCS instead? I attached a screenshot on how to do that in CCSv5; it should be similar in CCSv4.

     

     

    "Maybe the problem is that upon powering up the board ,the OMAPL138 run the u-boot,maybe the  "V" bit (bit 13) in the ARM system control coprocessor C1 register was modefied by u-boot. "

    I am not very familiar with u-boot; thus, my comments are limited here. Are you building with the TMS470 compiler? If so, could you perform the following steps to verify the state of your "V" bit before "_call_swi(ARM_PRIV_MODE_KEY);"? 

    1.) In your CCS folder, navigate to: tools/compiler/tms470/lib
    2.) Extract the rtssrc zip file and open up the folder.
    3.) Copy and paste boot.asm into your project in CCS
    4.) Open up boot.asm in CCS and change the highlighted code below to: ORR r0, r0, #0x1F;

    Note: Ensure you are modifying the 32 bit state boot routine, approximately line 202 in my file

    5.) Open up main.c and add the following to "init_OMAPL138" just before "_call_swi(ARM_PRIV_MODE_KEY);" 

    asm("     MRC p15, #0, R0, c1, c0, #0\n");

    6.) Build and load the project and set a breakpoint at "_call_swi(ARM_PRIV_MODE_KEY);"
    7.) Run the project and then view the core register R0, the 13th bit will display the state of the "V" bit

    Thanks,
    Kevin

  • 0 in reply to Kevin S
    Prodigy 200 points

    Thank you very much. My problem is resolved.

    I found the code in ARMUBL  that modified the "V"bit .

     // Set the IVT to low memory, leave MMU & caches disabled
      asm(" MRC  p15,#0,r0,c1,c0,#0");
      asm(" BIC  r0,r0,#0x00002300");
      asm(" BIC  r0,r0,#0x00000087");
      asm(" ORR  r0,r0,#0x00000002");
      asm(" ORR  r0,r0,#0x00001000"); 
      asm(" MCR  p15,#0,r0,c1,c0,#0");
      asm(" NOP");

     

    Because after my board released from the reset status,the board boot from nandflash and run to u-boot. So I setted the pushboutton on the board and disabled the board bootting from nandflash upon powering up.

     

  • 0 in reply to jian gong61581
    TI__Mastermind 30805 points

    Hi Jian,

    Thanks for sharing your solution; I am glad to hear everything is working now!

    Regards,
    Kevin