• State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 21 subscribers
  • Views 2212 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
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

...?T and ...?A

Dave Sudolcan

The following comment is on a website for the pC/OS RTOS kernel (http://www.embedded-os.de/)


The port of the pC/OS Kernel on AT91SAM7Sxx is now finished.
As Toolchain the IAR Embedded Workbench was used. Sorry to Keil, with "...?T" and "...?A" it's not really possible to create a good port for ARM and Thumb mode.


If anyone knows what this means, will you please explain it?

Thanks.

Parents
  • 0 in reply to Frank Goetze

    I need help....
    The following code fragment is the start of Task1() without the two memory-manager calls (commented). If I step over/in " b 0x001010d8" the processor jumps to the DAbt_Handler at address 0x00000010.
    Whats wrong with this part ???

      B530    push    {r4-r5,lr}
  2400    mov     r4,#0x00
  F000    bl      AppTickInit(0x00101290) - Part #1
  F8DE    bl      AppTickInit(0x00101290) - Part #2
  E000    b       0x001010d8        -               *** -> DAbt_Handler(0x00000010)
  3401    add     r4,#0x01           |  <-
  1C20    add     r0,r4,#0         <-     |
  4911    ldr     r1,[pc,#0x0044]         |
  4288    cmp     r0,r1                   |
  D3FA    bcc     0x001010d6          ----
  ...

Reply
  • 0 in reply to Frank Goetze

    I need help....
    The following code fragment is the start of Task1() without the two memory-manager calls (commented). If I step over/in " b 0x001010d8" the processor jumps to the DAbt_Handler at address 0x00000010.
    Whats wrong with this part ???

      B530    push    {r4-r5,lr}
  2400    mov     r4,#0x00
  F000    bl      AppTickInit(0x00101290) - Part #1
  F8DE    bl      AppTickInit(0x00101290) - Part #2
  E000    b       0x001010d8        -               *** -> DAbt_Handler(0x00000010)
  3401    add     r4,#0x01           |  <-
  1C20    add     r0,r4,#0         <-     |
  4911    ldr     r1,[pc,#0x0044]         |
  4288    cmp     r0,r1                   |
  D3FA    bcc     0x001010d6          ----
  ...

Children
  • 0 in reply to Frank Goetze

    Frank,

    Your code snipped shows -

      ...
  F000    bl      AppTickInit(0x00101290) - Part #1
  F8DE    bl      AppTickInit(0x00101290) - Part #2
  ...

    The opcodes indicate that the code is runing in thumb mode. But the target of the 'BL' shows 0x00101290, this is Arm-mode (even address, thumb mode would be 0x00101291).
    In this case, you need an interwork-stub, that is code that changes from thumb- to arm-mode.

    Here is an example of how that looks like:

    //--- Thumb-mode:
 ...
 01000CCE  3001      ADD         R0,#0x1
 01000CD0  3102      ADD         R1,#0x2
 01000CD2  F7FF      BL          AppTickInit?T  ; T=0x1000C71  (1)
 01000CD4  FFCD      BL          AppTickInit?T  ; T=0x1000C71  (2)
 ...

//--- Thumb to Arm Interwork-Stub:
 01000C70          AppTickInit?T PROC THUMB
 01000C70  4778      BX          R15
 01000C72  46C0      NOP         ; MOV R8,R8
 01000C74          ENDP

//--- Arm Function:
 01000C74          AppTickInit?A:  ; FUNCTION START
  257: int ArmF (int n1, int n2) __arm {
 01000C74  E1A03001  MOV         R3,R1 ; n2
 01000C78  ---- Variable 'n2' assigned to Register 'R3' ----
 01000C78  E1A02000  MOV         R2,R0 ; n1
 01000C7C  ---- Variable 'n1' assigned to Register 'R2' ----
  258:   return (n1 * n2 + n1 * n2);
 01000C7C  E1A01003  MOV         R1,R3 ; n2
 01000C80  E1A00002  MOV         R0,R2 ; n1
 01000C84  E0000091  MUL         R0,R1,R0 ; n2
 01000C88  E0800000  ADD         R0,R0,R0
  259: }
 01000C8C  E12FFF1E  BX          R14
 01000C90            ; END 'AppTickInit?A'

    Peter

  • 0 in reply to Gp F

    thanks,

    but see the main.c - AppTickInit() is a C-function called from main(). I think, this is to handle by the compiler...
    Have the Keil-compiler optimizing problems with not direct called functions (see Task1..3) or problems with C-Thumb-code mixed with ASM-Thumb/ARM-code ?

    Frank

  • 0 in reply to Frank Götze

    ... Sorry !

    see the main.c - AppTickInit() is a C-function called from C-function Task1().
    But the problem is still the same...

  • 0 in reply to Frank Götze

    ... more tests using the simulator and the board...
    Following test was running on the board:

    * If I set a breakpoint at 

    bl      AppTickInit(0x00101290) - Part #1
    register r4 is not zero in the register-window???
    * if I set a breakpoint at 
    push    {r4-r5,lr}
    and step forward, the register r4 will initialised with zero.

    What's wrong ???

    If I add a secound variable that will located in register r5 and the init is in front of r4, like 
      B530    push    {r4-r5,lr}
  2500    mov     r5,#0x00
  2400    mov     r4,#0x00
    and I break on init of r4 or later, then r5 is not zero in the register-window ???

  • 0 in reply to Frank Götze

    The CARM compiler handles all the interworking automatically. As usual with software, there is always the chance to get into some 'notch'. You should provide a boiled down example since the code fragments simply don't give enough details. Your most recent post looks like a stack overrun/underrun problem.

    Peter

  • 0 in reply to Gp F

    You can download the hole code of the pC/OS RTOS kernel from http://www.embedded-os.de/index.html?pcos.htm