forum logo You are not logged in. [Login] Main Index | Search | Active Topics | New user | Who's Online | FAQ

Other HI-TECH Compilers & Products >> 8051 Legacy Compiler
Previous topic Previous   View all topics Index   Next topic Next   Threaded Mode Threaded  

Pages: 1
Andreapce



Reged: Feb 21 2005
Posts: 39
Loc: Italy
File-Specific memory models
      #17876 - Thu Jun 30 2005 02:59 AM

I need to make two libraries live together: one is for writing flash memory on my AT89C51RD2 and the other is for using a W3100 external comm chip.

The first one needs to be compiled in a "small" model (otherwise it behaves strangely), while the second has been written for being used with the "large" model, thus I set "Large" for the project and "small" for the flash api library.

Thanks to a patch Adam posted I'm now able to set different memory models for each file in the project. Unfortunately, when I tried to compile it I got a bunch of error messages fron the linker:

Code:
 
signatures do not match: ___api_wr_code_page (C:\PCE\Tonio\UDP\flash_api.obj): 0x3079/0x3039 
no psect specified for function variable/argument allocation 
undefined symbols:
?a___api_fct_set_2 (C:\PCE\Tonio\UDP\flash_api.obj) 
?a___api_fct_set_3 (C:\PCE\Tonio\UDP\flash_api.obj) 
stack_internal (C:\PCE\Tonio\UDP\flash_api.obj) 
?___api_wr_code_page (C:\PCE\Tonio\UDP\flash_api.obj) 
?a___api_wr_code_byte (C:\PCE\Tonio\UDP\flash_api.obj)

The undefined symbols regard almost all of the functions in the flash api library.

Any hint?
Thanks,
Andrea

Post Extras: Print Post   Remind Me!   Notify Moderator  
luckyAdministrator
HI-TECH team member
*****

Reged: Oct 06 2003
Posts: 1054
Loc: Brisbane, Australia
Re: File-Specific memory models [Re: Andreapce]
      #17885 - Thu Jun 30 2005 08:37 PM

Quote:

The first one needs to be compiled in a "small" model (otherwise it behaves strangely), while the second has been written for being used with the "large" model, thus I set "Large" for the project and "small" for the flash api library.



You can't have different files compiled with different models linked together into the same project. A memory model is a model in which each function has certain rules on the way in which memory is used. They must all be using the same model so that they can interact correctly with each other.

I think the answer to your problem is to investigate why your flash api "behaves strangely" when not in small model. The main difference between small & large model is that small model uses a statically allocated stack. This may give you a hint as to what the problem is.

--------------------
Matt Luckman
HI-TECH Software

Post Extras: Print Post   Remind Me!   Notify Moderator  
Andreapce



Reged: Feb 21 2005
Posts: 39
Loc: Italy
Re: File-Specific memory models [Re: lucky]
      #17887 - Fri Jul 01 2005 02:43 AM Attachment (482 downloads)

Thanks Lucky.
Well, after looking for all the documentation I could find on Atmel site I didn't find something that could help me, so I contacted their support but they didn't answer yet.
I took a look at the assembler of a simple program that writes a page in flash memory, in the two "flavours", small and large, to see the differencies...but I'm quite new to this world and I lack knowledge, so I had to surrender.

Would you mind checking some code? I attach the .lst files of the function for writing one page in flash, one compiled in "large" model and the other in "small". Maybe you can tell me how to create an assempbler version of the function that I could use in the final project.

Thanks again,
Andrea


PS: I apologize in advance for I'll be away from office next week thus I won't read posts 'til monday 11th.

Post Extras: Print Post   Remind Me!   Notify Moderator  
Dan HenryModerator
Guru
****

Reged: Oct 16 2003
Posts: 3389
Loc: Boulder, Colorado U.S.A.
Re: File-Specific memory models [Re: Andreapce]
      #17897 - Sat Jul 02 2005 01:00 PM

flash_api LARGE.lst physical line #82 (listing line numbered 68) shows one of the PROGRAM DATA PAGE ROM routine's DPTR parameters getting corrupted by accessing the XRAM-stacked parameter nb_data (it appears that add_flash and add_xram parms are passed in registers).

Since you are trying to do assembly-like coding in C by referencing CPU registers directly, here's a workaround you can try (note that since you have not posted the source code, I extracted something close to what the source code probably looks like):

Code:
/*
YOUR CODE:                                     WORKAROUND:                            */
{                                              {
    unsigned char accu;                            unsigned char accu;
    unsigned char save_auxr1;                      unsigned char save_auxr1;

    /* Save environment.                           /* Save environment.
     */                                             */
    EA = 0;                                        EA = 0;
    save_auxr1 = AUXR1;                            save_auxr1 = AUXR1;

                                                   /* Save value of @DPTR-addressed nb_data
                                                    * in SFR B to avoid further DPTR use.
                                                    */
                                                   B = nb_data;

    /* DPTR0 parm                                  /* DPTR0 parm
     */                                             */
    AUXR1 &= ~0x01;                                AUXR1 &= ~0x01;
    DPTRL = (add_flash & 0x00FF);                  DPTRL = (add_flash & 0x00FF);
    DPTRH = (add_flash >> 8);                      DPTRH = (add_flash >> 8);

    /* DPTR1 parm                                  /* DPTR1 parm
     */                                             */
    AUXR1++;                                       AUXR1++;
    DPTRL = (add_xram & 0x00FF);                   DPTRL = (add_xram & 0x00FF);
    DPTRH = (add_xram >> 8);                       DPTRH = (add_xram >> 8);

    /* R1 parm                                     /* R1 parm
     */                                             */
    ACC = 0x09;                                    ACC = 0x09;
    ASM_MOV_R1_A();                                ASM_MOV_R1_A();

    /* ACC parm ***corrupts DPTR***                /* ACC parm ***direct from SFR B***
     */                                             */
    ACC = nb_data;                                 ACC = B;

    /* Select DTPR0 and enable boot ROM.           /* Select DTPR0 and enable boot ROM.
     */                                             */
    AUXR1 &= ~0x01;                                AUXR1 &= ~0x01;
    AUXR1 |= 0x20;                                 AUXR1 |= 0x20;

    /* LCALL 0xFFF0 to invoke PROGRAM DATA PAGE    /* LCALL 0xFFF0 to invoke PROGRAM DATA PAGE
     */                                             */
    __API_FLASH_ENTRY_POINT();                     __API_FLASH_ENTRY_POINT();

    AUXR1 &= ~0x20;;                               AUXR1 &= ~0x20;;
    accu = ACC;                                    accu = ACC;

    /* Restore environment.                        /* Restore environment.
     */                                             */
    AUXR1 = save_auxr1;                            AUXR1 = save_auxr1;
    EA = ea_save;                                  EA = ea_save;

    return (accu);                                 return (accu);
}                                              }

Post Extras: Print Post   Remind Me!   Notify Moderator  
Dan HenryModerator
Guru
****

Reged: Oct 16 2003
Posts: 3389
Loc: Boulder, Colorado U.S.A.
Re: File-Specific memory models [Re: Andreapce]
      #17898 - Sat Jul 02 2005 02:49 PM

Quote:

Maybe you can tell me how to create an assempbler version of the function that I could use in the final project.


In general, the simplest way to create an assembly language module is to write a prototype module in C that uses the desired call/return parameters, locals (i.e., auto variables), externs, etc., and possibly even implements your desired algorithm, then compile to assembly source using the '-S' option to generate a template assembly language for you. Then use that assembly source as the framework into which, you add your assembly code or modify the code generated by the compiler. This way you get all the naming conventions, signature, and other framework generated for you correctly.

In your case, just compile your module using '-S' and rearrange the code similar to what I did for the workaround here so that DPTR is not corrupted.

Post Extras: Print Post   Remind Me!   Notify Moderator  
Andreapce



Reged: Feb 21 2005
Posts: 39
Loc: Italy
Re: File-Specific memory models [Re: Dan Henry]
      #18117 - Mon Jul 18 2005 03:03 AM

Thank you Dan!
Your suggestion was very helpful and now the program works!

The access to the dptr register generated the error.

Thanks a lot again,
Andrea

Post Extras: Print Post   Remind Me!   Notify Moderator  
Dan HenryModerator
Guru
****

Reged: Oct 16 2003
Posts: 3389
Loc: Boulder, Colorado U.S.A.
Re: File-Specific memory models [Re: Andreapce]
      #18175 - Thu Jul 21 2005 07:46 PM

Hey, you told us you'd be back on the 11th. Your boss may have authorized an extra week's vacation, but you didn't check with us!

I'm happy to hear it worked out. Giving advice for users of a toolchain I don't own is risky for me. I'm certain Lucky would have steered you true, but I thought I'd take a crack at it.

Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1


Previous topic Previous   View all topics Index   Next topic Next   Threaded Mode Threaded  

Extra information
0 registered and 0 anonymous users are browsing this forum.

Moderator:  ndouglas, jtemples, Dan Henry, Andrew L, mikerj, dave g, meisty, josh stevo 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is enabled
      UBBCode is enabled

Rating:
Topic views: 5141

Rate this topic

Jump to

Contact Us | Privacy statement HI-TECH Software

Powered by UBB.threads™ 6.5.5