更高优先级的中断也会破坏程序？

你好Patrik，
 
 
我们正在调查这个问题
 
 最好的祝福
 
 二万



以下为原文





Hello Patrik ,


We are investigating the issue

            Best Regards

                      Erwan

亲爱的二万，
 
 
 你能否给我一个提示，告诉我如何避免所描述的行为？我想过在UART接收过程中锁定其他中断。有没有办法锁定部分源代码（例如中断处理程序），它不能从另一个中断源中断？
 
 最好的祝福，
 帕特里克



以下为原文





Dear Erwan,


Can you already give me a hint how I can avoid the described behaviour? I thought about locking other interrupts during the UART receive process. Is there a way to lock parts of the source code (e.g. an interrupt handler) that it can not be interrupted from another interrupt source?

Best regards,
Patrik

你好Patrik，
 
 
抱歉回复晚了。
osalSysLockFromISR用于进入临界区域。
OSAL_USE_IRQ_PREEMPTION未定义（cf osal.h）
 
您可以尝试在项目中定义OSAL_USE_IRQ_PREEMPTION（平台组件）
但我们还没有测试过这种情况。
您尝试验证哪种速度？
 
 最好的祝福
 
 二万



以下为原文





Hello Patrik ,


Sorry for the late answer.
osalSysLockFromISR is used to enter to a critical zone.
OSAL_USE_IRQ_PREEMPTION is not defined (cf osal.h)

you can try to define OSAL_USE_IRQ_PREEMPTION in your project (Platform component)
but we have not tested this case.
Which speed do you try to validate ?

   best regards

                Erwan

你好，Erwan，
 
 
 我添加了一张显示UART数据丢失的图片（希望它有效）。 PIT中断每100ms上升一次，不能从UART RX中断中断。 UART波特率配置为460800。
 
 最好的祝福，
 帕特里克



以下为原文





Hello Erwan,


I have added a picture which shows the loss of UART data (hope it worked). The PIT interrupt raises every 100ms and can´t be interrupted from the UART RX interrupt. UART baud rate was configured as 460800.

Best regards,
Patrik

你好Patrik，
 
在默认的OSAL配置中，
PIT_0每1毫秒发生一次。 OSAL中的（设置为1000）
你试过''抢先的ISR''吗？
 
 最好的祝福
 
 二万



以下为原文







Hello Patrik ,

in the default OSAL Configuration,
PIT_0 happenned every 1 ms. (set to 1000) in OSAL
did you try ''Preemptable ISRs'' ?

  Best Regards

             Erwan

你好，Erwan，
 
 
 你的意思是设置OSAL_ENABLE_IRQ_PREEMPTION
 在osal.h中为TRUE？我从未尝试更改任何这些默认设置。
 
 
 
 对于默认配置中使用的PIT_0是什么？
 
 最好的祝福，
 帕特里克



以下为原文





Hello Erwan,


do you mean to set OSAL_ENABLE_IRQ_PREEMPTION
in osal.h to TRUE? I never tried to change any of theses default settings.

• /*===========================================================================*/
  

• /* Module pre-compile time settings.                                         */
  

• /*===========================================================================*/
  

• 
  

• /**
  

• 
  

• * @brief   Enables the interrupts during the ISRs execution.
  

• 
  

• */
  

• #if !defined(OSAL_ENABLE_IRQ_PREEMPTION) || defined(__DOXYGEN__)
  

• #define OSAL_ENABLE_IRQ_PREEMPTION          FALSE
  

• #endif
  

For what is PIT_0 used in default configuration?

Best regards,
Patrik

你好Patrick，
 
 
OSAL_ENABLE_IRQ_PREEMPTION
 可在OSAL组件上配置。 （配置级别）
默认为FALSE
 
 
 
 
PIT_0用于1ms刻度（os-less）
如果您认为Tick太重，可以尝试启用此功能。
 
 最好的祝福
 
 二万



以下为原文





Hello Patrick ,


OSAL_ENABLE_IRQ_PREEMPTION
  is configurable on OSAL Component. (Configuration level)
FALSE by default

• #if OSAL_ENABLE_IRQ_PREEMPTION
  

•         
  

• /* Allows preemption while executing the software handler.*/
  

•         
  

• wrteei      1
  

• #endif
  

•         
  

• /* Executes the software handler.*/
  

•         
  

• bctrl
  

• #if OSAL_ENABLE_IRQ_PREEMPTION
  

•         
  

• /* Prevents preemption again.*/
  

•         
  

• wrteei      0
  

• #endif
  

PIT_0 is used for 1ms tick (os-less)
If you think that the Tick is too heavy, you can try to enable this feature.

         Best Regards

                      Erwan

嗨帕特里克，
 
 
 你开始体验这个问题的波特率？
 
 乔瓦尼



以下为原文





Hi Patrik,


At which baud rate you start to experience the issue?

Giovanni

你好Giovanni，
 
 
 我尝试了三种波特率。它的工作速度为57,6kb / s，但不是460,8kb / s和128kb / s。
 
 最好的祝福，
 帕特里克



以下为原文





Hello Giovanni,


I tried three baud rates. It worked with 57,6kb/s, but not with 460,8kb/s and 128kb/s.

Best regards,
Patrik

你好！
 
 
 我再次遇到中断优先级问题（我从这个主题开始的问题从未解决过）。对于我目前的项目，我有一个非常高优先级的ISR，它必须抢占所有其他ISR。我在源代码中尝试了不同的优先级和设置，但我无法得到这种行为。
 因此，我为SPC56xL Discovery Board设置了一个小型演示项目（基于SPC5 Studio的SPC56EL OS-Less演示应用程序）
 在这个应用程序中，我集成了两个PIT定时器中断（channel1和channel2）。一个中断处理程序获得高优先级（8），另一个中断处理程序获得低优先级（2）。我预计，高优先级会优先于较低优先级。但优先级较高的中断仅在较低优先级未运行时执行。
 
 为了更好地理解，我附上了一张照片。在该图中，信号D6表示较低的先前中断，D4表示较高的先前中断。两个引脚设置在相应ISR的开头，并在ISR结束时清零。
 为了确保我的中断处理程序不是问题，我还使用SPC5应用程序配置创建了ISR，并激活了“'Preemptable ISRs''选项。尽管如此，我得到的结果与我自己的中断处理程序相同。
 
 这些是osal_cfg.c中的中断处理程序：
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 此外，osal_cfg.h中的OSAL_ENABLE_IRQ_PREEMPTION设置为TRUE
 
 描述行为的原因是什么？以及我如何配置我的系统以激活优先级较高的ISR抢占较低优先级？
 
 最好的祝福，
 帕特里克



以下为原文





Hello!


Once again, I have problems with interrupt priorities (the issue I started with this topic has never been solved). For my current project, I have a very high priority ISR which must preempt all other ISRs. I tried different priorities and settings within the source code, but I wasn´t able to get this behavior.
Therefore, I set up a small demo project for SPC56xL Discovery Board (based on SPC56EL OS-Less Demo Application from SPC5 Studio)
Within this application, I integrated two PIT timer interrupts (channel1 and channel2). One interrupt handler gets a high priority (8) and the other one a low priority (2). I expected, that the high priority preempts the lower priority. But the higher priority interrupt is only executed when the lower priority isn´t running.

For better understanding, I attached a picture. In this picture, signal D6 represents the lower prior interrupt, D4 the higher prior interrupt. The two pins are set at the beginning of the corresponding ISR and cleared at the end of ISR.
To be sure that it isn´t a problem with my interrupt handlers, I also created the ISRs using the SPC5 Application Configuration with activated ''Preemptable ISRs'' option. Nevertheless, I got the same result as with my ''own'' interrupt handlers.

These are the interrupt handlers in osal_cfg.c:

• /*===========================================================================*/
  

• /* Module ISRs.                                                              */
  

• /*===========================================================================*/
  

• 
  

• /*
  

• 
  

• * ISR_1 ISR function (vector 61).
  

• 
  

• */
  

• OSAL_IRQ_HANDLER(vector61) {
  

• 
  

•   
  

• OSAL_IRQ_PROLOGUE();
  

• 
  

•   
  

• /* ISR code here.*/
  

•   
  

• Task_10us();
  

• 
  

•       
  

• /* Resets the PIT channel 0 IRQ flag.*/
  

•    
  

• PIT.CHANNEL[2].TFLG.R = 1;
  

• 
  

•   
  

• OSAL_IRQ_EPILOGUE();
  

• }
  

• 
  

• /*
  

• 
  

• * ISR_2 ISR function (vector 60).
  

• 
  

• */
  

• OSAL_IRQ_HANDLER(vector60) {
  

• 
  

•   
  

• OSAL_IRQ_PROLOGUE();
  

• 
  

•   
  

• /* ISR code here.*/
  

•   
  

• Task_100us();
  

• 
  

•       
  

• /* Resets the PIT channel 0 IRQ flag.*/
  

•   
  

• PIT.CHANNEL[1].TFLG.R = 1;
  

• 
  

•   
  

• OSAL_IRQ_EPILOGUE();
  

• }
  

• 
  

• /*===========================================================================*/
  

• /* Module exported functions.                                                */
  

• /*===========================================================================*/
  

• 
  

• /**
  

• 
  

• * @brief   Generated initialization code.
  

• 
  

• *
  

• 
  

• * @special
  

• 
  

• */
  

• void osal_cfg_init(void) {
  

• 
  

•   
  

• INTC_PSR(OSAL_VECTOR_ISR_1)=INTC_PSR_ENABLE(INTC_PSR_CORE0, 8);
  

•   
  

• INTC_PSR(OSAL_VECTOR_ISR_2)=INTC_PSR_ENABLE(INTC_PSR_CORE0, 2);
  

• }
  

• 
  

• /** @} */
  

Additionally, OSAL_ENABLE_IRQ_PREEMPTION in osal_cfg.h is set TRUE

• #if !defined(OSAL_ENABLE_IRQ_PREEMPTION)
  

• #define OSAL_ENABLE_IRQ_PREEMPTION          TRUE
  

• #endif
  

What is the reason for the described behavior? And how I have to configure my system to activate preemption of lower priorities by higher priority ISRs?

Best regards,
Patrik

你好Patrik，
 
 
非常奇怪，在SPC56xL上，默认情况下会激活抢占和嵌套IRQ。
我将在周四查看这个问题。
你可以在生成中断时通过调试器检查你的CPR吗？
 
 
你能试试INTC_EOIR（INTC_PSR_CORE0
）= 2中断处理程序结束前的两个）？
你能把你的申请寄给我吗？
 
 最好的祝福
 
 二万



以下为原文





Hello Patrik ,


Very strange, on SPC56xL , the preemption and nesting IRQ are activated by default.
I will check this issue this thursday.
could you check your CPR by debugger when the interruption is generated ?

• #define INTC_CPR(n)       (*((volatile uint32_t *)(INTC_BASE + 8 + ((n) * sizeof (uint32_t)))))
  

could you try  INTC_EOIR(INTC_PSR_CORE0
)  = 0 before the end of the interruption handler the two) ?
Could you send me your application ?

   Best regards

                              Erwan

你好，Erwan，
 
 
 我检查了INTC_CPR_PCR0寄存器值。产生中断时，寄存器显示相应中断的优先级（8或2）。
 
 包括INTC_EOIR（INTC_PSR_CORE0）= 0;
 在中断处理程序结束时对行为没有影响。
 
 您可以在此帖子附带的zip文件中找到该项目。
 
 最好的祝福，
 帕特里克



以下为原文





Hello Erwan,


I checked INTC_CPR_PCR0 register value. When interrupt is generated, the register shows the priority level of corresponding interrupt (8 or 2).

Including INTC_EOIR(INTC_PSR_CORE0) = 0;
at the end of interrupt handler has no effect on behavior.

You can find the project within the zip file attached to this post.  

Best regards,
Patrik

谢谢 ;-）
 
 
我们今天会检查



以下为原文





Thanks ;-)


We will check today

你好Patrik，
 
 
这个问题已被复制。
 
在强迫ivor.s，它正在工作。
 
 
 
 
你能试试这段代码''ivor.s''吗？
编译开关没有考虑在内。
我正在检查SPC5studio中的平台配置
 
 最好的祝福
 
 二万



以下为原文





Hello Patrik ,


The problem has been reproduced .

in forcing in ivor.s, it is working.

• /* Allows preemption while executing the software handler.*/
  

• 
  

• wrteei      1
  

• 
  

• /* Executes the software handler.*/
  

• 
  

• bctrl
  

• 
  

• /* Prevents preemption again.*/
  

• 
  

• wrteei      0
  

Could you try this piece of code ''ivor.s'' ?
The compilation switch was not taken in account.
i am checking the platform configuration in SPC5studio

Best Regards

                     Erwan

你好，Erwan，
 
 
 这就是原因。改变ivor.s后它起作用了。谢谢你的快速帮助！
 
 最好的祝福，
 帕特里克



以下为原文






Hello Erwan,


That was the reason. After changing ivor.s it works. Thanks for your fast help!

Best regards,
Patrik

你好Patrik，
 
我们已提交错误报告以进行此更正。
对此问题再次感到抱歉
 
 最好的祝福
 
 二万



以下为原文







Hello Patrik ,

we have submitted an Error Report to have this correction.
sorry again for the issue

   Best regards

              Erwan