BIOS_start() would not complete after updateing SYS/BIOS to current version.

Hi Enrique,

Did you upgrade to SYS/BIOS v6.24.4.22 or  SYS/BIOS v6.34.4.22 ?

Enrique Herrera said:

 I was able to compile and download to my target.  However, the system does not start up correctly.  I was able to step through the code and I found that BIOS_start() does not complete.  The main() would exit debug breakpoint when it finishes the Timer startup and when it goes to SWI startup function.

I am able to see HWI running. But I do not see any tasks or SWI running.  Is there something that Im missing.

If I understand correctly, the problem you are seeing with the new release is that your Tasks and Swis have stopped running, but the Hwis run normally. Can you share a screenshot of the detailed page of Task and Swi ROV view ? Also, how do you conclude the Hwis are running ?

Best,

Ashish

You are correct about the SYS/BIOS version.  I upgraded to v6.34.4.22.

I would like to thank you for reminding me about RTOS ROV.  I have forgoten that I was able to view the state of all the object of SYS/BIOS.

(Forgive me on the resolution of the screen shots, I'll figure another way to get them. I think is just I have my desktop to too high of a resolution)

Here is the detailed page of Task Obj.

Here is basic page of SWI Obj.

I guess I was mistaken about my system not starting correctly. You can see in the startup object. All the configured modules have been started up.

I thought I was only getting HWI starting because I would see only Hwi functions running. When I suspended the running of my project.  I would never see my tasks running.. And I would get the code resume running when just stepping though the main code.

I have to see why my tasks are not running. The tasks should be running since i am getting messages from the main hardware controller.

I was going through the modules in the RTOS Object View.  I found this in the BIOS module:

,ti.sysbios.BIOS,Module,N/A,N/A,Caught exception in view init code: "C:/ti/xdctools_3_24_05_48/packages/xdc/rov/StructureDecoder.xs", line 544: java.lang.Exception: Target memory read failed at address: 0x0, length: 1This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.

Im not sure if I should be worry about it.

Enrique,

There is a known bug in BIOS module view  that is causing the exception when ROV attempts to get the currentThreadType. I am guessing you are seeing an exception because of the same bug. This will be fixed in the next release. In order to determine the thread type, you can use the Raw view->Module State->threadType field for now.

(Note: The ROV bug should not effect your program execution in any way)

I looked at the Task ROV view from your screenshot. None of the tasks are in running state. This is odd and should not happen unless the running task is not being displayed in ROV. This is possible If you have some constructed tasks in your application as constructed tasks are not shown in the ROV view. Do you create any task in your application using Task_construct() API instead of Task_create() API ?

I would also like you to add a breakpoint in the Swi function and Task functions (Preferably all tasks if there aren't too many) and then run your code. This way you can know for sure that the Tasks and Swis are not being run.

Best,

Ashish

Ashish, 

I would like to thank you for your explanation for the error that’s being displayed in ROV for the BIOS module. I wll not worry about it.

I had the feeling that the tasks were not running. I had one of hardware interrupts releasing a semaphore.  But I never see the task for that semaphore take it.  So, I did what you asked.  I did put a breakpoint before the loop for each task.  But these breakpoints do not occur.  I thought there was an issue with the breakpoint, so added one at the hardware interrupt that was occurring.  That breakpoint was captured.  That indicated me that the breakpoints are working and the tasks were not being started. 

Next, I created a Swi instance that would just toggle one of LEDs I have on my product. I put a breakpoint in this small function.  Then I call Swi_Post(swi0) right before BIOS_Start().  This will force this Swi instance to occur.  However, the breakpoint in this Swi instance did not happen.

So the Task and SWI are not starting.  This strange behavior occurred soon I added in Clock module.  So I had one of my clocks to start at boot up.  I got every strange value in time remining for DSP_StartupPoll clock function.

What I did next is remove the Clock module and all it instances.  I compiled and ran it on the traget. The SWI and Task shown to be running.  All the breakpoint i set before I removed the Clock module did occured.  

I thought I had a memory issue.  So I added in other modules I do not need.  For instance I added in Event and Agent modules.  I configure them so they would use some memory.  I was able to compile and run it on my target.  The system came up with Swi and Tasks running.  But as soon I just add in the Clock module, with the instances I need, and with the other modules I do not need.  The system will not start the Swi and Tasks.

To me, everything points to the Clock module. But I need the Clock module. 

I forgot to mention that I do have a service request open on this issue:

Service Request # 1-903873308

Hi Enrique,

Enrique Herrera said:

So the Task and SWI are not starting.  This strange behavior occurred soon I added in Clock module.  So I had one of my clocks to start at boot up.  I got every strange value in time remining for DSP_StartupPoll clock function.

You are right, the tRemaining field looks strange. tRemaining is computed using the following math:

tRemaining = Timeout - ClockTicks;

if (tRemaining < 0)

tRemaining += pow(2,32);

Since you are seeing a tRemaining value of 4294827626 I am suspecting that the ClockTicks value became much larger than Timeout and tRemaining became a negative value which finally got adjusted to a large positive value. Can you find the clock ticks value from Clock->Raw View Page->Module State->ticks. I would expect it to be around 139700 for the above case.

One possible cause could be that the Timer is running too fast which would even justify why none of the tasks every get run. Can you look at the Timer module's Basic and Device view ? The Basic view should show the period & timer type and the device view should show the current & remaining timer counts. These might help catch any inconsistencies.

Best,

Ashish

 I re-ran my project on my target and check the status of the Clock and the Timer modules.  I was able to find the running instance of the Clock module with tRemaining  value of 4294864252.  

I looked at the Timer module and it has a period of 300 of PeriodType_COUNTS and with no pre-scalar.

I then looked at the Device of the Timer module and found currCount of 284 and remaining Count of 284.  Then I ran and suspended 2 more times and found the two counts with value 155 and the other time with values 194.

The problem I have with that is why currCount and remainingCount would have the same value.  I would think the currCount would have a growing value and the remainingCount would decreasing value form 300.

I had to try something with my project today.  So what I did is downgraded the version of SYS/BIOS and XDCTools.  On SYS/BIOS, I went to 6.33.7.53. And on XDCTools, I went to 3.23.5.61.  The biggest hurdle was XDCTools did not like the memory sections in my SYS/BIOS RTSC configuration file.  After I passed that, I was able to compile and download it to my target device.

I still see my Swi and Tasks not running. And the Clock instance with a very big value.  I cannot believe that this problem would exist for this long. It must be something in my configuration.  

*SNAP*!

Ashish Kapania said:

Timer period (in terms of Timer counts) for clock module should be equal to 1ms by default unless you modify Clock tickPeriod. Assuming you are using a default value of 1ms for clock tickPeriod, a Timer period of 300 counts is too small. The system clock frequency for Control28335 Platform is 150Mhz which is also the Timer frequency and at this frequency I would expect the Timer period to be 150000. I am guessing this low period value is causing frequent interrupts and stalling your system when you use the clock module.

Can you share the section of code where you are configuring the Clock ? Also, can you check the cpu frequency from the BIOS module view ?

Thank you for helping me to solve this problem. The issue was in Sys/BIOS->Scheduling->Clock - Module Settings.  I had the value 2 in Tick Period (us) field.  I thought that field was met for the setting the Timer for the Clock module. And thought it was setting time resolution (in milliseconds) for Clock module to use.  But really, is setting the Timer that the Clock module will use. And it is in microseconds.  Originally, the Timer for the Clock was going off every 2 microseconds.  That’s why it did not have any time to do anything else.  

I think you knew that was the problem.  Thanks for all your help, Ashish.

Glad to know its fixed.