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.

xdc.runtime.Main: "power/PowerCC3200.c", line 301: assertion failure

Other Parts Discussed in Thread: CC3200, CCSTUDIO

Hello,

Could you explain what does the following error means?

xdc.runtime.Main: "power/PowerCC3200.c", line 301: assertion failure
xdc.runtime.Error.raise: terminating execution

I have attached a screenshot hope it helps,

A little history: This error comes when I started the continuous spi transfer with an ADC and sending TCP packet to PC.

Thank you in advance,

  • Moving to TI-RTOS Forum

    Regards,
    Gigi Joseph.
  • Hi Daniel,

    It could be that the application is attempting to release a constraint that doesn't exist. Have you added your own power constraints to your applciation?
    Also could you do a quick "BIOS Scan For Errors" to make sure it's not a stack/heap overflow issue? Thanks

    Best,
    Alexander
  • Hello Alexander,
    Thank you for your reply. I do not make any power_mng related calls. Just added my existing code from a TM4C129 project. Yes, checked the Scan for errors but did not show any error.
    I read the Power Management for CC3200 but have not found any usable.

    Is there any way to remove all power management related function from this project?
  • Which version of TI-RTOS are you using at the moment? Could you also post the code where you performing the SPI transfers?

    Best,
    Alexander
  • Sure, could you give me a private link? I will share the complete project.

  • I sent you a PM. See u there!
  • Hi Daniel,

    I've been looking over your code, could you post some screenshots of ROV (what tasks are running) prior to the failure point? In addition to the stack peaks of those tasks?

    Also just to clarify, WiFi is still running when collecting the ADC samples correct?

    Best,
    Alexander
  • Yes, its running.

    The picture below is when the TCP connection is established, but DAM (Data Acquisition Module) task is not collecting the samples. 

    This screenshot, when some ADC conversion results are acquired and ready to transfer to TCP_transmit task where as a bigger chuck will be forwarded to the host pc via Wifi.

    And after some breakpoint hit (about 6-8) here is the result

  • Okay interesting, thanks for posting those. Would it be possible perform the ADC data acquisition independently of the WiFi to see if the assert is still raised?

    Best,
    Alexander
  • Sure. I modified my project by commented out the following code:

    // Conversion is made for all channels, all ADCs
    		if (aiChannelIndex == ADS1263_MAX_DIFF_CHANNELS - 1)
    		{
    			// Reset OffsetRequest flag.
    			adc->OffsetState = false;
    
    			// Set special function code for the host
    			// Send the response to TCP_Transmit Task where additional buffering is made
    			// NumberOfDRDYResponses
    			for(blockID = 0;blockID<NumberOfDRDYResponses;blockID++)
    			{
    				response[blockID].FCode = DAM_FCODE_DataReady;
    
    				// Toggle GPIO here when BIOS_WAIT_FOREVER to see TCP transfer affect on ADC conversion.
    // THIS one
    				//Mailbox_post(TCP_Mailbox_Transmit,&(response[blockID]),BIOS_WAIT_FOREVER);
    			}
    
    			if(adc->isStopAcquisition)
    			{
    				// at the end of conversion stop
    				Clock_stop(adc->clkHndl);
    			}
    		}

    So, the ADC conversion running but TCP_transmit task never notified. 

    It is also important to mention that I had started a topic about sharing sockets btw. tasks in CC3200:

    In my project I just send the socket handle to both TCP_Receive and TCP_Transmit tasks. Because none of TI employee confirms my thoughts I left the thread open. 

    Do you think is there any connection btw. Power_xy related error and socket sharing?

  • There could be, we can see exactly how this assert is occurring if you enable logging in your application.

    Could you add/change the following in your .cfg file?

    Text.isLoaded = true;
    BIOS.logsEnabled = true;
    
    driversConfig.libType = driversConfig.LibType_Instrumented;
    
    var Log = xdc.useModule('xdc.runtime.Log');
    var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');

    Then build/run and select Tools->Execution Analysis in the CCS Debug view and check the printf logs.

    Then run the application until it fails and note the Power events that are logged within the SPI driver.

    Ex) 

    Hopefully this sheds more light on this issue.

    Best,

    Alexander

  • Well, when I open the Analysis configuration CCS crahes... every time... ( I have only 5 sec to set the Printf logs, than crash).

  • Sorry to hear that Daniel,  it could be one of two things. The first is your application, in which case you can build and run an instrumentation example to test whether the System Analyzer still crashes. Two, it's CCS's JVM heap, in which case navigate to your CCS installation directory

    c:\ti\ccsv6\eclipse and open the ccstudio.ini file. Within there update the line to 768 to increase CCS's memory.

    -Xmx768m
    

    Best,

    Alexander

  • Hell Alexander,

    Unfortunately I don't have more time for CC3200, Other urgent issues come up that I need to solve.

    See you later and thank you for your help.