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

E-mail address of KEIL support ?

Where is possible really get support from KEIL ?

  • Click on the 'Support' link above,
    then choose the 'E-Mail Support' link under 'Getting Support'

    Simple, eh?

  • Which email you can advise me ?

    support@keil.com
    support.us@keil.com
    support.intl@keil.com

    or "web-based technical support form " ?

    I tried all last month.

    Also, I send email copies directly to Reinhard Keil and Rudolf Baumgartner via old email's which I receive in previous cases last year.

    I send 4 email's last month and have no answer's.

    Sorry, 1 answer I have from email robot
    on support@keil.com that my "inquiry"
    resended to support.intl@keil.com :)

    What happened ?
    All KEIL support peoples now have holidays or bussines trip :) ?

    If you from KEIL, you can answer to my
    email in "E-mail" field of this message,
    now hidden from spamers
    (Thanks to Jon Ward ).



  • Why not ask your questions here to start with?

    - Mark

  • Sergey,
    Last time I sent a message to Keil support in September 2000. I got the answer in January 2001, when, naturally, nobody needed it any longer. Be patient. Or rather send your troubles to this forum.
    Bud' prosche - i ludi k tebe potyanutsya.
    Michael.

  • Am I the only guy who gets support from Keil? Every time I ask a question from support, I usually get an answer within 1-2 days.

  • Maybe you are!

    I'm afraid that I have also found that answers to questions to the "official" Keil E-mail support addresses can take a very long time, or sometimes appear to get lost all together.

  • >Why not ask your questions here to start with?

    Don't understand how you can help me ...

    Ok.
    You can try reproduce this bug in C251 v2.14n, XSMALL memory model.

    // ---- Beginning of ERR_PTR.C  ----
    typedef unsigned char UCHAR;
    typedef void * PTVOID;
    
    typedef struct { // Some structure with size <= 4 bytes
      UCHAR uc0;   
      UCHAR uc1; 
      UCHAR uc2; 
      UCHAR uc3; 
    } STR_A, *PTSTR_A;
    
    typedef struct { // Some structure with size > 4 bytes
      UCHAR uc0;     
      UCHAR uc1; 
      UCHAR uc2; 
      UCHAR uc3; 
      UCHAR uc4[10]; 
    } STR_B, *PTSTR_B;
    
    // 'volatile' just to prevent optimizing
    
    volatile PTSTR_A pa1,pa2;
    volatile PTSTR_B pb1,pb2;
    
    PTSTR_A f_a( PTVOID p)
    {
      return( (PTSTR_A) p );
    }
    
    PTSTR_B f_b( PTVOID p)
    {
      return( (PTSTR_B) p );
    }
    
    void main(void)
    {
     *pa1 = *pa2;  //OK_1, (copy via ?C?BMOVEPP8)
     *pb1 = *pb2;  //OK_2, (copy via ?C?BMOVEPP8)
     *pa1 = *f_a( (PTVOID) pa2 ); // BUG_1
     *pb1 = *f_b( (PTVOID) pb2 ); // BUG_2
    }
    
    // ---- End of ERR_PTR.C  ----
    


    Look at the code, generated for main():
    ;       FUNCTION f_a?_ (BEGIN)
                                                 ; SOURCE LINE # 22
    ;---- Variable 'p' assigned to Register 'DR0' ----
                                                 ; SOURCE LINE # 24
    000000 7F10           MOV      DR4,DR0
                                                 ; SOURCE LINE # 25
    000002 22             RET      
    ;       FUNCTION f_a?_ (END)
    
    ;       FUNCTION f_b?_ (BEGIN)
                                                 ; SOURCE LINE # 27
    ;---- Variable 'p' assigned to Register 'DR0' ----
                                                 ; SOURCE LINE # 29
    000000 7F10           MOV      DR4,DR0
                                                 ; SOURCE LINE # 30
    000002 22             RET      
    ;       FUNCTION f_b?_ (END)
    
    ;       FUNCTION main (BEGIN)
                                                 ; SOURCE LINE # 32
    ; *pa1 = *pa2;  //OK_1, (copy via ?C?BMOVEPP8)
         ; SOURCE LINE # 34
    000000 7E1F0000    R  MOV      DR4,pa2
    000004 7E0F0000    R  MOV      DR0,pa1
    000008 7404           MOV      A,#04H        ; A=R11
    00000A 120000      E  LCALL    ?C?BMOVEPP8
    
    ; *pb1 = *pb2;  //OK_2, (copy via ?C?BMOVEPP8)
         ; SOURCE LINE # 35
    00000D 7E1F0000    R  MOV      DR4,pb2
    000011 7E0F0000    R  MOV      DR0,pb1
    000015 740E           MOV      A,#0EH        ; A=R11
    000017 120000      E  LCALL    ?C?BMOVEPP8
    
    ; *pa1 = *f_a( (PTVOID) pa2 ); // BUG_1
         ; SOURCE LINE # 36
    00001A 7E0F0000    R  MOV      DR0,pa2
    00001E 120000      R  LCALL    f_a?_
    000021 7E0F0000    R  MOV      DR0,pa1
    000025 79300002       MOV      @DR0+2,WR6
    000029 1B0A20         MOV      @DR0,WR4
    
    ; *pb1 = *f_b( (PTVOID) pb2 ); // BUG_2
         ; SOURCE LINE # 37
    00002C 7E3F0000    R  MOV      DR12,pb1
    000030 7E0F0000    R  MOV      DR0,pb2
    000034 120000      R  LCALL    f_b?_
                                                 ; SOURCE LINE # 38
    000037 22             RET      
    ;       FUNCTION main (END)
    
    
    C251 COMPILER  V2.14n,  ERR_PTR   
    

    You can see, that lines, marked OK_1 and OK_2 generate good code for copying objects pointed with pointers making call to
    "copy structure" function C?BMOVEPP8.

    Now look at the code, generated for line BUG_1
    ; *pa1 = *f_a( (PTVOID) pa2 ); // BUG_1
         ; SOURCE LINE # 36
    00001A 7E0F0000    R  MOV      DR0,pa2
    00001E 120000      R  LCALL    f_a?_
    000021 7E0F0000    R  MOV      DR0,pa1
    000025 79300002       MOV      @DR0+2,WR6
    000029 1B0A20         MOV      @DR0,WR4
    

    Function f_a() produce result in DR4, so DR4 is a pointer to STR_A .
    But instead of fetching data from address in DR4 compiler just save DR4 (WR6 and WR4) to address in DR0 ( value of pa1 ).
    In other words, instead of
    *pa1 = *f_a( (PTVOID) pa2 );
    
    it produce code for imaginated :) line
    *pa1 = (STR_A)f_a( (PTVOID) pa2 );
    
    But I don't understand how possible make typecasting: STR_A * to STR_A.



    Look at the code generated for line marked BUG_2:
    ; *pb1 = *f_b( (PTVOID) pb2 ); // BUG_2
         ; SOURCE LINE # 37
    00002C 7E3F0000    R  MOV      DR12,pb1
    000030 7E0F0000    R  MOV      DR0,pb2
    000034 120000      R  LCALL    f_b?_
    

    After calling f_b() no code at all...


    CONCLUSION:

    This effect persist always when using constructions like
      *ptr_To_Structure_X = *function_Returning_Ptr_To_Structure_X();
    

    It's seems to be curious, but in real programs this case was encountered after 2,5 years of working with DK251 :)


    All other cases were workarounds like:

      tmp_ptr_To_Structure_X = function_Returning_Ptr_To_Structure_X();
      *ptr_To_Structure_X = *tmp_ptr_To_Structure_X;
    

    This workaround produce good code (see example above).

    P.S.
    Bug was encountered just after millenium :) so you can imaginate which ideas we research at first ... :)




  • I believe you have a C language mistake, not a compiler bug.

    // ---- Beginning of ERR_PTR.C  ----
    typedef unsigned char UCHAR;
    typedef void * PTVOID;
    
    typedef struct { // Some structure with size <= 4 bytes
      UCHAR uc0;
      UCHAR uc1;
      UCHAR uc2;
      UCHAR uc3;
    } STR_A, *PTSTR_A;
    
    typedef struct { // Some structure with size > 4 bytes
      UCHAR uc0;
      UCHAR uc1;
      UCHAR uc2;
      UCHAR uc3;
      UCHAR uc4[10];
    } STR_B, *PTSTR_B;
    
    // 'volatile' just to prevent optimizing
    volatile PTSTR_A pa1,pa2;
    volatile PTSTR_B pb1,pb2;
    
    PTSTR_A f_a( PTVOID p)
    {
      return( (PTSTR_A) p );
    }
    
    PTSTR_B f_b( PTVOID p)
    {
      return( (PTSTR_B) p );
    }
    
    void main(void)
    {
     *pa1 = *pa2;  //OK_1, (copy via ?C?BMOVEPP8)
     *pb1 = *pb2;  //OK_2, (copy via ?C?BMOVEPP8)
     *pa1 = *f_a( (PTVOID) pa2 ); // BUG_1: you've stripped the volatile qulifier.
     *pb1 = *f_b( (PTVOID) pb2 ); // BUG_2: you've stripped the volatile qulifier.
    }
    
    Both f_a and f_b strip volatile from the pointer's pa2 and pab. You got what you
    coded. Aside from the fact that f_a and f_b can be replaced by simple casts, you use of typedef's to hide pointers which is disconcerting (to me at least). If you
    want your struct elements to be volatile and not have to worry about putting the
    volatile keyword everywhere then delcare your struct's like this:
    typedef struct { // Some structure with size <= 4 bytes
      volatile UCHAR uc0;
      volatile UCHAR uc1;
      volatile UCHAR uc2;
      volatile UCHAR uc3;
    } STR_A, *PTSTR_A;
    
    typedef struct { // Some structure with size > 4 bytes
      volatile UCHAR uc0;
      volatile UCHAR uc1;
      volatile UCHAR uc2;
      volatile UCHAR uc3;
      volatile UCHAR uc4[10];
    } STR_B, *PTSTR_B;
    
    // Pointers point to a struct with all elements volatile. We don't need volatile
    // on our struct pointers now.
    PTSTR_A pa1,pa2;
    PTSTR_B pb1,pb2;
    
    // and then replace f_a and f_b with proper casts. Simple is better.
    pb1 = (PTSTR_B *) pba1;
    pb2 = (PTSTR_B *) pba2;
    
    Let me know how this works, I only have C51.

    - Mark

  • >I believe you have a C language mistake, not a compiler bug


    In real program:
    - there are no 'volatile' attributes and called functions are 'extern'.
    - 'Typedefs' widely used in real program by compatibility and easy porting reason's.


    However,
    1) Keyword 'volatile' was added just in example only to prevent compiler optimization
    and in fact have no meaning for discussed problem.

    2) All used in example 'Typedefs' also have no meaning for discussed problem, the same result if using

    STR_A * f_a( void * p) {...}
    
    instead of
    PTSTR_A f_a( PTVOID p) {...}
    
    This is only 'style' question.

    Each time when I find new compiler bug I
    specially 'construct' my example to be short (minimal as possible), simple, clear and obvious. Sorry, if not :)
    This is because my question is not subject for public discussion in this place. I think KEIL compiler-designer's perfectly understand me :)


    >Let me know how this works, I only have C51

    Naturally, this is not work (because reasons above).

    Mark, thanks for your advice, but problem not in how to find 'workaround' ?
    My own workaround was supplied with example.

    Moreover, my workaround obviously demonstrate that problem in bug in C251 code-generator (IMHO).

    Look once again:

    This not work:
    // This line produce crazy code or no code at all ...
    
      *ptr_To_Structure_X = *function_Returning_Ptr_To_Structure_X();
    

    This work (workaround):
    // This line produce true code - just save function result to temporary pointer
    
      tmp_ptr_To_Structure_X = function_Returning_Ptr_To_Structure_X();
    
    // This line work good because produce call to library function
    
      *ptr_To_Structure_X = *tmp_ptr_To_Structure_X;
    

    And if we return to subject of my first letter:
    - I asked help from KEIL support,
    send 4 letters from 13.jan to all known KEIL email's - no answers :(

    Where really working KEIL-support E-mail ? Who can help ?


  • Sergey,

    I looked through our support log and only found 1 e-mail that we just received from you on February 15, 2001. I didn't see that any other e-mails came to support@keil.com or support.us@keil.com from you since the beginning of the year. Maybe you used a different e-mail address?

    You may also want to check your sent items folder to be sure you actually sent the e-mail to us.

    Since you are located outside of North/South America, we forwarded your request on to Germany for technical support. Most of the office there has been out last week at the Embedded Systems Show, so turn-around time for questions was probably slow because of that.

    Nonetheless, I have been able to duplicate the problem you are speaking of and have forwarded it to engineering. We should hear something in a few days on that.

    Jon

  • If you supply me with your email,
    I can resend all my original letters
    to:

    <support@keil.com>
    <support.us@keil.com>
    <support.intl@keil.com>
    <Rudolf Baumgartner>
    <Reinhard Keil>

    More punctually, one answer I receive from email-robot on 'support@keil.com'
    that my inquire was recended to support.intl@keil.com. Thats all.