• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 354 subscribers
  • Views 18319 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interrupts from the secure world to the non-secure world.

Yasuhiko Koumoto

Hello experts,

I am using SAM L11 (Core is Cortex-M23).
I did a simple test of the interrupt.
In the case of the handler was the secure world, it worked as I expected.
The instruction sequences are as the follows.
 *(int*)(0xE000E380) = 0;
 *(int*)(0xE000E100) = 1;
 *(int*)(0xE000E200) = 1;
 for(i=0;i<1000;i++);
However, when Interrupt Target Non-secure Register (0xE000E380) was set,
the HardFault had occurred. As for SAM L11, would it be reasonable behavior?
 *(int*)(0xE000E380) = 1;
 *(int*)(0xE000E100) = 1;
 *(int*)(0xE000E200) = 1; /* HardFault */
 for(i=0;i<1000;i++);
Although I put the vector of the secure world to the non-secure world address, the phenomenon was not changed.
From the specification aspect, how does it work?

Thank you and best regards,

Yasuhiko Koumoto.

Parents
  • 0 Arm Employee Badge

    Hi,

    Has the problem been solved?

    >Although I put the vector of the secure world to the non-secure world address,

    > the phenomenon was not changed. From the specification aspect, how does it work?

    This wouldn't work. Non-secure world cannot execute an interrupt handler in the Secure address space.

    Non-secure world must have its own vector table (with boot code such as reset handler) and the interrupt handlers must in in Non-secure memories.

    regards,

    Joseph

Reply
  • 0 Arm Employee Badge

    Hi,

    Has the problem been solved?

    >Although I put the vector of the secure world to the non-secure world address,

    > the phenomenon was not changed. From the specification aspect, how does it work?

    This wouldn't work. Non-secure world cannot execute an interrupt handler in the Secure address space.

    Non-secure world must have its own vector table (with boot code such as reset handler) and the interrupt handlers must in in Non-secure memories.

    regards,

    Joseph

Children
  • 0 in reply to Joseph Yiu

    Hi Joseph,

    I think I have the same "problem" that Yasuhiko Koumoto occured. I try to describe it.

    //Secure world

    NVIC_SetPriority(TRNG_IRQn, 1);
    NVIC_SetTargetState(TRNG_IRQn);
    NVIC_EnableIRQ(TRNG_IRQn);

    TRNG_INTENSET = TRNG_INTENSET_DATADRY;  // enable int
    TRNG_CTRLA |= TRNG_CTRLA_ENABLE;               // enable device. Hardfault will be occur after this instruction

    But if i change the code into...

    //Secure world

    NVIC_SetPriority(TRNG_IRQn, 1);
    NVIC_SetTargetState(TRNG_IRQn);
    // NVIC_EnableIRQ(TRNG_IRQn);

    TRNG_INTENSET = TRNG_INTENSET_DATADRY;  // enable int
    TRNG_CTRLA |= TRNG_CTRLA_ENABLE;               // enable device. Hardfault will be occur after this instruction

    //Non-secure world

    NVIC_EnableIRQ(TRNG_IRQn);

    The non-secure interrupt will occur.

    And I tried put all 5 instructions into non-secure callable function as follow, it worked.

    void __attribute__((cmse_nonsecure_entry)) in()
    {
    NVIC_SetPriority(TRNG_IRQn, 1);
    NVIC_SetTargetState(TRNG_IRQn);
    NVIC_EnableIRQ(TRNG_IRQn);


    TRNG_INTENSET = TRNG_INTENSET_DATADRY; // enable int
    TRNG_CTRLA |= TRNG_CTRLA_ENABLE; // enable device
    while(1);
    }

    Best regrads,

    Wenchuan

  • 0 Arm Employee Badge in reply to Wenchuan2018

    With the first code arrangement, it might be possible that your Non-secure world hasn't boot up and hence Non-secure Main stack pointer has not been initialized.