F28035 Cla1ToCpuMsg RAM Allocation

Hello everybody,

I'm working with a F28035 and I'm having some issues related to memory allocation for CLA-to-CPU Message RAM.

According to the memory map showed in the documentation (SPRS584F), the chip has 80h W RAM available for CLA-to-CPU Messages. However, when I try to allocate more than 40h W the .map file shows a wrong number for the used memory (it shows 80h W).

For example, if I declare 3Fh W the .map shows 3Fh, correct; if I declare 40h W the .map shows 40h, which is correct; but if I declare 41h W it shows 80h, non sense.

Is there any consideration that I'm dismissing? Is it possible to use the 80h W that are showed in the datasheet?

Thank you for the answers.

Lucas

  • Hi Lucas

    Lucas Sinopoli
    but if I declare 41h W it shows 80h

    The message ram does accept the full 80h words. How did you declare and place these variables?

    Also what does the .map file show for the section Cla1toCpuMsgRam?

  • In reply to Vishal_Coelho:

    I declare in the following manner:
    ---------------------
    // CLA To CPU memory declarations
    #pragma DATA_SECTION(CLA1Status, "Cla1ToCpuMsgRAM");
    struct CLAStatus CLA1Status;
    --------------------
    And I define the type as:
    --------------------
    typedef struct CLAStatus
    {
    float period;
    unsigned int periodX100;
    long previousPeriod;
    float startPeriod;
     .......
     etc
     ....... 

    } CLAStatus;

    extern struct CLAStatus CLA1Status;
    -----------------------
    So, when I add inside of the type definition enough variables as to  exceed 40h W, the .map goes wrong. As I said, after reaching 40h W only adding 1 more word will make the used memory to go to 80h.
    Here is an example:
    I define 'typedef struct CLAStatus' being 3Eh W long and I check the .map file obtaining
    ---------------------
    PAGE 1:
    ...........
    CLA1_MSGRAMLOW        00001480   00000080  0000003e  00000042  RWIX
    ..........
    ...........
    .........
    Cla1ToCpuMsgRAM 
    * 1 00001480 0000003e UNINITIALIZED
    00001480 0000003e DCDCControl.lib : CLA.obj (Cla1ToCpuMsgRAM)
    .........
    ----------------------
    But if I add a 4 more words to the variable I obtain these results
    ----------------------
    ..............
    CLA1_MSGRAMLOW        00001480   00000080  00000080  00000000  RWIX
    ..............
    .............
    Cla1ToCpuMsgRAM 
    * 1 00001480 00000080 UNINITIALIZED
    00001480 00000080 DCDCControl.lib : CLA.obj (Cla1ToCpuMsgRAM)
    ---------------------
    I hope this provides enough information to diagnose the issue.
    Thanks,
    
    
    Lucas
  • In reply to Lucas Sinopoli:

    Ok I think I know whats happening here. The linker is trying to align the structure to an address that is a multiple of 64(0x40). Normally it should stick it at 0x1480 which is a multiple unless you have other small variables......in which case it will stick the structure at the next multiple 0x14c0. Could you verify the address of _CLA1Status in the map file??

    In such a case, my guess is that the linker assigns the small variables starting at 0x1480, and the structure at 0x14c0 and shows the entire memory as being utilized

    The last bullet point of Section 7.4.1 of SPRU514D talks about why structures are "blocked"

  • In reply to Vishal_Coelho:

    Thanks for your reply Vishal.

    I really don't think that is the problem though, since the address of CLA1Status is 

    00001842   _CLA1Status

    This is because I have another variable declare before CLA1Status that is float.

    So the linker is not assigning multiples of 0x40

    Lucas

  • In reply to Lucas Sinopoli:

    Hmm, The address 0x1842 isnt in either of the message rams. That falls somewhere in Peripheral frame 0.

  • In reply to Vishal_Coelho:

    Sorry, that's wrong. I typed that instead of copying and made a mistake. Here is a copy from the file, as you can see is 1482

    003f12e4   _LIN0INTA_ISR
    003f12e9 _LIN1INTA_ISR
    00001500 _CLA1Parameters
    00001482 _CLA1Status
    003f1348 _LUF_ISR
  • In reply to Lucas Sinopoli:

    Vishal, you were right with the alignment. I add some smaller structures to the memory and checked on the .map finding that CLA1Status is now aligned at 14c0 as you mentioned.

    So I guess the issue is fixed. 

    Thanks for your help!!

    Lucas

  • In reply to Lucas Sinopoli:

    The question that remains open is why without those changes, CLA1Status is being aligned to 0x1482 because that is not a multiple of 64.

    Any ideas?

    Lucas

  • In reply to Lucas Sinopoli:

    My guess on this is that if a structure is smaller than 64 words and it is able to fit it in a page(64 words long) it will do so. This is part of the DP load optimization. It tries not to split a structure over two pages if it can.

  • In reply to Vishal_Coelho:

    By it, I mean the linker will try to optimize the placement