• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 883 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.

OSAL Questions

Boris Ioffe
Prodigy 170 points

Situation:

The project is SimpleBLEPeripheral derivative, using 1.3 stack and  USB-dongle configuration on actual cc2540USB. I setup msg generator that supplies data at given rate. My app reads from UART 10 messages a second, each message is 12 bytes.  I parse these into c-structs and blink RED led as an indication that a message is processed. Everything works, but I observed some things that don't seem logical to me.

Question 1:

UART business is extremly fast (can easily parse 1000 msg per sec if need be), until I try to wrap up my data into OSAL_Message form:

              canappEvent_t* pMsg =  (canappEvent_t*) osal_msg_allocate(sizeof(canappEvent_t) + 3 + msgLen);

As soon as I invoke osal_msg_allocate strange things become noticable. It takes the system about 5-7 seconds to produce first blink (it takes some time to process first message). I guess there is some sort of lazy initialization of OSAL facilities, but the code is available and it doesn't seem like osal_msg_allocate is doing much. If the app could parse thousands messages in 1 sec without OSAL memory allocation part, it hardly keeps up with 100s and it sometime falls into an inconsistent state and hangs the device.  I noticed that LED business doesn't work in the debug mode at all. IAR Debuger can be subject of entirelly different discussion, I am often puzzled with its results. So I am trying to get an idea by using peripherals attached to the chip.  Can I trust blinks? Maybe blinking mechanism is somehow affected by osal_mem_alloc?

Question 2:

Relevant code snippet.

             canappEvent_t* pMsg =  (canappEvent_t*) osal_msg_allocate(sizeof(canappEvent_t) + 3 + msgLen);
             pMsg->hdr.event = msgType;
             osal_memcpy(pMsg->data,&msgID,2);
             pMsg->data[2] = msgLen;
             osal_memcpy(pMsg->data+3,msgPayload,msgLen); // Line in question
             HalLedSet( 0x02,  0x02);

Even though the logic seems to be perfectly functional in accordance to IAR Debugger, the line in question has a weird effect.If commented out it blinks RED led (as intended), if uncommented it blinks GREEN LED. 100% reproducable. How can it be? 

Question 3:

Is there some analog to coredump when software crashes on a chip?

Looking forward to any input on this,

-B

           

  




  • 0
    TI__Mastermind 23440 points

    Hi Boris,

    Very interesting.

    1)
    Can't say I understand why it should take seconds.. It shouldn't.

    2)
    You should be able to trust blinks. However, are you sure that pMsg is not NULL in this case? It could be a problem on an embedded device to use dynamic memory allocation, at least to the extent that you seem to be using it.

    Read chapter 3.1.3 of the Software developers guide for info on how to check usage of the osal memory heap, and/or see comments in the OSAL_Memory.c file.

    Perhaps it could be more beneficial to use a static array to hold your incoming data and manage this yourself. Not ideal, but we are talking about

    3)
    If you are running in debug mode, you can pause the device and check stuff like the stack (view->stack), check the contents of various variables, the memory, etc. But nothing like a coredump. If you want, you could read out the entire memory content and somehow do an offline analysis, but the best bet is to do this live in debug mode. 

    Best regards,
    Aslak 

  • 0 in reply to Aslak N.
    Prodigy 170 points

    Thank you Aslak N.  I  read 3.1.3 and will try  OSALMEM_METRICS thing tonight to get a better perspective.  I

    see when my app gets into inconsistent state, it actually enters infinite loop in osal_msg_retrieve trying to call osal_int_disable.  Does it ring the a bell?   I am not good with machine assembly, can't tell whats going on.   

    If I were to implement some sort of watchdog task that could reset the device when it hangs, how would I approach it?  I am quite convinced that it is possible, because when my application hangs  LED continues flashing  FLASHING_COUNT number of times. 

    Is it possible to reboot the device programmatically ?

  • 0 in reply to Boris Ioffe
    TI__Mastermind 23440 points

    Hi Boris,

    Rings no bells. Do you mean osal_msg_receive? It also sounds strange that it will continue blinking if it enters an infinite loop.

    You can use OnBoard.c's reset function Onboard_soft_reset, or you may call HAL_SYSTEM_RESET() which will trigger a wdt reset immediately.

    If you wish to utilize the watchdog in a normal manner, see chapter 16 of the CC2540/41 System On Chip User Guide. 

    Best regards,
    Aslak 

  • 0 in reply to Aslak N.
    Prodigy 170 points

    Thank you for the answers.