Giter Club home page Giter Club logo

Comments (6)

mtm0183 avatar mtm0183 commented on May 27, 2024

Any chance the USART2 interrupt is configured as a non-kernel aware interrupt? The call to OS_RdyListRemove() in os_time.c is called inside a CPU_CRITICAL_ENTER/EXIT block which means the USART2 interrupt shouldn't have occurred until after CPU_CRITICAL_EXIT(). Unless the CPU critical macros are configured incorrectly.

from uc-os3.

OmicronB avatar OmicronB commented on May 27, 2024

It's possible. I'm new to ucos. I used the BSP for the STM32F105 that came with the TCP/IP book for STM32. I had to tweak it here and there to make it work with the current code. I didn't change anything interrupt related though. I am also seeing this crash with the ethernet rx interrupt, so it's not specific to the UART. Any pointers where I need to look to check the configuration of the CPU critical macros or where I can check that the interrupts are correctly set up as kernel aware?

from uc-os3.

mtm0183 avatar mtm0183 commented on May 27, 2024

For an ST port, the CPU macros should be ok. cpu_cfg.h sets the CPU_CFG_KA_IPL_BOUNDARY. Make sure any RTOS-aware interrupts are in the KA boundary.

from uc-os3.

OmicronB avatar OmicronB commented on May 27, 2024

Curiously the interrupt priorities are not set in the BSP code. I see this for example:

BSP_IntVectSet(BSP_INT_ID_USART2, BSP_Ser_ISR_Handler);
BSP_IntEn(BSP_INT_ID_USART2);

Seems the priorities are left at their defaults. If I add a line to set the priority to something that is in the KA boundary:

BSP_IntVectSet(BSP_INT_ID_USART2, BSP_Ser_ISR_Handler);
BSP_IntPrioSet(BSP_INT_ID_USART2, 15, CPU_INT_KA);
BSP_IntEn(BSP_INT_ID_USART2);

I run into another issue. At startup I'm writing debug output to USART2. At some point it is pending on a semaphore, I assume it is waiting for the TX queue to drain. When it does this the code hangs in the function "OS_PendListInsertPrio" in os_core.c. It loops forever on line 1335. The element pointed to by p_tcb_next has this contents:

p_tcb_next = 0x2000B534 -> (
  StkPtr = 0x2000B40C,
  ExtPtr = 0x0,
  StkLimitPtr = 0x2000A6CC,
  NamePtr = 0x080179C0,
  NextPtr = 0x0,
  PrevPtr = 0x0,
  TickNextPtr = 0x20007CA8,
  TickPrevPtr = 0x0,
  StkBasePtr = 0x2000A534,
  TaskEntryAddr = 0x08014EFD,
  TaskEntryArg = 0x0,
  PendNextPtr = 0x2000B534,
  PendPrevPtr = 0x2000B534,
  PendObjPtr = 0x20000250,
  PendOn = 6,
  PendStatus = 0,
  TaskState = 2,
  Prio = 7,
  BasePrio = 7,
  MutexGrpHeadPtr = 0x0,
  StkSize = 1024,
  Opt = 3,
  TS = 26460899,
  SemCtr = 0,
  TickRemain = 0,
  TickCtrPrev = 0,
  TimeQuanta = 0,
  TimeQuantaCtr = 100,
  MsgPtr = 0x0,
  MsgSize = 0,
  MsgQ = (InPtr = 0x0, OutPtr = 0x0, NbrEntriesSize = 0, NbrEntries = 0, NbrEntriesMax = 0),
  MsgQPendTime = 0,
  MsgQPendTimeMax = 0,
  RegTbl = (0),
  FlagsPend = 0,
  FlagsRdy = 0,
  FlagsOpt = 0,
  SuspendCtr = 0,
  CPUUsage = 662,
  CPUUsageMax = 662,
  CtxSwCtr = 426,
  CyclesDelta = 2361,
  CyclesStart = 26461766,
  CyclesTotal = 195551,
  CyclesTotalPrev = 477117,
  SemPendTime = 0,
  SemPendTimeMax = 0,
  StkUsed = 103,
  StkFree = 921,
  IntDisTimeMax = 304,
  SchedLockTimeMax = 0,
  DbgPrevPtr = 0x200009CC,
  DbgNextPtr = 0x20007E0C,
  DbgNamePtr = 0x08016F34)

The issue here is that the member field PendNextPtr is pointing to itself hence the loop never terminates.

The stack looks like this at this point:

-000|OS_PendListInsertPrio(:p_pend_list = 0x20000258, :p_tcb = 0x2000B534)
    |  p_pend_list = 0x20000258
    |  p_tcb = 0x2000B534
    |  prio = 7
    |  p_tcb_next = 0x2000B534
-001|OS_Pend(:p_obj = 0x20000250, p_tcb = 0x2000B534, :pending_on = 6, :timeout = 0)
    |  p_obj = 0x20000250
    |  p_tcb = 0x2000B534
    |  pending_on = 6
    |  timeout = 0
-002|OSSemPend(p_sem = 0x20000250, timeout = 0, opt = ?, p_ts = 0x0, p_err = 0x2000B486)
    |  p_sem = 0x20000250
    |  timeout = 0
    |  opt = ?
    |  p_ts = 0x0
    |  p_err = 0x2000B486
    |  cpu_sr = 64
-003|BSP_OS_SemWait(:p_sem = 0x20000250, :dly_ms = 0)
    |  p_sem = 0x20000250
    |  dly_ms = 0
    |  err = 2048
    |  dly_ticks = 0
-004|BSP_Ser_WrByteUnlocked(:c = 83)
    |  c = 83
-005|BSP_Ser_WrByte(c = ?)
    |  c = ?
-006|putchar(ch = ?)
    |  ch = ?
-007|log_info_str(:str = 0x0801707C)
    |  str = 0x0801707F
-008|Mem_OutputUsage(out_fnct = 0x08013055, :p_err = 0x2000B524)
    |  out_fnct = 0x08013055
    |  p_err = 0x2000B524
    |  str = (16, 16, 16, 16, 17, 17, 17, 17, 181, 78)
    |  p_seg = 0x20007AC0
    |  cpu_sr = 0
    |  rem_size = 7128
-009|main_task(p_arg = ?)
    |  p_arg = ?
    |  err_os = OS_ERR_NONE
    |  err_lib = LIB_MEM_ERR_NONE

from uc-os3.

OmicronB avatar OmicronB commented on May 27, 2024

I've debugged this new issue a bit further. The BSP has this function:

void  BSP_Ser_WrByteUnlocked (CPU_INT08U c)
{
    USART_ITConfig(USART2, USART_IT_TC, ENABLE);
    USART_SendData(USART2, c);
    BSP_OS_SemWait(&BSP_SerTxWait, 0);
    USART_ITConfig(USART2, USART_IT_TC, DISABLE);
}

The function BSP_OS_SemWait is just a wrapper for OSSemPend:

CPU_BOOLEAN  BSP_OS_SemWait (BSP_OS_SEM  *p_sem,
                             CPU_INT32U   dly_ms)
{
    OS_ERR      err;
    CPU_INT32U  dly_ticks;


    dly_ticks  = ((dly_ms * DEF_TIME_NBR_mS_PER_SEC) / OSCfg_TickRate_Hz);

    OSSemPend((OS_SEM *)p_sem,
              (OS_TICK )dly_ticks,
              (OS_OPT  )OS_OPT_PEND_BLOCKING,
              (CPU_TS  )0,
              (OS_ERR *)&err);

    if (err != OS_ERR_NONE) {
       return (DEF_FAIL);
    }

    return (DEF_OK);
}

What I see is that at some point the wait returns but the current task is still in the pending list of the semaphore. The next time the function is called the current task is added to the list again and I think this causes the circular reference.

But the question is: how can OSSemPend return with a result of OS_ERR_NONE without removing the current task from the pending list of the semaphore? Curiously this always happens at the exact same point in the execution so it seems to be deterministic.

from uc-os3.

OmicronB avatar OmicronB commented on May 27, 2024

I believe I found the issue. I was using the function Mem_OutputUsage to print the memory usage. This function internally calls CPU_CRITICAL_ENTER() and from within this critical region calls the output function which in turn results in the BSP_Ser_WrByteUnlocked function to eventually be called.

I feel this is a bug in Mem_OutputUsage. It should not call the output function from within a critical region.

from uc-os3.

Related Issues (17)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.