AM2432: AM243x Cache and interrupt related question

Hello Ming,

Thanks a lot for the information. 

Further question about enabling the interrupt. From the TRM, there are 512 interrupts are supported for r5f core, are these interrupt prioritized with smaller higher as higher priority?  Could we map to any interrupt number with any peripherals or they are hard-binded?  

Take another case as an example, to enable fault interrupt to respond to a bus fault, what do I need to set interrupt in detail?

Thanks,

Hong 

Hello Ming,

I am asking about the fault handler example, it is because I noticed some different results in my implementation.  I created a bus fault in my example, and it could either go to the fault handler as designed to issue a SW warm reset, or it could go to another route which is not as expected and go through a CPU reset, where I didn't implement the CPU reset handler at all.  I guess there are some configurations I didn't set properly. 

Thanks,

Hong

Hi Hong,

Hong Zhang said:

are these interrupt prioritized with smaller higher as higher priority?

This is correct. Please see these TRM sections:

• 6.2.3.5.5 VIM Interrupt Prioritization
• Table 6-312. R5FSS_VIM_PRI_INT_j Register Field Descriptions

Note nested IRQs are supported in No-RTOS, but are currently unsupported in FreeRTOS:

• https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/KERNEL_FREERTOS_PAGE.html#autotoc_md443
• https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/KERNEL_NORTOS_PAGE.html#autotoc_md490

Hong Zhang said:

Could we map to any interrupt number with any peripherals or they are hard-binded?  

The assignment of interrupt nubmers is fixed, please see the TRM Sections 9.4.1.2 - 9.4.1.5.

Hong Zhang said:

I created a bus fault in my example, and it could either go to the fault handler as designed to issue a SW warm reset, or it could go to another route which is not as expected and go through a CPU reset, where I didn't implement the CPU reset handler at all.

Could you please explain what you're trying to do? Are you trying to detect ECC bus faults?

Regards,
Frank

Hello Frank,

Frank Livingston said:

Hong Zhang said:

I created a bus fault in my example, and it could either go to the fault handler as designed to issue a SW warm reset, or it could go to another route which is not as expected and go through a CPU reset, where I didn't implement the CPU reset handler at all.

Could you please explain what you're trying to do? Are you trying to detect ECC bus faults?

I am working on customized fault handler based on ti's reference HWiP_armv7r_handlers_nortos.c. Instead of using a while loop, I modified it to trigger a SW warm reset instead. The issue I am seeing is that for some cases, it did properly trigger the interrupt handler with BUS_FAULT example case, and successfully issue the SW warm reset, but for some cases, the same abort handler is not triggered, instead, a CPU reset somehow is triggered which set the PC counter to the beginning of the project instead of jumping into the fault hander.  I don't understand why does a BUS fault trigger a CPU reset sometimes instead of the fault handler? Is there other enable/init function to be called to enable the HwiP_irq_handler_c ? 

void __attribute__((interrupt("ABORT"), section(".text.hwi"))) HwiP_prefetch_abort_handler(void)
{
SOC_generateSwWarmResetMainDomain();
}

void __attribute__((interrupt("ABORT"), section(".text.hwi"))) HwiP_data_abort_handler(void)
{
SOC_generateSwWarmResetMainDomain();
}

Hi Hong,

Ok, so you create a bus fault somehow. How is this done?

How do you know a bus fault is detected?

You expect the bus fault to trigger either HwiP_prefetch_abort_handler() or HwiP_data_abort_handler()?

When testing, does the code arrive at either or both of these handlers? When the code arrives at one of these handlers, the warm reset is successful?

In the case you don't arrive at these handlers (and you only observe CPU reset), how to you know the bus fault is detected?

Can you put a breakpoint on all the vectors in the vector table to see which exections are caused by your fault injection?

Regards,
Frank

Hello Frank,

Thanks a lot for your reply. 

Frank Livingston said:

Ok, so you create a bus fault somehow. How is this done?

Created a data bus fault by accessing a memory that is not valid. 

uint32_t * const bad_pointer = (uint32_t *) 0x80000000;
uint32_t val = *bad_pointer;

Frank Livingston said:

How do you know a bus fault is detected?

Set a break point in the fault handler or read the rst_src register via SOC_generateSwWarmResetMainDomain() .

Frank Livingston said:

You expect the bus fault to trigger either HwiP_prefetch_abort_handler() or HwiP_data_abort_handler()?

HwiP_data_abort_handler() should be triggered

Frank Livingston said:

When testing, does the code arrive at either or both of these handlers? When the code arrives at one of these handlers, the warm reset is successful?

For some unknown reason, it could trigger reset and got to reset_addr: .long _c_int00 instead of HwiP_data_abort_handler() for the bus fault. 

Frank Livingston said:

In the case you don't arrive at these handlers (and you only observe CPU reset), how to you know the bus fault is detected?

For some cases, the bus fault is  not detected, but from assembly debug, it could see it goes to  _c_int00  instead. 

Frank Livingston said:

Can you put a breakpoint on all the vectors in the vector table to see which exections are caused by your fault injection?

As I saw from the assembly debug, it goes to reset_addr _c_init00, while I expect it triggers a data abort. 

Thanks a lot,

Hong 

Hi Hong,

Can you share a simple code so I can try the same experiment?

Can you put a SW breakpoint on all the vectors in the vector table to see which exceptions are caused by your fault injection?

Regards,
Frank

Hello Frank, 

The example I use is as below, 0x80000000 is not a valid address in our system, while for AM243X EVB board, this address might be different. 
uint32_t * const bad_pointer = (uint32_t *) 0x80000000;
uint32_t val = *bad_pointer;

I noticed from my testing, the above example could either trigger a proper data abort or goes to reset in the vector table. It is not a consistent behavior. It could trigger a proper data abort this time, and might go to reset in next time, and result could vary with power cycle as well. 

Thanks,

Hong 

Hi Hong,

Ok, I'll try a similar experiment to try and understand this behavior. I'll get back with you later this week.

Regards,
Frank

Hi Hong,

Sorry for the delayed response. I tried a similar experiment, but I wasn't able to reproduce your results.

Here's what I did:

• Imported SDK No-RTOS empty project
• Removed R5F MPU region for DDR (CONFIG_MPU_REGION5)
• Added your code snippet to empty_main()
• Placed breakpoints on all R5F vector table entries
• Executed code through invalid access @ 0x80000000.

I executed this experiment 10 times. I power cycled the EVM between each experiment. In all cases, the R5F arrived at Vector 4 @ 0x00000010 after attempting the invalid access.

I've shared my CCS project below.

Are you sure you aren't executing a reset in your exception handler before you observe the CPU reset?

Regards,
Frank

6471.empty_am243x-evm_r5fss0-0_nortos_ti-arm-clang.zip

Hello Frank,

I could understand that this issue is not easily to be reproduced, because I have seen different behaviors on my side as well. 

I was working on my application image, for one version of the code, it was able to trigger the proper data abort every time. However, with another version of image, even if nothing changes on the fault handler part, data abort triggers CPU reset instead.  While I do see prefetch abort is able to trigger abort handler every time with different versions of code (same fault handler is used) and prefetch abort never triggers CPU reset.

Do you in case have other customers reported that the data abort could possibly trigger CPU reset for this part?  

Thanks,

Hong 

Hi Hong,

Hong Zhang said:

However, with another version of image, even if nothing changes on the fault handler part, data abort triggers CPU reset instead.

Can you share example code demonstrating this behavior?

Hong Zhang said:

While I do see prefetch abort is able to trigger abort handler every time with different versions of code (same fault handler is used) and prefetch abort never triggers CPU reset.

How are you triggering pre-fetch abort? In my testing (using your code snippet), I only observed data abort, never pre-fetch abort.

Hong Zhang said:

Do you in case have other customers reported that the data abort could possibly trigger CPU reset for this part?  

No, I haven't seen this feedback from other customers.

Can you share a toy example demonstrating the behaviors?

• pre-fetch abort instead of data abort
• CPU reset instead of expected data abort

I think this is the fastest path to debugging this issue since I'm unable to reproduce the issue on my side.

Regards,
Frank