• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 405 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/AM5728: L3 errors in SDK example

Michael Shklyarman
Genius 12740 points
Part Number: AM5728

Tool/software: TI-RTOS

Champs,

I've been helping customer chase elusive L3 errors and am currently able to see an issue directly on examples we provide. I am not sure this is the same issue the customer experiences but I need to get to the bottom of it. In a nutshell I am loading rtos_template_app_am572x_a15 project into CCS, build and run with no issues. However, there are few oddities about it:

1. When I first connect to A15 (prior to loading the .out) I can see L3 error registers in the Registers view of the CCS with no issues (e.g. L3_TARG_STDERRLOG_CUSTOMINFO_OPCODE)

2. After I load the firmware CCS shows "Error: unable to read" for these registers

3. The firmware appears to be running fine but when I pause it CCS still cannot read the L3 registers

4. In order to understand better what is going on I have installed HW ISR as follows:

var hwi4Params = new Hwi.Params();
hwi4Params.instance.name = "L3_DbgErr";
hwi4Params.priority = 41;
hwi4Params.eventId = -1;
hwi4Params.enableInt = true;
Program.global.PdInt = Hwi.create(41, "&INT_L3_DbgErr", hwi4Params);

and put a breakpoint in the INT_L3_DbgErr() function which only calls Hwi_clearInterrupt(41).

the breakpoint gets hit even before the task gets a chance to run. Thus AFAIU, there are real L3 Errors there but they do not cause issues with this particular example.

5. Last but not least, I tried another example from the PDK: GPIO LED blink one. With this example I did NOT observe any issues with L3, CCS always reads L3 registers with no issues and I do not see errors there.

Any insights will be greatly appreciated.

Thanks

Michael

  • 0
    TI__Guru* 95265 points
    Michael,

    Can you explain which P-SDK release you used? Is it the latest 5.2? And the CCS version?
    >>> PDK: GPIO LED blink one >>>> Is it GPIO_LedBlink_<board>_armTestProject?

    Regards, Eric
  • 0 in reply to lding
    TI__Genius 12740 points
    Hi Eric,

    I am using CCS 8.3.0. The rtos_template_app_am572x_a15 example is from processor_sdk_rtos_am57xx_5_02_00_10. The GPIO_LedBlink_idkAM572x_armTestProject project is generated by the pdkprojectcreate.bat in pdk_am57xx_1_0_12.

    regards,
    Michael
  • 0 in reply to Michael Shklyarman
    TI__Guru* 95265 points
    Michael,

    As updated offline, you tried by "configuring MMU descriptors for L3 address space (0x44000000) I was able to fix the RTOS template application where I observed L3 issues initially. I copied the MMU configuration from the .cfg file provided for the LED blink example. It seems that the MMU initialization for L3 registers space is in fact necessary for proper operation of the SoC, even if the end user application does not access L3 registers explicitly."

    Suggestion was sent to customer to see if this resolve their issue. We need to understand why MMU configuration for L3 registers space is required to begin with.

    Regards, Eric
  • 0 in reply to lding
    TI__Genius 12740 points

    Eric,

    Customer repeated the original test and the failure still occurred (CPU hangs, completely unresponsive). They will continue testing to try and get more leads. In the meantime we really need to understand what causes L3 errors when MMU isn't configured for L3 registers. The GPIO led blink example configures not only L3 configuration registers but also 0x43200000 region which appears reserved in the L3 memory map. I can't explain these setting based on the available documentation but they do appear to be required. I need to understand the underlying reason in order to be able to guide the customer to make necessary setting for their application.

    Thank you,

    Michael

  • 0 in reply to Michael Shklyarman
    TI__Guru* 95265 points
    Hi Michael,

    In the GPIO_LedBlink_idkAM572x_armTestProject, the MMU setting is below:

    /* Enable the cache */
    Cache1.enableCache = true;

    /* Enable the MMU (Required for L1 data caching) */
    Mmu.enableMMU = true;

    var attrs = new Mmu.DescriptorAttrs();
    Mmu.initDescAttrsMeta(attrs);
    attrs.type = Mmu.DescriptorType_BLOCK;
    attrs.noExecute = true;
    attrs.accPerm = 0; // R/W at PL1
    attrs.attrIndx = 4; // Use MAIR0 Byte2
    Mmu.setMAIRMeta(4, 0x04);
    Mmu.setSecondLevelDescMeta(0x43200000, 0x43200000, attrs);

    /* Set IO Delay configuration areas as non-cache */
    attrs.attrIndx = 1;
    Mmu.setSecondLevelDescMeta(0x4844a000, 0x4844a000, attrs);
    Mmu.setSecondLevelDescMeta(0x4ae07d00, 0x4ae07d00, attrs);

    What you added for L3: L3_MAIN_SN 0x4400_0000 0x457F_FFFF 24MiB L3 configuration registers (Service Network)?

    For the suggestion to customer, they added MMU for 0x4400 _0000 to 0x4580_0000, correct? Do they also add 0x4320_0000 (4MB)?

    The document for 4320_0000 to 0x4330_0000 is reserved. I can't find what it is.
    0x4330_0000 to 0x4360_0000 is EDMA TPCC and TC0/1.

    Regards, Eric
  • 0 in reply to lding
    TI__Genius 12740 points
    Hi Eric,

    Yes, you are right, the config for 0x44000000 was added by me. Customer did not add 0x4320_0000, only 0x4400_0000. I really need to understand what purpose does it serve.
    thanks
    Michael
  • 0 in reply to Michael Shklyarman
    TI__Guru* 95265 points
    Hi Michael,

    I looked the internal TRM for AM57x device, the region 0x4320_0000 to 0x4330_0000 are also marked as reserved. I searched .cfg file, many of them have this MMU setup. It may be a simple copy and paste. I didn't find out how 0x4320_0000 originally came from.

    Regards, Eric