Steps Needed to Support Log_info with SYSBIOS

What device are you running? Also which version of SYS/BIOS are you using? Can you look in ROV to see which Hwi are present. What type of library are you using for BIOS? Try using the following to see if it makes a difference.

BIOS.libType = BIOS.LibType_Custom;
BIOS.logsEnabled = false;
BIOS.assertsEnabled = false;

Todd

As Todd stated, the BIOS version and part number would help.

BIOS uses a timer to drive the periodic 1ms tick.  I suspect that on rare occassions (every 8 seconds), the 2 ISRs happen at/near the same time so there's interference.

On some devices, it is possible to prioritize the interrupts so that your "important" timer interrupt is at a higher priority than the other interrupts and will therefore preempt other interrupts.

The OS disables interrupts during some critical sections.  This disable time is on the order of 100 instruction cycles.  Depending on memory, this could take more than 100 instruction cycles.  On some devices (like Cortex-M and C28), it is possible to define "zero-latency" interrupts that will never be disabled by the OS.  These ISRs cannot make any OS calls, but they should be able to run with minimal OS interference.

Which device are you using?  Which OS version?

Hello,

Please find my answers below.  

I am using the Piccolo 320F28069 running at 80Mhz so that I can run the FLASH with 2 waitstates (instead of 3 waitstates at 90Mhz).  I am using SYSBIOS 6.35.  Here are some more details on my implementation:

When I created the SYSBIOS project, I used a “minimal” project.  

Here is the ROV Hwi readout (requested by Todd) 

                                                                                                                                                                                            The "RicksTick" Hwi is mine.  The other two are evidently from SYSBIOS.  Can I disable these or does SYSBIOS need them?           

Here is some more ROV screenshots: 

Also, here is how I setup my Timer0 hwi: 

And here is how I setup the timer0 to run :

InitCpuTimers(); // Initialize Timer 0 only.
ConfigCpuTimer(&CpuTimer0, 80.000000, 100.0); //Configure a 100 usec period.  
CpuTimer0Regs.TCR.bit.TSS = 0; //Start the timer. 
BIOS_start();  //After BIOS starts, I process the timer0 ints from Hwi38.  

BIOS uses a timer to drive the periodic 1ms tick.  I suspect that on rare occassions (every 8 seconds), the 2 ISRs happen at/near the same time so there's interference.

- That makes sense.  Does it do this by default?  So, when I use the BIOS clock module I can only set an integer numer of usecs.  I can see how it is wasteful for me to use Timer0 and then SYSBIOS doesn't benefit from that.  It then has to create its own Tick and Timestamp with different timers.  Then occasionally they conflict.  Is there a way to generate a SYSBIOS timer interrupt with fine granularity control over its period (without me using external Timer0)?  E.g. can I setup a SYSBIOS Clock module to run at 62.5 usecs?  

-It's interesting that when I used the SYSBIOS clock module to generate these interrupts (with an integer number of usecs), I did not have these problems.   Perhaps that is because SYSBIOS could use that same clock to generate its Tick and Timestamp.  When I went outside of SYSBIOS to use Timer0 INT then I started to see these problems.  However, I need fine granularity of control of the period of the interrupts.  1 usec granularity is not sufficient.  

   On some devices, it is possible to prioritize the interrupts so that your "important" timer interrupt is at a higher priority than the other interrupts and will therefore preempt other interrupts.

- Yes, this is a good topic to try to use to design a solution.  Can you prioritize Hwis on the C28x family?  I was under the impression that you could not do that.  Swis yes, but Hwis, no.  If I am wrong, please let me know.  If this SYSBIOS “tick” thread is causing the interference, then can I disable it or make it lower priority than my Timer0 Hwi where I do important stuff. 

-An interesting side note here is that I can run the BIOS clock module at 100usec and generate reliable/regular interrupts.  However, I can’t use clock module in my application because I need to set the timer with finer granularity than 1 usec.     

The OS disables interrupts during some critical sections.  This disable time is on the order of 100 instruction cycles.  Depending on memory, this could take more than 100 instruction cycles.  

-That’s interesting.  I am thinking about what speed of MCU I need to reliably run a 16kHz task with SYSBIOS.  Or, is SYSBIOS not really meant to be used with code that needs to run at 16kHz speeds?  Right now my Piccolo is running at 80Mhz.  Just rough numbers here, but 80Mhz/16kHz = 5000cycles.  A Hwi to Swi takes roughly 500cycles of overhead to process.  I am not sure how much overhead the “Tick” and any other SYSBIOS functions are taking. 

-As a side note I am also using the 28346 delphino at 200Mhz on another application and this has plenty of overhead.  I don’t see this problem.  

On some devices (like Cortex-M and C28), it is possible to define "zero-latency" interrupts that will never be disabled by the OS.  These ISRs cannot make any OS calls, but they should be able to run with minimal OS interference.

-Yes, I can possibly propose this to my manager.  I’m worried about the fact that I can’t make OS calls from these ISRs.  This kind of kills the purpose of using SYSBIOS.  We can possibly structure our 16kHz code to run outside of SYSBIOS and then place slower loops and management/housekeeping stuff in SYSBIOS.  However, then we’d need to be very careful to make the two sets of code to interact reliably.  I don’t think that will fly.  Our 16kHz loop is where all the important stuff happens, so it might not make sense to use SYSBIOS at all if that’s the case.  Or perhaps we just need to use a faster processor if we want to use SYSBIOS.   Do you have any guidance on what type of processing power and RAM we need to reliably run a decent sized16kHz task?    

-I’d also like to understand and measure what other SYSBIOS threads are running.  

Thanks,

Rick

Can you try changing the masking options field to "All"?  This will disable all other interrupts while your timer interrupt is running.  In your current setup, the other interrupts in the system can preempt your interrupt routine.  If you set this field to ALL, then the IER register will be set to 0 so that no other interrupts can preempt you.  By default, the BIOS interrupts are set to "self" so that your interrupt can preempt BIOS.

Hi,

I did try that but the result was the same.  The jitter was still there.