Behavior of eventflags

We are using eventflags to control our uart communications in our S5 and S3 applications. We are using the HAL driver, not the framework. The receive uart callback assembles a packet using the SLIP protocol, and when the final END char is received to complete the packet, the callback sets the eventflag for that uart.  The command processor runs in a different thread and blocks on a get() call to that eventflag.  After processing the command, the command processor thread clears the eventflag, and it goes back to blocking until the callback signals that another complete packet was received.

I'd like to understand how the eventflags are supposed to behave.  E.g. if the callback were to, say, set the eventflag multiple times without it being cleared in between, would that cause a problem?  Would it then have to be cleared the same number of multiple times?  The ExpressLogic documentation doesn't indicate that there is any 'counting' similar to what happens with a mutex or semaphore, which should mean that I should be able to set the eventflag 25 times without ill effect, and clear it once.  I'd appreciate any insights others may have.

tom

  • Hi tom,

    >I'd like to understand how the eventflags are supposed to behave. E.g. if the callback were to, say, set the eventflag multiple times without it being cleared in between, would that cause a problem?
    Event flags is a bitset.
    Therefore even if you set them multiple times, each bit is set only once.
    You should use semaphore.

    >After processing the command, the command processor thread clears the eventflag, and it goes back to blocking until the callback signals that another complete packet was received.

    Callback thinks one packet regardless of number of received packets.

    Therefore blocking until the another complete packet is received is naturally.

  • Sorry, you mean event flags, don't you?
    I guess the manual explains The following contents.
    Each event flag is a bit, and set/clear operaron is logical AND/OR.
    So no matter how many times you set it, it counts only once.

    ------------------------------------------------------
    Event Flags

    Event flags provide a powerful tool for thread synchronization.
    Each event flag is represented by a single bit. Event flags are arranged in groups of 32.
    Threads can operate on all 32 event flags in a group at the same time. Events are set by tx_event_flags_set and are retrieved by tx_event_flags_get.
    Setting event flags is done with a logical AND/OR operation between the current event flags and the new event flags. The type of logical operation (either an AND or OR) is specified in the tx_event_flags_set call.
    ------------------------------------------------------
  • The reason for this question is that about a year ago, I experienced uart hangs during flash update. The rest of the threads ran fine, but the command processor thread would no longer run. The only way to recover it was to perform a close() and open() on the affected uart channel. I started to pursue it with Renesas support and at one point got this response from a Renesas engineer named Cheng Ping. This was ticket 175378, which I opened 19Sep2018.

    "Is it possible that a new complete packet is received via callback before the last response packet is transmitted? In this case, the event flag will be set again before it's cleared properly, and this operation is not what we expect. Therefore, I will prefer to use semaphore to count the number of received packet in the block pool, and the command processor thread starts the process in case the number of received packet is not zero. "

    So Cheng Ping says that multiple SET operations, without matching CLEARs, is an "unexpected" operation. What that means, I have no idea, but he suggests that it is a bad thing.

    Would Renesas please comment on this?
  • In reply to tclong:

    Hi tclong-
    Reviewing renesasrulz.com/.../transitioning-to-threadx-event-flags
    and the Express Logic Thread-X manual on Event Flags (page 82) shows no notice that Event Flags can't be set multiple times without issues. Given that these are bit operations I don't see how the register would have any 'memory' of the previous state after the operation... Perhaps Cheng Ping was thinking of a different flag or miss-understood how it operated.

    Let us know if you still have concerns and we can get someone from Express Logic to verify 'officially'...