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.

AM2634: AM2634 MCAL Issues: MCAL Demo Project, Interrupt Handling, VIM Bug, and GPT Timer Interval

Part Number: AM2634

Tool/software:

Dear TI team,

I am using the AM2634 and MCAL software, and I have encountered the following issues that I would like to ask about.

1. Does TI provide an MCAL demo project?

Currently, the MCAL_AM263X_10.00.00.zip provided by TI does not contain an MCAL demo project.

2. Reading the interrupt number of the currently executing register

When using the TI AM263x, it is not possible to directly read the interrupt number of the currently executing interrupt through the register. Instead, it is necessary to first read another register (which stores the address of the currently executing interrupt handler) and then read the original register to obtain the interrupt number. I'm unsure whether this approach is considered a workaround.

/* Get current interrupt number */
VIM_InterruptHandler interruptHandler = (VIM_InterruptHandler)(ptrVIMRegs->irqVectorAddress);
uint32 intNum = (ptrVIMRegs->activeIrq & 0x3FFU);

3. Issues encountered when using sys_vim.c in the demo code

The MCAL provided by TI includes a VIM (Vector Interrupt Manager) demo code, which uses assembly language to enable and disable interrupts(enableDisableIrqFiq). However, when compiler optimization is enabled, this assembly code causes a trap. This seems to be a bug in the demo code. Does TI have an updated version of this demo code?

4. How to calculate the GPT timer interrupt interval

Currently, we are using the GPT timer, which is driven by the RTI module. The RTI module has a clock source that is divided based on ClockDivId, and the resulting frequency becomes the actual RTI frequency. All these configurations are set up through EB.

At runtime, we can configure how often the RTI triggers an event, and each event triggers the GPT timer once. The function StartTime() can be called at runtime to set the interrupt interval.

However, the calculated interrupt interval does not match the measured result.

Current EB settings:

  • The GPT timer references McuClockSettingConfig_RTI0's McuClockReferencePoint_0 (Figure 1).

  • McuClockReferencePoint_0 frequency is 2E8 (Figure 2).

  • The clock divider is 0 (Figure 3).

Figure 1 

Figure 2 

Figure 3

Runtime settings:

  • Compare up counter 1 is set to 199 (Figure 4), meaning an event is triggered every 200 cycles.

  • This means 2E8 / 200 = 1E6, approximately 1 microsecond per event.

  • Figure 5 shows that the GPT timer is started, and an interrupt occurs every 20,000 events, meaning it should be triggered every 1 microsecond × 20,000 = 20ms.

  • However, using TSMASTER, the actual measured interrupt interval is 0.2ms, which is 100 times shorter than expected.

Figure 4 

Figure 5
These are my questions, and I look forward to your response.
Thanks.

Best Regards,
ph tseng

  • Hi ph tseng,

    Please expect a small delay in response as the expert is out-of-office today.

    Regards,
    Shaunak

  • Hello,

    Currently, the MCAL_AM263X_10.00.00.zip provided by TI does not contain an MCAL demo project.

     Yes (mcal_demo is not provided as part of mcal releases), any specific requirement for mcal_demo? Functionality wise testing is part of mcal/examples.

    2. Reading the interrupt number of the currently executing register

    Both lines serve different purpose nothing like interdependencies.

    3. Issues encountered when using sys_vim.c in the demo code

    What kind of trap? Need more clarity on the behavior.

    4. How to calculate the GPT timer interrupt interval

    We will analyze and will get back to you.

    Thanks,
    Gunjan

  • Hello,
    Thank for your reply,

    Regarding issue 3.

    In sys_vim.c(provided by MCAL_AM263X_10.00.00.zip), within the vimIrqDispatcher function, when MCAL_NESTED_INTERRUPTS_IRQ_ENABLE is enabled, the function enableDisableIrqFiq(1) is called (Figure 1). The enableDisableIrqFiq(1) function is written in assembly language (Figure 2), and it directly stores the CPSR into register r0. This overwrites the interrupt handler that was previously stored in r0, resulting in a branch to an incorrect memory location when attempting to call the interrupt handler. This leads to a trap.

    As shown in Figure 3, addresses 0x178 to 0x18C contain the assembly code of enableDisableIrqFiq, and at address 0x194, a branch is made to the incorrect r0 value, which causes the trap. Figure 4 shows that after executing the instruction at 0x194, a prefetch trap is triggered.

    This issue only occurs when compiler optimization is enabled—under this condition, register r0 is used to temporarily store the interrupt handler.

    The compiler being used is TI Clang v4.0.1 LTS.

     Figure 1

     Figure 2

     Figure 3

     Figure 4

  • Regarding Issue 2, here is a more detailed explanation. I wrote a function that reads the currently executing interrupt number via a register, using two different methods. Figure 1 shows the method where the interrupt number is read directly, while Figure 3 shows the method where the interrupt handler is read first, followed by reading the interrupt number. Figures 2 and 4 show the respective results. As seen in Figure 2, intNum is 0 and fails to read the expected value of 91, whereas in Figure 4, the correct value is successfully read.
     Figure 1

     Figure 2

     Figure 3

     Figure 4

    Thannks,
    ph tseng

  • Hi Tseng,

    1. Does TI provide an MCAL demo project?

    The release includes example for each module. The example is located in:

    C:\ti\MCAL_AM263X_10.00.00\mcal\examples\Gpt\soc\am263\r5f0_0\ti-arm-clang

    You can import the example "gpt_app.projectspec" to CCS 12.x

    2. Reading the interrupt number of the currently executing register

    You can obtain the interrupt number from VIM register: ACTIVEIRQ

    For example, the interrupt number is 0x5B in below settings:  R5FSS0_CORE0_INTR_RTI1_INTR_0

    3. Issues encountered when using sys_vim.c in the demo code

    What is the optimization level? I tried o=2, and don't see any issue.

    4. How to calculate the GPT timer interrupt interval

    It is determined bythe GptModuleXCounterBlkYFrequency from EB Tresos GUI. It can be 1Hz, 2Hz, ....

  • I can read the interrupt number (first 5 digits):

  • Runtime settings:

    The device has 4 RTI modules. The OS timer use RTI0. The GPT uses other modules which depends on the configuration from the EB GUI.

    The module number is GptChannelId/4 --> RTI1 (1), or RTI2 (2), or RTI3 (3)

    Each RTI Module has two counters: counter 0 and counter 1

    The counter is selected by GptCOunterBlkId:

    The timer frequency is configured using this GUI: 1Hz for RTI0 counter 0 and counter 1; 5 Hz for RTI1 counter 0, 6 Hz for counter 1; 8Hz for RTI2 counter 0.

    Your GPT config set should be mapped to those settings.