What is the best practice for code "Critical Sections" using the MX6 Baremetal SDK 1.1 ?

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the best practice for code "Critical Sections" using the MX6 Baremetal SDK 1.1 ?

Jump to solution
561 Views
nathanpalmer
Contributor IV

I am porting some code to the MX6SL and it uses critical sections to prevent clashes between ISR / Main shared memory.  I would like to use the most effective mythology for implementing the functionality on the MX6 and try to use code from the SDK 1.1 if possible.

The existing code very simply reads CPSR to a local (stack) variable and then disables global interrupts.  (this takes 2 ARM asm instructions).  After the critical section a second macro restores the CPSR.  This has worked well and I could probably do the same thing on the MX6 (cortex A9).  However, I am now using the void IRQ_HDLR(void) provided by the SDK and it includes calls to the GIC which is new to me.  I have read the Datasheet on it, but I was thinking that there may be some gotchas involved in disabling interrupts the way I was before and using this new IRQ_HDLR. 

Specifically, I had a problem when I tried to call arm_set_interrupt_state(false) from an ISR.  The code started executing functions in cortex_a9.s that I never called.

My question is:

Is there a "Critical Section" model that is compatible with the Bare metal SDK?  Also, can I use the GIC to make Peripheral Specific Critical sections? or are the enable_interrupt(..)/disable_interrupt(..) GIC functions not suitable to be used in that way (maybe not thread safe/reenterant themselves) ?

Labels (2)
0 Kudos
1 Solution
140 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi Nathan,

As I understand the way you are disabling interrupts are disabling the global interrupts which is the most used method for critical sections.

The disable_interrupt and enable_interrupt functions of the SDK just enable or disable an specific interrupt.

The way I understand is that the GIC is flexible  and you can design your handler to be reentrant, non-reentrant with priorities or not.

It seems that the SDK allows nested interrupts and which might be an issue for data coherence. Therefore I would stick with your method of disabling the global interrupts.

Best Regards,

Alejandro

View solution in original post

0 Kudos
1 Reply
141 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi Nathan,

As I understand the way you are disabling interrupts are disabling the global interrupts which is the most used method for critical sections.

The disable_interrupt and enable_interrupt functions of the SDK just enable or disable an specific interrupt.

The way I understand is that the GIC is flexible  and you can design your handler to be reentrant, non-reentrant with priorities or not.

It seems that the SDK allows nested interrupts and which might be an issue for data coherence. Therefore I would stick with your method of disabling the global interrupts.

Best Regards,

Alejandro

View solution in original post

0 Kudos