TDA4VM-Q1: AUTOSAR Os: Data Abort failure during initialization of CAN message RAM of MCAN0

Hello Eric,

of course you are right, the start address of CAN message RAM is 0x02708000. 

The function which causes the problem wants to initialize the section with 0x00000000 so it is hard to see if a value has been changed because the memory has got already this value. 

When I try to change the memory in the memory browser of CCS I got the error message:

MAIN_Cortex_R5_1_0: Trouble Writing Memory Block at 0x2708000 on Page 0 of Length 0x4: (Error -1065 @ 0x2708004) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.7.0.00213) 

Could that be a hint to the underlying problem?

Info:

If I check the memory of MCAN0 configuration registers these are also complete 0x000000.

Regards

Bastian

Bastian,

Thanks for checking this. Yes, it looks as though these registers are not accessible at the moment you are trying to read them. I've checked on my board, after booting up the board, I am able to read the registers at 0x02701000:

Then, I tried to write into the RAM:

And this is all done while connected to mcu3_0:

Can you check if you can at least see the registers at 0x02701000? This can give us a clue if there are at least some values and the CAN is powered/clocked.

Then, can you also tell me how you are booting the board? I'm assuming SBL, so if you could tell me what your appimage consists of? Or any details you can provide about your bootflow.

If you want to try and read the CAN registers with my working testcase, I've developed the following SD card boot binaries that you can try and connect after booting up to mcu3_0 and read the registers at 0x02701000. If you do run this test, you can see some output come out of MCU_UART (where you normally get the SBL logs).

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/5076.app

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/4062.tiboot3.bin

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tifs.bin

Thanks,

Erick

Hi  Erick, 

I will try your images as soon as possible (I am on a business trip at the moment ). 

I have a question regarding memory access. Could I provide the access by calling CSL_armR5MPUCfg during init of my binary?

BR

Bastian

Bastian,

The MCU3_0 does not need any MPU configuration to access this region, so modifying CSL_armR5MPUCfg should not be necessary. This actually looks more as if the module is not powered on.

To rule out the MPU, we can try to connect to the peripheral from another core. The easiest way would be to use the "CS_DAP" device. If you right click on the area with the cores and select "Show all cores", you can see the "Non Debuggable Devices", and under that catagory is the CS_DAP, which you can connect to. This should have access to the CAN registers regardless of MPU settings. Please see if you can do toggle a bit in the 0x02708000 region from here.

Let me know if this makes sense.

Meanwhile, can you let me know how you boot up your system? Which bootloader are you using and what is the media (SD, Flash, UART, GEL, etc.)

Thanks,

Erick

Hi  Erick,

Erick Narvaez said:

The MCU3_0 does not need any MPU configuration to access this region, so modifying CSL_armR5MPUCfg should not be necessary. This actually looks more as if the module is not powered on.

But I am not sure if this is called anyway. 

Erick Narvaez said:

To rule out the MPU, we can try to connect to the peripheral from another core. The easiest way would be to use the "CS_DAP" device. If you right click on the area with the cores and select "Show all cores", you can see the "Non Debuggable Devices", and under that catagory is the CS_DAP, which you can connect to. This should have access to the CAN registers regardless of MPU settings. Please see if you can do toggle a bit in the 0x02708000 region from here.

I am not able to get access via CS_DAP to this region:

Erick Narvaez said:

Meanwhile, can you let me know how you boot up your system? Which bootloader are you using and what is the media (SD, Flash, UART, GEL, etc.)

We boot via SD card.

BR

Bastian

Hello Bastian,

Can you also change in the CS_DAP memory browser view from "APB_View" to "System_View"?

When you boot with SD card, what bootloader are you using? SBL? Can you please share the files you are booting with?

It would be helpful to see the boot logs as you are booting to make sure everything is initialized properly. Are you using your own boot binaries or are you using the default ones provided by the SDK?

Regards,

Erick

Hi Erick,

we are going on in our investigation and it seems that our problem has been that we set the entry point on the main function of our application and not to the resetvector. So c_int00 has never been called when we flash and start the programm via CCS Debugger. 

Now we are facing the problem that the entry point seems to be correct (we include resetvecs.asm to our build and set the entry point to _resetvectors) but something is loaded "over" the code after loading the binary with the debugger. This is the compare with with a working freertos application.

The startup code beginning with adress 0x00000000 is similar except the loaded address but when I load the AUTOSAR programm the debugger shows this:

Do you have got an idea what could be the reason?

Best regards

Bastian

Bastian,

I am not clear on how you are initializing your board. Can you tell me how you boot the board up from power on? Is there an SD card involved, and if so, what binaries are you using? This would give us a hint of what is already present on the system memory.

To answer you question, if you are getting overloaded by the application you are loading in the debugger, you need to check what is in that area, a good place to start is the .map file that is generated when you compile the code. If you do not expect something to be using that memory section, some other dependency can be getting pulled in and loaded on top of your code.

If you could share the .map file and let me know what address you are seeing the overload issues, we can see if this file is the culprit.

What is your program composed of? Is it using TI SDK libraries?

Regards,

Erick