谁发现micrium在stm32上移植的ucos有bug？

hzwwqq

谁发现micrium在stm32上移植的ucos有bug？ [复制链接]

各位大侠，我是在micrium网站上下载了其在stm32f10x上的ucos移植程序。发现在这个程序中如果各个中断的优先级都设为0，那么任务调度都很正常，我创建了9个任务。一旦更改这些优先级，如，分别设为 2，3，那么程序运行一段时间后就会死机。有人说在OSStartHighRdy，OSPendSVCHandler,OSPendSVCHandlerNoSave,函数有bug,请问是不是真的？本人初学ucos，一点头绪都没有，还请大虾指点啊。

shenmon@126.com

250200729

自己顶一个
个人认为，micrium应该不会留下这么大的bug吧。但是我在使用中确实碰到了这个问题，搜遍了网上认为移植成功的ucos代码，发现这几个函数的代码是一样的。在st推出的几块开发板的资料中，比较了这几个函数，也没有什么区别。

amdsempron

你的问题我想应该存在。
我以前在51系统上移植的操作系统，开发的时候正常，但是长期运行发现死机，当时找了好长时间。后来偶尔把优先级别都改成0，中断的优先级别是改成芯片的现有的优先级别后，系统很稳定。

我虽然没有在STM32上试过，没有改优先级。（CPU速度快，还用DMA，没有必要改用中断优先级）
你说的现象，我认为是存在。
顺便说，不改优先级，我认为系统是很稳定的

嘉人

                                 中断是可以设置优先级的。设置优先级会导致高优先中断抢占，所以要把主堆栈(MSP,不是ucos的任务堆栈)设置大点，以防止抢占时会产生堆栈溢出。

nebulabhm

你说的是这个文件吧：
LR_IROM1 0x08000000 0x0007ffff                                                                         ;; Load region
{
    ER_IROM1 0x08000000        0x0807ffff
    {
        vectors.o (VECT, +First)
        init.o (INIT)
        * (+RO)
    }

    RW_IRAM1 0x20000000  0x0000FC00        ;;4C00
    {
        * (+RW,+ZI)
    }                                                           ;; The following declarations select the "two region model" ;
                                                                ;; A default __user_initial_stackheap() will be used        ;
    ARM_LIB_HEAP  0x2000F700 EMPTY  0x00000200   {}
    ARM_LIB_STACK 0x2000FB00 EMPTY -0x00000200   {}
}

suaimei

                                 这个可以有！

succeedzcs

                                 请升级到2.88版本

nightelf

                                 中断优先级都设置成0，不存在中断嵌套，需要的主堆栈也就会小一些。而更改了中断优先级，尤其是设置了抢占优先级，就可能有中断嵌套的情况发生，需要的主堆栈就会大一些，如果主堆栈的空间不够，就会死机了。

cometapple

不知道楼主用的哪个ARM核，如果是ARM7TDMI，那么该内核是不支持硬件中断嵌套的，所以也不会出现楼上所说的情况，如果是CORTEX-M3内核，那么2.86确实有bug，请参考https://bbs.eeworld.com.cn/icview-95426-1-1.html

xushangjin

引用其他一个帖子的原文：

官方（micrium）的例子(stm32+ucosii2.86)不太好，不能中断嵌套，所有中断必须在同一优先级别，官方例子都是0，主要是在双堆栈指针使用上有问题
用下面两段代码替换就没问题了，也不存在原来有人说使用不同优化级别编译会死机的问题

OSStartHighRdy
    LDR     R0, =NVIC_SYSPRI2                                   ; Set the PendSV exception priority
    LDR     R1, =NVIC_PENDSV_PRI
    STRB    R1, [R0]

    ;MOVS    R0, #0                                              ; Set the PSP to 0 for initial context switch call
    ;MSR     PSP, R0
   
    MRS     R0, MSP
    MSR     PSP, R0
   
    MRS     R0, CONTROL
    ORR     R0, R0, #0x02
    MSR     CONTROL, R0
   
    LDR     R1, __OS_TCBCur
    MRS     R0, PSP
    SUBS    R0, R0, #0x24
    STR     R0, [R1]
   
   
    LDR     R0, __OS_Running                                    ; OSRunning = TRUE
    MOVS    R1, #1
    STRB    R1, [R0]

    LDR     R0, =NVIC_INT_CTRL   ; Trigger the PendSV exception (causes context switch)
    LDR     R1, =NVIC_PENDSVSET
    STR     R1, [R0]
   
    CPSIE   I              ; Enable interrupts at processor level

OSStartHang
    NOP
    B       OSStartHang          ;Should never get here






OSPendSV
    MRS     R0, PSP                                             ; PSP is process stack pointer
    ;CBZ     R0, OSPendSV_nosave                                 ; skip register save the first time

    SUBS    R0, R0, #0x20                                       ; save remaining regs r4-11 on process stack
    STM     R0, {R4-R11}

    LDR     R1, __OS_TCBCur                                     ; OSTCBCur->OSTCBStkPtr = SP;
    LDR     R1, [R1]
    STR     R0, [R1]                                            ; R0 is SP of process being switched out

                                                                ; at this point, entire context of process has been saved
OSPendSV_nosave
    PUSH    {R14}                                               ; need to save LR exc_return value
    LDR     R0, __OS_TaskSwHook                                 ; OSTaskSwHook();
    BLX     R0
    POP     {R14}

    LDR     R0, __OS_PrioCur                                    ; OSPrioCur = OSPrioHighRdy;
    LDR     R1, __OS_PrioHighRdy
    LDRB    R2, [R1]
    STRB    R2, [R0]

    LDR     R0, __OS_TCBCur                                     ; OSTCBCur  = OSTCBHighRdy;
    LDR     R1, __OS_TCBHighRdy
    LDR     R2, [R1]
    STR     R2, [R0]

    LDR     R0, [R2]                                            ; R0 is new process SP; SP = OSTCBHighRdy->OSTCBStkPtr;
    LDM     R0, {R4-R11}                                        ; restore r4-11 from new process stack
    ADDS    R0, R0, #0x20
    MSR     PSP, R0                                             ; load PSP with new process SP
    ;ORR     LR, LR, #0x04                                       ; ensure exception return uses process stack
    BX      LR

工作环境STM32-Cortex核，MDK编译。不知是否存在这个问题？

atghjiq

To 电子乌托邦:
我是楼主，这个帖子我搜到了，也进行了尝试，更改之后，系统直接跳转的异常HardFaultHandler.具体原因还没有查明。感谢大家的帮忙，期待更详细的解答

yql1980

To  zengfan155：
我用的是cortex-m3内核+2.86,看了你所说的bug，感觉和我现在的问题没有太大关系。
To yugen：
对于MSP，我已经尝试过改的非常大，仍然是运行一段时间后就死机。
感谢大家的帮助，这个问题现在还没有解决

pxjinxing

                                 估计可能是某个任务的堆栈（PSP）不够用了。

wangtong0819

                                 LZ，听了你12楼说的，我试了一下，并没有你说的会发生硬件错误的情况。

houyb

                                 已经有2个人说了让你升级到v2.88,楼主你咋就听不进去呢

morse

                                 确定和版本有关系吗

yppah2007

To 电子乌托邦:
你好！谢谢你的回复。能不能把你的移植的文件发给我一下？谢谢
我的邮箱是
shenmon@126.com

chengj

已经有2个人说了让你升级到v2.88,楼主你咋就听不进去呢

我当第三个

rtl84723

                                 我当四个。这个问题当初把我害惨了

taowosuotu

                                 鉴于楼上四位大侠的意见，今天升级到了2.88，仍然是设置优先级后，运行一段时间，程序进入hardfault.