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.

IWR6843ISK: SOC_softReset freezing app when RTOS Timer is in use

Part Number: IWR6843ISK

Hello community,

I am currently working on IWR6843ISK board with a custom app based on OOB lab from MMWave industrial Toolbox 4.7.0. My SDK version is 03.05.00.04, compiler ti-cgt-arm_16.9.6.LTS.

I need to reset my app when asked. I use "SOC_softReset(gMmwMssMCB.socHandle, &errCode)" in my main.c which works fine when I only use CLI_task.

But when I create a RTOS Timer at 1ms, this same function never exit and my app freeze. 

I tested with a watchdog , and my app resets successfully. I don't understand.

I tried adding HwiP_disable() before SOC_softReset but it also failed.

Here is a snippet: 

void MmwDemo_Reset()
{
int32_t errCode;

//Reset Software -- this part fails
if (!SOC_softReset(gMmwMssMCB.socHandle, &errCode))
MmwDemo_writeLog("Error: Warm Soft Reset failed with error %d\n", errCode);

//this part works

/*Watchdog_Handle watchdogHandle = NULL;
Watchdog_Params watchdogParams;

// Initialize the Watchdog driver
Watchdog_init();

// Initialize the Watchdog driver default parameters
Watchdog_Params_init(&watchdogParams);

watchdogParams.resetMode = Watchdog_RESET_ON;
//watchdogParams.callbackFxn = watchdogCallback;
watchdogParams.debugStallMode = Watchdog_DEBUG_STALL_ON;
watchdogParams.windowSize = Watchdog_WINDOW_100_PERCENT;
// T-expire = (preloadValue+1) x 2 ^ 13 / RTICLK1 ; RTICLK1=20MHz
watchdogParams.preloadValue = 1954; // 80.03 mSec
watchdogParams.socHandle = gMmwMssMCB.socHandle;
//watchdogParams.esmHandle = esmHandle; // required in callback mode only

// Open the Watchdog driver
watchdogHandle = Watchdog_open(0, &watchdogParams);

while(1);*/
}

void MmwDemo_CANInit(uint8_t taskPriority)
{
Timer_Params timerParams;
Timer_Handle myTimer;
Error_Block eb;
Error_init(&eb);

Can_Initalize();

Semaphore_Params semParams;
Semaphore_Params_init(&semParams);
semParams.mode = Semaphore_Mode_BINARY;
sem = Semaphore_create(0, &semParams, NULL);

//Initialize the Task sensorConfig
Task_Params taskParams;
Task_Params_init(&taskParams);
taskParams.priority = taskPriority;
Task_create(mmwDemo_CAN_task, &taskParams, NULL);

//Timer for 1ms update
Timer_Params_init(&timerParams);
timerParams.period = 1000U;
timerParams.periodType = Timer_PeriodType_MICROSECS;
timerParams.arg = 1;
myTimer = Timer_create(Timer_ANY, gestionTimerIsr, &timerParams, &eb);

if (myTimer == NULL)
{
System_abort("Timer create failed");
}

return;
}

static void gestionTimerIsr(UArg arg0)
{
static uint16_t cpt_1Hz = 1000;

// Rhythm: 1000Hz / 1000 = 1Hz
if( cpt_1Hz <= 0 )
{
cpt_1Hz=1000;
gestionA1Hz = TRUE;
}
cpt_1Hz--;

//counting stuff...


//Enable task to run each ms
Semaphore_post(sem);
}

Tasks, timer and radar works fine apparently, but Reset don't fire. When I comment "myTimer = Timer_create(Timer_ANY, gestionTimerIsr, &timerParams, &eb);" Reset works again.

Can you help me please ?

Fabien

  • Hello

    It would be helpful to know the intent of  the change and what kind of reset do you wish to implement.

    Is the desire to just start /stop the  sensing on demand 

    or

    Is the intent to change the configuration.

    Would be good to know such details before getting into code modification based debug.

    Thank you

    Vaibhav

  • Hello,

    I need a soft reset in order to re-enter SBL later. My company use a CAN Reset command before uploading new firmware through bootloader.

    Thank you in advance, Fabien

  • Fabien:

    I can see that from the code that you provided that the timer triggers every 1ms. Then you enter the timer ISR which decrements cpt_1Hz variable, which is initially set 1000, to 0. This means that you post to the sem semaphore every 1s. Have you tried increasing the duration of the timer and then decrease how much you increment by. For example try timerParams.period = 10000U = 10ms and have static uint16_t cpt_1Hz = 100. This will decrease the number of ISR calls by a factor of 10, but you will still post to the semaphore every 1s.

    I believe what is happening is that the ISR is a high priority task and since it is called, so frequently it could be starving other tasks.

    Let me know if this works.

    Best,

    Connor Desmond

  • Thank you Connor,

    Your idea could be great but my semaphore is posted every ms, and I need this. My variable gestionA1Hz  is used in my CAN task for blinking LED and some minor stuff but the main purpose of my task is to run at 1ms. I also think that it is the core issue but I am stucked here, I absolutly need to get the task running at about 1ms.

    What I don't understand is why "SOC_softReset" which in reality set a register (C:\ti\mmwave_sdk_03_05_00_04\packages\ti\drivers\soc\src\soc.c l.848 

    ptrSOCDriverMCB->ptrRCMRegs->SOFTRST1 = CSL_FINSR(ptrSOCDriverMCB->ptrRCMRegs->SOFTRST1, 7U, 0U, 0xADU); ),

    does not success in reseting the software. A timer, even with high priority should not overwrite registers, don't you think ?

    I must be missing something...

    Have you another idea ? Thanks in advance, Fabien.

  • Fabien,

    I can't say with certainty that the 1ms semaphore post is the cause, but what I would suggest is increasing it and see if things just "work". You need to find the root cause of your problem then make adjustments accordingly. This is a complex system with multiple tasks running, so when something goes wrong it is hard to say exactly what an issue's cause is without thorough debug. Let me know how extending the time goes, if it doesn't fix the problem then we can dig deeper, but this is the first step.

    Best regards,

    Connor Desmond

  • Connor,

    Thank you for your insights. Increasing timer period to 10ms make it work. 5ms fails and 8ms works. It seems that setting the timer period ask for finding the sweet spot... I really need 1ms granularity, so I will keep the watchdog for the moment. 

    Let me know if you think of another trick. Thanks for your help, Fabien