Messaging Framework pend not receiving message if wait time is too short

 Hello,

I'm using the messaging framework to communicate between my USB receive thread (reads commands from PC) and my measurement thread. One of the commands starts a measurement progress that will measure a value everytime the while-loop of the measurement thread is passed. See following diagram:

while(1)
{
     if(!g_sf_message.p_api->pend(g_sf_message.p_ctrl,&meas_thread_message_queue,&pHeader,1))
     {
          parse message and react
          result = g_sf_message.p_api->bufferRelease(g_sf_message.p_ctrl, (sf_message_header_t *) message, SF_MESSAGE_RELEASE_OPTION_NONE);
     }
     if(balance_mode_active)
     {
          measure weight
     }
     tx_thread_sleep(1);
}

As stated, one of the commands sets the bool balance_mode_active to true. measure weight takes approximately 200ms. The starting message always comes through. However, the stop message isn't received with the pend with 1ms timeout. When I set the timeout to 200 it works. I have configured the ThreadX with source to 1000 ticks/second. so I need a timeout of 200ms for pending on the message framework. This is way too much, since the measurement thread is blocked during that time.

I have tried to set the SF_MESSAGE_PRIORITY_HIGH, changed the thread priorities in every order I can imagine and it still won't work with a pend with 1ms timeout.

The USB thread has a priority of 6 and the measurement thread a priority of 5. With breakpoints I have checked that the message for the Messaging Framework is sent from the USB Thread with a return code of 0.

Does anyone have an idea how to solve this problem? If the messaging framework doesn't work with 1ms wait time, is there another ThreadX construct I can use for this communication?

Regards,

Christoph

  • Hi Christoph-
    Have you used the Messaging Framework module guide to help construct your program architecture? Are you doing something different from the flow used in that project?

    Warren
  • In reply to WarrenM:

    www.renesas.com/.../keyword-search.html is the location of the module guide...

  • In reply to WarrenM:

    Hi Warren,
    yes I have read this document and as far as I know, I implemented the framework as it should be. The first message is always working, when I don't measure the weight, both messaged work with 1ms pend time as it should.
    As soon as the weight measurement is implemented, the message is not recognized anymore. The measurement is done over an external device connected through uart. It consists of sending a command and waiting a certain time until the answer has arrived or give a timeout error if no answer has arrived. The UART is configured with 9600baud, 8N1, data is received through a callback function with a semaphore being put when all the data has arrived.

    Can this have any influence on the Messaging FW? Is there a documentation about recommended thread priorities for the messaging FW to work correctly? In the document and zip file you mentioned, all threads have priority 1 which is unrealistic in a real application.

    Regards,

    Christoph

  • In reply to cbismark:

    Hi Christoph-
    I don't know of any doc that recommends thread priorities for the messaging framework specifically. Here is a good general guideline however: renesasrulz.com/.../transitioning-to-threadx-managing-thread-priorities

    How are you implementing the wait during the measure function? Is it possible this is impacting the messaging framework somehow? Do you spend a lot of time in the callback?

    Warren
  • In reply to WarrenM:

    Good morning Warren,

    I handled the callback like an interrupt, as short as possible:

    void uart5_callback(uart_callback_args_t *p_args)
    {
    switch(p_args->event)
    {
    case UART_EVENT_RX_CHAR:
    case UART_EVENT_BREAK_DETECT:
    TEL[TEL_ptr++]=(UCHAR)p_args->data;
    if(TEL[TEL_ptr-1]==0x0D)
    {
    tx_semaphore_put(&g_semaphore_uart5);
    }
    break;
    case UART_EVENT_TX_COMPLETE:
    tx_semaphore_put(&g_semaphore_uart5_tx_complete);
    break;
    default:
    break;
    }
    }

     

    The timeout is implemented as follows:

    unsigned short wait_for_answer(void)
    {
        USHORT result=1;
        new_weight_received=false;
        ldu_ok=false;
        result = tx_semaphore_get(&g_semaphore_uart5,TX_TIMER_TICKS_PER_SECOND*3);            //wait 3s for answer
        if(!result)
        {
            New_Telegram1();
        }
        TEL_ptr=0;
        return result;
    }

    Basically, I wait for the "telegram received"-semaphore with a timeout of 3s. Of course, when the external device is connected, it only takes a few ms to receive the answer and get the semaphore. The function I am calling in my main loop as mentioned in the first post:

    unsigned short get_netto(float *weight)
    {
        unsigned short errorcode=0;
        SendStringLDU("GN");                            
        if (wait_for_answer())errorcode=ldu_noanswer;
        if (!new_weight_received) errorcode=ldu_noweight;
        if(!errorcode)*weight=weight_n;
        return errorcode;
    }

    The bool "new weight received" is being set in the New_Telegram1()-function, if I ask the external device for a weight and also get one. This function is blocking, because wait_for_answer() blocks in the semaphore-get command.

    Is it possible that the processor doesn't have enough background time to actually send the message and when I pend to 200ms, in the background the message can be sent?

    Regards,

    Christoph

  • In reply to cbismark:

    Are there any news on this problem? Anymore ideas, what might be going on?
  • In reply to cbismark:

    Here is an update: I switched the messaging framework for event flags and with them it works even with a wait time of 1ms. Now this indicates that the messaging framework doesn't behave as expected.

     

    EDIT: Event Flags also work with TX_NO_WAIT.