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.

OMAPL138 SYSBIOS ARM system memory access

Other Parts Discussed in Thread: OMAP-L138, SYSBIOS

Hi everyone,

I have just purchased the OMAP-L138LCDK as a development platform to start writing code and it is my intention to use TI’s RTOS (SYS-BIOS) on the ARM9 core to be the master and look after the HMI. However I have encounter my first stumbling block in creating/using a SYS-BIOS for the ARM9 core in an OMAP-L138.

It would appear that SYS-BIOS hello world template is missing a whole section of CPU memory i.e. system registers. For example the PSC1 register located at address 0x01E27000, just to name one.

This is illustrated in the following screen capture:

Essentially if I try and access this memory location I receive a runtime page fault error.

 

Yet, I can create a non-SYS/BIOS “hello world” project targeted on the ARM core I do not encounter this issue.

Similar, if I create a DSP-BIOS “hello world” project targeted on the DSP core I do not encounter this issue.

I do not believe that this is a permission/access issue and enabling and disabling the MMU seem to makes no difference.

I suspect that a whole section of system memory addresses is just simply not define in the SYS-BIOS ARM template project.

Any assistance in fixing this problem will be gratefully appreciated.

Matt.

 

The SYS-BIOS ARM project was created with:

CCS version 6.0.1

Compiler TI v5.1.11

SYS/BIOS v6.41.2.41

and XDCtools v3.30.6.67_core

  • Matthew,

    For the ARM-side non-SYS/BIOS case, are you using the same GEL file as for the SYS/BIOS case?  Have you verified that the PLL1 register region is properly declared in the CCS memory map?

    Also, can you please describe how you are enabling/disabling the MMU, and what settings you are using?

    And, have you tried accessing some of the PLL1 registers from a program?  I’m wondering if those work, and if it is just the CCS views that are not working.

    Thanks,
    Scott

  • Hi Scott,

    Thank you for your quick reply.

    I am not aware that I’m using a gel file, as there are none associated with the project, and I thought that “.gel” scripted files are only required for older version of CCS. With that said, I am using the same target configuration file, “filename.ccxml” for each of the projects.

    I do agree with you, that this issue is most likely due to the fact the register region have not been properly declared. It was my hope that the by creating a default SYS/BIOS project for the targeted platform and processor (i.e ARM) this would automatically be done for me, but alas this was is not the case and is the point I want to drive home to TI. i.e. making a SYS-BIOS project for the OMAP-L138 ARM core does not work straight out of the box.

    Yet, it would appear that the declaration of CPU register regions works fine for none SYS/BIOS projects on the ARM core and either RTOS or non RTOS projects on the DSP core for the OMAP-L138.

    So if there was a way to import the memory-map from these other projects I think this will solve my issue. As identified in the last post here: https://e2e.ti.com/support/embedded/tirtos/f/355/p/200390/712854

    However, as a new user to CCS, I cannot find where to make such a change, as the workshop diagram below seem to be for an older version of CCS where “Tools” is available in the menu bar.

     

    As for turn on/off the MMU, I did this in the .cfg file, thinking that this might help after reading other forum posts but it did not.

     

    As for accessing a CPU register in a program, this is how I discovered the problem. By single stepping through the program it could access and then read/write to the register PCS0 (located at 0x01C10000) but then when it tries to do them same command for the register PCS1 (located at 0x01E27000) I can see that this memory location produces a page fault error before the line of execution. Thus when it does try execute the line it crashes, as the program does not have a valid pointer.

    Upon further investigation of the CPU registers, it would appear that there is a whole suite of unmapped CPU registers which should be accessible by the core under the SYS-BIOS project.

     

    If you can provide any further guidance that will be helpful.

    Matt

  • Matt,

    Thanks for the additional details.

    GEL files are still used in CCS, and they are usually referenced in the ccxml file.  So if you are using this same file in both cases it is not the issue.

    I think you should try enabling the MMU again.  In your screenshot the “Enable MMU” box is checked.  But the “Add the MMU module to my configuration” box is not.  You need to click that box too, to bring in the MMU support into your application.  Can you try doing that?  If the MMU support is indeed included in your application you’ll see it in the “Outline View” that lists modules actually used in the application.  This view is normally in the upper right corner in CCS.

    Thanks,
    Scott

  • Hi Scott,

    I have had a look at both .ccxml file, viewed as "source", and I cannot see any reference to a “.gel” file. However with that said it would appear that there is to be a .gel running as I can see configuration steps upon loading the program. I also saw error appear with the following file name “OMAP-L138_LCDK.gel”

    That is, when I go and reload the same SYS-BIOS project on the ARM9 core a second time, without power cycling the board, I receive the following error.

    ARM9_0: Output:      Target Connected.

    ARM9_0: Output:      ---------------------------------------------

    ARM9_0: Output:      Memory Map Cleared.

    ARM9_0: Output:      ---------------------------------------------

    ARM9_0: Output:      Memory Map Setup Complete.

    ARM9_0: Output:      ---------------------------------------------

    ARM9_0: GEL: Error while executing OnTargetConnect(): Page fault occurred reading 0x01E27800

           at (*((unsigned int *) ((0x01E27000+0x800)+(4*LPSC_num)))&0x1F) [OMAP-L138_LCDK.gel:787]

           at PSC1_LPSC_enable(0, 0) [OMAP-L138_LCDK.gel:523]

           at PSC_All_On() [OMAP-L138_LCDK.gel:244]

           at OnTargetConnect()

     

    FYI - I have enabled MMU as you have requested, however I do not see where to find this item in the Outline overview.

     

    And as I reported previously this did not seem to make any difference.

     

    My suspicion is that there is a setting in the TI-RTOS for configuring the CPU memory to map the missing registers that currently reside in the physical memory. e.g. PSC10ARM @ 0x01E27000


    But I have no idea in CCSv6 or SYS-BIOS where this information is defined for OMAPL138-ARM9 core.

    If you can provide guidance in mapping the CPU memory to the physical memory that will be most helpful

  • Hi Scott,

    Any luck find on where I need to modify the memory map.

    To assist I have gone through the process of making 2 new SYS-BIOS projects:

    1. SYS-BIOS-ARM. This has a page fault error when you try to read certain system registers, e.g. "PSC10ARM" at 0x01E27000

    2. SYS-BIOS-DSP. This project is able to read and write to the system registers, e.g. "PSC10DSP" at 0x01E27000

    Please find attached the ".map files for each project. this may be able to shed some light on the matter

    Additionally I have created a Hello-World project for the ARM and this seem to be able to read and write to the system registers, e.g. "PSC10ARM" at 0x01E27000

    The ".map" file for this project has been uploaded as well

    Thanks

    Matt

    6765.mapfiles.zip

  • Matt,

    Sorry for the very slow reply.  

    And thanks for the map files.  These show the memory used by the application.  They don’t show what the debugger (CCS) considers mapped memory, or reflect what the MMU is configured for.

    Also, BTW, the example programs won’t map or enable access to *all* memory areas.  They should work out of the box, but all memory regions of the device may not be enabled, as that is not appropriate/necessary for the example.

    I don’t have an LCDK board but will try to borrow one to recreate what you are reporting.  It still seems to me that PLL1 is protected, probably thru some MMU settings.  (There is no MMU protection available from the DSP side.)  This could be because PLL1 is critical to allow access to external memory, and whenever it is bypassed external memory cannot be accessed.

    I’ll post back when I know more…

    Regards,
    Scott

  • Hi Scott,

    I do appreciate that you are taking the time to look into this and to provide you with some further guidance.

    I do not think it is a memory protection issue, as there is a whole area of physical memory register that the default ARM SYS-BIOS project can not access which should not be protect, e.g. UART1 and UART2, I2C1

    From my investigation, and I admit that I have not gone and checked every register access, but using CCS view memory the SYS-BIOS ARM project can view and access memory the following registers

    Register Address
    EDMACC0ARM 0x01C14000
    UART0 0X01C42000
    I2C0ARM 0X01C22000
    TIMER64P0ARM 0X01C20000
    TIMER64P1ARM 0X01C21000
    TIMER64P2ARM 0X01F0C000
    TIMER64P3ARM 0X01F0D000
    SPI0ARM 0X01C41000
    SPI1ARM 0X01F0E000
    RTCARM 0X01C23000
    PLL0ARM 0X01C11000
    ECAP0ARM 0X01F06000
    ECAP1ARM 0X01F07000
    ECAP2ARM 0X01F08000
    EPWM0ARM 0X01F00000
    EPWM1ARM 0X01F02000
    MMCSD0ARM 0X01C40000

    But I can not access the following registers

    Register Address
    EDMACC1ARM 0x01E30000
    UART1ARM 0X01D0C000
    UART2ARM 0X01D0D000
    I2C1ARM 0X01E28000
    PLL1ARM 0X01E1A000
    GPIO0ARM 0X01E26000
    LCD0ARM 0X01E13000
    MMCSD1ARM 0X01E1B000
    EMIFA0ARM 0X68000000
    USB0ARM 0X01E00000
    USB1ARM 0X01E25000

    From this I can surmise that the memory map, and hence the reason why I receive page faults accessing these registers, has not been configured for the physical regions 0x01D0 000 up to 0x01EF FFFF.

    So, my question is how do I rectify this for SYS-BIOS ARM?

    Thanks,

    Matt

  • Matt,

    I got access to a board this morning and could recreate what you described.  The address 0x1e27000 was initially visible after loading a program, but was not when run to main().  Backtracking I could see that the peripheral memory regions went away during MMU module startup.

    Interestingly enough, this board I’m using is in our regression test farm, and the first time I connected I received the same GEL error you reported.  This was because the board was not power cycled since a previous run, and the “on connect” steps in the GEL file were trying to access areas that the already-enabled MMU was protecting.

    I then talked to the MMU module designer.  There are several regions that get mapped by default, including the configured memory regions for the platform, and then the peripherals that the kernel really cares about (like the timers).  And this may map some additional peripherals that are nearby (because of the page sizes).  Other peripherals that are not used by the application are intentionally not mapped in the MMU.

    You can map the peripherals you care about by making some additions to your application’s .cfg file.  I added the below to my .cfg file to map the 0x1e27000 region, and it became accessible for me:

    var Mmu = xdc.useModule('ti.sysbios.family.arm.arm9.Mmu');
    Mmu.enableMMU = true;

    var peripheralAttrs = {
        type : Mmu.FirstLevelDesc_SECTION,
        bufferable : false,
        cacheable  : false,
    };

    var peripheralBaseAddr = 0x1E27000;

    Mmu.setFirstLevelDescMeta(peripheralBaseAddr, peripheralBaseAddr, peripheralAttrs);

    You can do something similar to map the peripherals you care about.  

    There is some documentation for the ARM9’s MMU module that may help: in the “docs” subdirectory of your bios_6_41_02_41 installation, double click on “Bios_APIs.html”, and then navigate to: ti.sysbios.family.arm.arm9.Mmu

    Please let me know if this does not resolve the issue for you.

    Regards,
    Scott

  • Hi Scott,

    Your last post did the trick, thank you for your assistance in this matter.

    I now have a better understanding of what the MMU module does and how to use it and thank you for the link to the API documentation.

    It was just a bit deceptive in the GUI perspective that there is only 2 check boxes, add MMU and the enable MMU.

    As a new user seeing only a check box with enable MMU, I thought I would gain access to all of the peripheral memory, but it appears that this is not the case and you need map this explicitly in the cfg script view.

    Thanks again

    Matt