CCS/TMS320C6457: DSPBIOS 5.33.06 scheduler problem

Domenico Logozzo

Part Number: TMS320C6457

Tool/software: Code Composer Studio

Hello to all developer,

I have an issue with my application which runs on a TMS320C6457 with DSPBIOS 5.33.06 and compiler v. 6.1.20. It seems that the scheduler of task, swi and hwi sometimes is not doing the right thing.

Probably I'm missing something and doing something wrong even if I vae checked the constraints an limitations about calls of SWI_post of HWI_disable() HWI_restore() and so on...

I have seen (tracing with log messages) in some cases that if I post an SWI from a HWI service routine then, instead of having the SWI running after the HWI completion, it starts before it is completed.

Just to explain what I'm observing is:

HWI start --> SWI_post --> SWI starts ---> SWI ends --> HWI resuming --> HWI ends

instead of what I expected:

HWI start --> SWI_post --> HWI ends --> SWI starts ---> SWI ends

This behaviour comes out after application is running while executing a repetitive test. When it starts to fail then I can observe it in many HWI-SWI post cases...

I know that these few informations are not so much to have some answer... anyway perhaps someone has experienced similar problems... I can say that I have inspected my code to see if I was doing some illegal

call (for example any SWI_post when interrupts are disabled or any HWI_disable not followed by HWI_restore(oldcsr)) but I can't find anything wrong.

Can you help me?

over 3 years ago

0 Rahul Prabhu over 3 years ago

TI__Guru** 115410 points

Domenico,

Since HWI are higher priority compared to SWI, your expected behavior is correct. Are you sure that you are HWI is resuming and that it is not triggered due to a new interrupt that cam in. What is the sequence that you are using in HWI are you disabing the interrupts using global disable doing a post and then reenabling interrupts?

Ideally there is no thread that should pre-empt the HWI. Are you checking the scheduler behavior in UIA or some other visualization tool or how are you determining the sequence followed by the scheduler.

Regards,

Rahul

0 Domenico Logozzo over 3 years ago in reply to Rahul Prabhu

Prodigy 160 points

Hi Rahul and thanks for the answer!

I try to give an answer to your question. Yes I'm quite sure that no post is performed while HWI are disabled. It was the first thing I checked since DSPBIOS user guide alert about that illegal procedure. Regarding the method I used to trace the sequence of events I have calls to a macro that write different codes in a circular unsigned int buffer. This is to mark the different significative points where program has run. The write routine is a very simple code:

#define WriteDebugStatus(data) oldcsr = HWI_disable(); \
  writedebugstatus(data); \
  HWI_restore(oldcsr);

void writedebugstatus(unsigned int data)
{
   extern int DebugPnt;
   extern unsigned int DebugVect[_MAX_DEBUG_LENGTH];

   DebugVect[DebugPnt] = data;
   DebugPnt = (DebugPnt + 1) % _MAX_DEBUG_LENGTH;
}

where oldcsr is a local unsigned int variable defined in the calling HWI.

So the calling code will perform the following:

unsigned int oldcsr;
WriteDebugStatus( some int value );

See for example these results in the DebugVect[] after the test was running for some time:

[2569]   0x00000011
[2570]   0x40000001
[2571]   0x40000000
[2572]   0x00000010
[2573]   0x00000011
[2574]   0x40000001
[2575]   0x40000000
[2576]   0x00000010

the code 0x00000011 is the enter of an HWI.

the code 0x40000001 is the enter in the SWI posted from HWI

the code 0x40000000 is the exit from SWI posted from HWI

the code 0x00000010 is the exit from the HWI (the same that was marked at its start with 0x00000011)

So it is a very strange behaviour. And I think that the scheduler is corrupted by something I have done... but I cannot realize what I'm doing wrong

Best regards Rahul!

0 Domenico Logozzo over 3 years ago

Prodigy 160 points

No one had to face this problem? Is it possible I'm the only one experienced this scheduler strange behaviour?

I add that I have checked in firmware if there was any illegal call (i.e. SWI_post when interrupt are disabled or SWI_disable, SWI_enable when interrupt

are disabled). I didn't find any illegal call. Can somone suggest what could make scheduler to produce these error?

0 Rahul Prabhu over 3 years ago in reply to Domenico Logozzo

TI__Guru** 115410 points

Domenico,

The DSP BIOS kernel is a 10+ year old kernel which is atleast 3 generations behind the TI RTOS kernel that we are actively supporting at the moment, so the expertise around DSP BIOS is a little sparse.

I would recommend looking at RTA and ROV tools integrated in older CCS versions that supported DSP BIOS to have some visualization of the scheduler to understand and root cause this behavior. I would also check to see if there are any stack overflow or condition which is causing code to jump or blocking conditions which is causing this behavior.

Regards,

Rahul

0 Domenico Logozzo over 3 years ago in reply to Rahul Prabhu

Prodigy 160 points

Hello,

finally I think I have found the problem!

I had a function from which I called the SWI_raisepri and the SWI_restorepri DSPBIOS API.

Normally this function was called from SWI context but I have found one task that occasionally could call the same function. In the DSPBIOS API callability table is clearly rmarked that these 2 functions cannot be called from task context.

So I have resolved the problem posting a new SWI, from inside the task, which call that function.

TI team, could you tell me if you think, checking the source code of SWI_raisepri and SWI_restorepri, that this behaviour is expected if those API are called from a task?

I mean, I would be assured that this is the real origin of my problem and I'm not experienced some side effect...

Best reagards!

0 Domenico Logozzo over 3 years ago in reply to Domenico Logozzo

Prodigy 160 points

I'm still waiting for TI Expert feedback regarding SWI_raisepri and SWI_restorepri...

Code Composer Studio™︎

Code Composer Studio forum

CCS/TMS320C6457: DSPBIOS 5.33.06 scheduler problem