• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 503 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5529: Odd semaphore behavior - Initialization parameter overridden at compile (binary -> counting)

Jacob Faseler
Prodigy 100 points

Part Number: MSP430F5529

I have a task that writes to the USCI A0 Tx Buffer, but only once another task has informed it through a semaphore that there's something relevant in a global queue:

This Semaphore is declared as a binary semaphore using a global Semaphore_Params:

And blocking behaves as expected in ROV:

However, when I look up the semaphore at address 0x323e, it's listed as a counting semaphore:

So far this hasn't caused any catastrophic issues, but I'd like to ensure that the primitive behaves in a predictable and well defined manner (aka, no sending blank or garbage messages to the device on the other end of the UART link) (aka, the way I told it to come into existence)

Any clues as to why this is happening or how to fix it would be much appreciated. 

also as a sidenote, how do I get the IInstance params to show up in ROV? I've made due without them, and I'm pretty sure it's something to do with the config, but I'm not sure which switch to flip.

Thanks in advance

  • 0
    TI__Guru* 96960 points

    Hi Jacob,

    I'm not sure what's going on. In the Semaphore.xs file, here is the code that determines the mode string to display in ROV.

        switch (obj.mode) {
        case Semaphore.Mode_COUNTING:
            view.mode = "counting";
            break;
        case Semaphore.Mode_BINARY:
            view.mode = "binary";
            break;
        case Semaphore.Mode_COUNTING_PRIORITY:
            view.mode = "counting (priority)";
            break;
        case Semaphore.Mode_BINARY_PRIORITY:
            view.mode = "binary (priority)";
            break;
    }

    The mode field in the middle of the Semaphore instance state structure. The other fields in that row look fine, so I doubt it is corruption. 

    Right before and after you construct the semaphore, can you look at ROV. Depending your TI-RTOS (SYS/BIOS) version, the unconstructed structure may show up as "unconstructed" or what looks like a bad instance. What version are you using?

    We don't "store" the passed in parameters. We keep the ones we need in the instance state (e.g. mode) and the others are just used during the create/construct.

    Todd

  • 0 in reply to ToddMullanix
    TI__Guru* 96960 points

    Any update on this? Did you get a chance to look at ROV before and after you constructed the semaphore?

    [10/30 Update: Marking this as TI Thinks Resolved due to no activity from original poster.]

**Attention** This is a public forum