• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 40 subscribers
  • Views 74 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.

CC3301MOD: Require information for program crash on routine "FwEvent_irq_handler" and "init_device"

YogeshG
Prodigy 230 points

Part Number: CC3301MOD
Other Parts Discussed in Thread: CC3301

Hi All,

We have ported TI SDK for CC3301 on STM32F412ZG.

SDK is using Free RTOS version 10.4.3 and our code base is using 7.0.1

While executing code we observed code creashes on following routine.

1) "FwEvent_irq_handler" in "fw_event_if.c"

  • In this routine, program crashes on executing "trnspt_RequestSchedule(pFwEvent->uContextId, TRUE)"

2) "int32_t init_device(uint32_t commandsEventsSizeBTL,uint32_t commandsEventsSize)" 

  • Internally it call "cmd_Send", which internally call "trnspt_RequestSchedule(cmdCB->clientID, 0);"

Our queries:

1) "init_device" internally handling "ctrlCmdFw_ContainerDownload", "ctrlCmdFw_DownloadIniParams", etc. 

  • We understood while porting to STM32, we need to use this function without any change. Plz confirm
  • Please provide some information about various functionality handled by this function.

2) What might be the reason for program crashes on "trnspt_RequestSchedule".

  • Internally "trnspt_RequestSchedule" using "osi_SyncObjSignalFromISR", "osi_SyncObjSignal" and "pTransport->aClientPending[uClientId]". 
  • What exactly "osi_SyncObjSignalFromISR", "osi_SyncObjSignal" functions are doing and when it will crash?
  • This routine part of "osi_freertos.c". While porting to STM32 do we need to handle any point?
  • We found it crashes on below routine of Free RTOS.
  • Does it having any relation to Free RTOS version we are using 7.0.1 instead 10.4.3

Thanks...

  • 0
    TI__Guru 65705 points

    Hi,

    1. this functions go chunk by chunk and download the RAM bootloader, firmware and INI params to the chip. Generally, you do not have to touch those as these are platform/OS independent. Maybe STM is configured in such a way that the memory change the order, e.g. endianity
    2. there is one main task which is the transport task. some clients register to this task (via trnspt_RegisterClient) and when they want to be served, they simply request a schedule. Some of these client are the event task, command task, TX and timer. So in your case you get an interrupt, it requests a schedule from the trasport thread via trnspt_RequestSchedule() which should get to the transport task. In the implementation, to signal between tasks (so the interrupt context remains short), we use a signal object. This signal is waited on the transport task and specifically in while loop of trnspt_Task(). Then, the task is calling the callback function that was registered during init. This is also not something you need to port but you need to make sure that in your OS, you have semaphores, signals, queues, etc. The adaptation is done in osi_freertos.c file. Maybe the freeRTOS version is too old, I am not sure.

    Shlomi