AM62A3: DM Core access to MCU_MCAN register space, clarification on RAT

As a quick follow up (thank you Gunter for helping me post!)

the MCAN_isMemInitDone() API simply seems to call below function which just reads a 32bit address. 

memInit = HW_RD_FIELD32(MCAN_SsAddr(baseAddr) + MCAN_MCANSS_STAT, MCAN_MCANSS_STAT_MEM_INIT_DONE);

I added a quick log and verified that MCAN_SsAddr(baseAddr) + MCAN_MCANSS_STAT evaluates to 0x4E09008, which should be covered by the VRAT setup above, and is part of the MCU_MCAN0_SS section. 

It seems like the HW_RD_FIELD32 causes the DM core to crash, so I am wondering if theres some MPU configuration that is not properly set up. I noticed my syscfg out of the box by default as the following REGISTER_REGION area already set up. Is there another MPU instance that should be set up?

Following is the MPU settings for the REGISTER_REGION:

        .baseAddr = 0x0u,
        .size = MpuP_RegionSize_4G,
        .attrs = {
            .isEnable = 1,
            .isCacheable = 0,
            .isBufferable = 0,
            .isSharable = 0,
            .isExecuteNever = 1,
            .tex = 0,
            .accessPerm = MpuP_AP_ALL_RW,
            .subregionDisableMask = 0x0u
        },

Hi, 

Thanks for posting. I will look into it and back to you soon.

Regards,
Aparna

Hi Nick, can you help me confirm that there is then no hard whether or not we use VRAT? In short, it should not affect anything?

What I am noticing on my end is that the function that the DM core is calling to setup the CAN bus is causing the DM core to crash it looks like. Basically:

This function in the DM core is being called ( I added the log) and it seems to hang on HW_RD_FIELD32, which is simply reading an address. The address that gets passed in (from log) is of value 0x04e09008, as the log executes and logs this "MCAN_DRIVER using 0x04e09008!"

uint32_t MCAN_isMemInitDone(uint32_t baseAddr)
{
    uint32_t memInit;
    uint32_t state;

    DebugP_log("MCAN_DRIVER using 0x%08x!\r\n", MCAN_SsAddr(baseAddr) + MCAN_MCANSS_STAT);

    memInit = HW_RD_FIELD32(MCAN_SsAddr(baseAddr) + MCAN_MCANSS_STAT,
          MCAN_MCANSS_STAT_MEM_INIT_DONE);

I have tried other functions in the MCAN driver, which simply write to other addresses in the 0x04e09000 space (or similar, the cfg registers will write to the 0x04exxxxx registers for CAN).

Off the top of your head, do you have any thoughts on why reading or writing these registers will cause the DM core to hang? 

I can do the following tests:

1. Add a few more logs into CAN driver itself, and see what happens
2. Remove the VRAT config from syscfg, and see if any behavior changes

Hi Nick,

from your comments, are you saying that addresses in the range of the MCU_MCAN0/1, i.e. 0x04E00000 to 0x04E1FFFF specifically, DO NOT require any RAT configuration?

I am looking at the Table 2-3 in the TRM and is says RAT_region0 for that range.

Are you saying these address range 0x04E00000 to 0x04E1FFFF automatically goes through the RAT, without configuration needed?

Thanks!

--Gunter

Hello Gunter,

That is correct. My understanding is that the RAT is basically conbinational logic (i.e., it does not really add any latency to signals that pass through it because there are no flops or other circuits that take multiple clock cycles for the signal to pass through), and that any accesses to memory that is in a "RAT region" in the table Gunter posted will be physically exiting the DM R5F subsystem through the RAT circuitry.

Hello Yue,

I chatted with Gunter a bit just now. My first concern would be to check whether the MCAN is actually getting clocked. If there is not a valid clock signal going to the peripheral, I would expect reads and writes to that register space to fail (although I'm not sure what it looks like from the remote core side, I'm used to seeing that read failure from the Linux side with devmem2).

I am passing the thread back to a team member who is more familiar with MCU+ SDK programming to provide additional debug thoughts.

Regards,

Nick

Hi, I am able to execute loopback tests on both MCU_CAN0 and MCU_CAN1 from DM core. Closing this as resolved. Thanks!

Hello Yue,

Glad to hear that yall are able to move forward now that the peripheral is clocked! I've marked this thread resolved, but feel free to create a new thread if you have future questions.

Regards,

Nick