• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 607 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.

AM6442: Unexpected Behavior When Using HwiP_construct() for Interrupt ID 6 on AM64x

K.Z
Genius 3215 points

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Hi All,

We are currently verifying the operation of the API functions included in “ind_comms_sdk_am64x_09_02_00_08” MCU+ SDK.

From Linux, which was created based on Processor SDK Linux v9.2, we load a program onto R5F Core 0 and check its behavior.

First, referring to the following sample programs, we are checking the APIs for hardware interrupts:

  • AM64x MCU+ SDK: Driver Porting Layer (DPL) Demo
  • AM64x MCU+ SDK: Hardware Interrupt APIs

It appears that the interrupt number can be set using the intNum member of the HwiP_Params argument in the HwiP_construct() function. Therefore, we repeatedly performed the following steps while incrementing the interrupt number starting from 0:

  1. Execute HwiP_construct() function (interrupt number N)
  2. If HwiP_construct() succeeds, execute HwiP_destruct().

Then, when calling HwiP_construct() with interrupt number 6, we encountered a situation where Linux did not respond to the following command intended to shut down R5F Core 0:

echo stop > /sys/class/remoteproc/remoteproc0/state

Note: By “when calling HwiP_construct(),” we determined this because the print statement inserted immediately before HwiP_construct() was output, but the one immediately after was not.

When testing with interrupt numbers 0–10, all numbers except 6 succeeded (HwiP_construct() returned 0) and did not cause the above situation.

Checking the Technical Reference Manual for interrupt number 6: AM64x/AM243x Technical Reference Manual (Rev. H)
Section 9.4.1.2 R5FSS0_CORE0 Interrupt Map contains a table mapping interrupt numbers to sources.

Interrupt ID 6’s source is listed as R5FSS0_COMMON0_COMMTX_LEVEL_0_0.
Also, Interrupt ID 7 does not appear in the table.
However, based on our earlier test results:

  • Executing HwiP_construct() for interrupt number 6 caused the R5F core to stop responding to shutdown requests.
  • Executing HwiP_construct() for interrupt number 7 succeeded.

If IDs 6 and 7 were reversed, it would make sense that calling HwiP_construct() for a non-existent interrupt number could cause abnormal behavior.

Therefore, we have two questions:

[Question 1]
HwiP_construct() succeeded for interrupt number 7, but does interrupt number 7 actually exist?
Or is it the case that calling HwiP_construct() for a non-existent interrupt number succeeds by design?

[Question 2]
When calling HwiP_construct() for interrupt number 6, the R5F core stopped responding to shutdown requests.
What could be the possible cause of this phenomenon?

Best Regards,

Ito

  • 0
    TI__Guru 59678 points

    Hi Ito,

    Why are you calling HwiP_construct API for each interrupt number? What is the use case here?

    K.Z said:
    HwiP_construct() succeeded for interrupt number 7, but does interrupt number 7 actually exist?
    Or is it the case that calling HwiP_construct() for a non-existent interrupt number succeeds by design?

    This is not the recommended way. The interrupts which are not listed in the TRM should not be used and are considered reserved.

    K.Z said:
    When calling HwiP_construct() for interrupt number 6, the R5F core stopped responding to shutdown requests.
    What could be the possible cause of this phenomenon?

    What error are you getting when doing a graceful shutdown?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Thank you for your reply.

    I would like to explain the background for my questions.

    First, I was verifying the timer overflow interrupt.
    By checking TRM section 9.4.1.2 “R5FSS0_CORE0 Interrupt Map,” I found that the Interrupt ID for timer number X is 152 + X (e.g., Interrupt ID 152 is TIMER0_INTR_PEND_0). Based on this, I changed the timer number and the Interrupt ID while configuring the timer and the hardware interrupt.
    In the main function, I used ClockP_usleep() to sleep while detecting the timer overflow interrupt, and confirmed that a variable representing the interrupt count could be incremented.
    I ran the above checks on the R5F0-0 core program. During the test with Timer 8, when I executed HwiP_construct() with interrupt number 160, the R5F program stopped printing logs thereafter, and the R5F core appeared to stop accepting shutdown requests. Regarding this, since the R5F0-0 core program uses Timer 8 as the instance for the system tick by default, I suspect there was some conflict between ClockP_usleep() and the callback function registered via HwiP_construct().
    From these results, I learned that on the R5F0-0 core, I should not execute HwiP_construct() with interrupt number 160. However, this raised the question of whether it is acceptable to execute HwiP_construct() with other interrupt numbers.
    Therefore, I performed a test in which I executed HwiP_construct() while incrementing the interrupt number starting from 0. I observed questionable behavior with interrupt numbers 6 and 7, which prompted me to ask these questions.

    Note 1: When executing HwiP_construct() with interrupt number 6, log output stops and shutdown requests from Linux are no longer accepted.
    Note 2: Interrupt number 7 does not exist in the Technical Reference Manual, but executing HwiP_construct() with interrupt number 7 does not cause an error.

    Although I do not plan to actually use interrupt numbers 6 or 7, I would like to understand why the behavior is questionable as described above.
    Next, regarding the error encountered during graceful shutdown:
    When attempting to shut down R5F core 0 from Linux, the following message is displayed:
    -----------------------
    root@am64xx-evm:~# echo stop > /sys/class/remoteproc/remoteproc1/state
    -sh: echo: write error: Device or resource busy
    -----------------------

    I have reviewed the page describing the procedures required for graceful shutdown and incorporated them into the R5F program, so I believe the necessary handling is present and not missing.

    AM64x MCU+ SDK: Graceful shutdown of remote cores from Linux


    Finally, I checked the TI forum you pointed out. Since I am using SDK v9.2, I believe there is no issue related to the SDK version.

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Guru 59678 points

    Hi Ito,

    Is it happening only with interrupt number 6? Have you tried other interrupts also?

    Have you tried this without Linux? Is the R5F core working after doing HwiP_construct for interrupt #6?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Thank you for your reply.

    The issue described as “When executing the HwiP_construct() function, the log output from the print statement placed immediately after it does not appear”
    was confirmed while testing interrupt numbers from 0 to 255, and it occurred only with interrupt number 6.

    Regarding the issue of “not accepting shutdown requests from Linux,”
    we have not been able to verify this behavior for individual interrupt numbers, so it is unclear whether this issue is specific to interrupt number 6.

    Next, regarding operation verification without Linux: since this is a custom board,
    the boot mode cannot be freely switched, making it difficult to verify operation without Linux.

    Tushar Thakur said:
    Is the R5F core working after doing HwiP_construct for interrupt #6?

    As part of our investigation, we added a process to increment a global variable in the callback function configured by the HwiP_construct() function.
    We then identified the address of this global variable from the map file and read it from Linux using the devmem2 command.

    As a result, the global variable was incremented each time it was read,
    which indicates that the R5F core itself continues to operate.

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Guru 59678 points

    Hi Ito,

    I am checking this internally with the team, what the interrupt #6 refer to. Please allow some time to revert back.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Thank you for your help,
    Has there been any progress?

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Guru 55513 points

    Hi,

    The assigned expert is currently out of office. Please expect delayed responses.

    Thanks for your patience.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Genius 3215 points

    Hi Vaibhav,

    I look forward to a prompt response.
    Best Regards,
    Ito
  • 0 in reply to Vaibhav Kumar
    Genius 3215 points

    Hi Vaibhav, 

    Has there been any progress?

    Best Regards,

    Ito

  • 0 in reply to K.Z
    TI__Guru 59678 points

    Hi Ito,

    I did not got much information on the interrupt #6, and continue to investigate the same. Meanwhile, please confirm in your application is the interrupt #6 configured twice? 

    K.Z said:
    we added a process to increment a global variable in the callback function configured by the HwiP_construct() function

    From the above it seems the interrupt #6 is getting triggered properly on R5F core. Is this interrupt also used in A53 application?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Thank you for your help.

    Tushar Thakur said:
    I did not got much information on the interrupt #6, and continue to investigate the same. Meanwhile, please confirm in your application is the interrupt #6 configured twice? 

    Is my understanding correct that you want to confirm whether HwiP_construct() is being called twice in the program for interrupt #6?

    In this case, at least in the sections where I modified the sample program, it is not being called.
    I also searched through the code automatically generated by SysConfig, and it was not there either.

    Tushar Thakur said:
    From the above it seems the interrupt #6 is getting triggered properly on R5F core.

    I believe that interrupt #6 is being triggered correctly, and that the callback function is being executed.
    However, perhaps because of this, it appears that the main process is not progressing at all.
    For reference, I tested interrupt numbers 0–255, and the issue where “the print statement immediately after calling HwiP_construct() does not output any log” occurs only with interrupt number 6.

    Tushar Thakur said:
     Is this interrupt also used in A53 application?

    The A53 core is running Linux.

    Although I am not running the program on Linux, I am not sure what processing Linux might be performing in the background.
    Best Regards,
    Ito

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Has there been any progress?

    Best Regards,

    Ito

  • 0 in reply to Tushar Thakur
    Genius 3215 points

    Hi Tushar,

    Has there been any progress?

    Best Regards,

    Ito

  • 0 in reply to K.Z
    Intellectual 411 points

    Hi Tushar,

    I'll be taking over on behalf of Ito-san.

    Could you please update me with the status of this inquiry?

    Thank you!

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Guru 59678 points

    Hi Michael,

    Apologies for the delay here. I did have checked the above behavior.

    Michael V said:
    Could you please update me with the status of this inquiry?

    The behavior above is seen because as soon as you enable the interrupt #6 in your application program, it triggers the ISR. The core is getting ISR again and again and the execution is not coming to the main thread(user context). This is because the Interrupt #6 belongs to the data transmission from core to external debugging devices.

    The interrupt #6 is not used in the SDK and is not supposed to be used by the User in application project.

    As your application project enables interrupt #6 which takes the core execution to ISR again and again making it to never come out of ISR handling. This is the reason why the core is not responding to the shutdown command from Linux and the print statements after interrupt enable are never executed.

    Hope this information is helpful.

    Regards,

    Tushar