Sys/Bios and preemptive multitasking

Sergej Sergeyuk

Other Parts Discussed in Thread: SYSBIOS, AM1705

Hi, all.

My platform is am1705 (CCS5.1.1; SYS/BIOS 6_33_02_31; Win7*64bit)

I need a preemptive multitasking at SYS/BIOS.
I use example from spruex3k (3.5.6 Task Yielding). 
New SYS/BIOS project + copy-paste the source code gives me three different results.

I decided the problem is a modification of stack during the switching of tasks.
I tried to guard the System_printf by the pair "Task_disable" + "Task_enable". Result is the same (damaged).
The only way is to protect the application from crash is to remark "Task_yield" call.

My question is: how to implement the preemptive multitasking?

It is possible to increment the "numTimes" in the "hiPriTask" to increase the probability of error.

1) Correct result like
Task 0: time is 0
Task 0: time is 1
Task 0: time is 2
Task 0: time is 3
Task 1: time is 4
Task 1: time is 5
Task 1: time is 6
Task 1: time is 7
hiPriTask here
...

2) Sometime I can see the result like this:
Task 2: time is 44
Task 2: time is 45
Task 2: time is 46
Task 2: time is 47
hiPriTask here
Task -1047245608: time is 48
Task -1047245608: time is 49
Task -1047245608: time is 50
Task -1047245608: time is 51
Task 1: time is 52
Task 1: time is 53
Task 1: time is 54
Task 1: time is 55

3) Sometime the result is:
Task 1: time is 52
Task 1: time is 53
Task 1: time is 54
Task 1: time is 55
Exception occurred in ThreadType_Task.
Task handle: 0xc00061a8.
Task stack base: 0xc00061f0.
Task stack size: 0x2000.
R0 = 0x00000000 R8 = 0xffffffff
R1 = 0x00000000 R9 = 0xffffffff
R2 = 0x016e3600 R10 = 0xffffffff
R3 = 0xc1944cd8 R11 = 0xffffffff
R4 = 0xffffffff R12 = 0x6000005f
R5 = 0xffffffff SP(R13) = 0xc00081c0
R6 = 0xffffffff LR(R14) = 0xc1944d50
R7 = 0xffffffff PC(R15) = 0xc194d274
PSR = 0x200000df
ti.sysbios.family.arm.exc.Exception: line 174: E_dataAbort: pc = 0xc194d274, lr = 0xc1944d50.
xdc.runtime.Error.raise: terminating execution

over 13 years ago

0 ToddMullanix over 13 years ago

TI__Guru* 96960 points

Sergej,

What exactly are you doing between the runs? E.g. Reset CPU, Reloading, and run? reload and run? restart and run?

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

No Resets, No Restarts.

It's enough to: reload run - reload - run - ... - run -> exception.

The bug isn't stable. Once for 10-15 runs. Or even more.

The PC and SP points to the random places. Sometime even to the data segment.

It's really the stack damage.

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Hi Sergej,

Can you attach the target configuration you are using? I cannot get the problem reproduced.

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

Hi, Todd.

The project file is attached. Bin, Obj, etc are included.

3771.task_test.rar

correct case (break point at System_exit, all messages are after F6):

Error case. The SP & PC from time to time points to the different addresses. Error can be repeated pretty easy. 5-6 runs only.

P.S. Win7/64 bit.

CCS 5.1.1 is installed to 'C:\TexasInstrument', not to the default location 'C:\ti'.

The content of CCS folder:

0 Sergej Sergeyuk over 13 years ago in reply to Sergej Sergeyuk

Intellectual 420 points

P.S. Sorry, I have forgotten one moment...
I made a changes in the SRC during testing and i'm not sure all the changes are reverted back.
So the text may be different in the comparison with the Wizard's SRC.
But the result is always the same. 10-15 starts and error again.

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Sergej,

Is this on a custom board or a TI board?

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

It's on the custom board. am1705 based.

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Have you reproduced this on a TI board? If so, which one (rev also).

Todd

0 ToddMullanix over 13 years ago in reply to ToddMullanix

TI__Guru* 96960 points

Hi Sergej,

Found it. I was able to reproduce the issue and it's because a Task stack overflowed (I saw the error in LoggerBuf). The app sets the size to 512. I increased the size to 576 and it ran fine. Every once and awhile the stack on one of the tasks goes to 524 (via ROV->Tasks->Detailed View).

Can you try increasing the stack and see if that helps? I'll file a documentation bug to fix the sample code in the docs.

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

Hi, Todd.

Thank you for your job. It's good to see that you're able to reproduce the bug now.

I don't have a EVK and it's quite difficult to perform the test you asked. I've asked the regional TI dealer for a rent this EVK but... i'm not sure it's possible at all.

The size of stack is the first what i changed during the exploring the problem. The SRC files in the test projects i posted are with the 8K stack size for each task.

The bug still exists.

0 Sergej Sergeyuk over 13 years ago in reply to Sergej Sergeyuk

Intellectual 420 points

hi, Todd again.

Look, please to the attached image:

1) The error appears between the switching of tasks.

2) The string generated by printf is always the same and does not depend from the running task.

Can it be a bug/limitation of printf / logger used in the application? The SysMin is used in the project.

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Sergej,

Can you reproduce it without the Mmu in your .cfg file. For example, do the following.

//var Mmu = xdc.useModule('ti.sysbios.family.arm.arm9.Mmu');
//Mmu.enableMMU = false;

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

MMU is off, 10-15 starts and an exception is here.

0 Sergej Sergeyuk over 13 years ago in reply to Sergej Sergeyuk

Intellectual 420 points

Sorry, I mean:

1) The MMU is commented.

2) The CCS holds a line "MMU On" in the status line.

Sorry

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

I don't mean set MMU to off. I mean remove the lines from your .cfg.

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

I corrected my previous post.

The MMU is commented in the CFG file. Exactly like you asked. The changes are confirmed by the CCS in the status line.

15 starts and i have an exception again. I really looking to the logger/printf functionality.

0 Sergej Sergeyuk over 13 years ago in reply to Sergej Sergeyuk

Intellectual 420 points

my current CFG file is:

4431.task_test.cfg.txt

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

The "[ARM9_0]" is put in by CCS, not the target. I'm pretty sure it is not related.

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

hi, Todd.

are you able to reproduce the bug on the TI board?

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Sergej,

I believe we have reproduced it. We are investigating...

What gel file are you using?

Todd

0 Sergej Sergeyuk over 13 years ago in reply to ToddMullanix

Intellectual 420 points

hi, Todd.

The gel file is:

5340.init.gel.txt

0 ToddMullanix over 13 years ago in reply to Sergej Sergeyuk

TI__Guru* 96960 points

Hi Sergej,

We are still looking at this. It looks like the stack pointer is not being adjusted correctly somewhere. We hope to have an update early next week.

Todd

0 Alan DeMars over 13 years ago in reply to ToddMullanix

TI__Mastermind 30830 points

Sergei,

You have successfully uncovered a bug in our interrupt dispatcher code.

I have a fix in place that we are currently regression testing internally.

We are targeting a new SYS/BIOS release (6.33.04) with the fix by the end of next week.

If you need a workaround sooner than that, I think that can be arranged.

Alan

0 Sergej Sergeyuk over 13 years ago in reply to Alan DeMars

Intellectual 420 points

Hi, Alan, hi, Todd, hi all.

It's nice to know you found the problem. The SYS/BIOS isn't stable today.

I have a problem with MMU also. It gets enabled/disabled at rintime : )

I hope the problem is in the switching of stacks.

0 Alan DeMars over 13 years ago in reply to Sergej Sergeyuk

TI__Mastermind 30830 points

Can you elaborate on the MMU problem your having in another thread please?

Alan

0 Sergej Sergeyuk over 13 years ago in reply to Alan DeMars

Intellectual 420 points

Hi, Alan, hi all.

No reasons from my point of view. My feeling is the source of problem with MMU is the task switching.

And seems we need a workaround earlier than the next week.

Can you explain how to fix the bug?

0 Alan DeMars over 13 years ago in reply to Sergej Sergeyuk

TI__Mastermind 30830 points

Sergej,

Sorry for the long delay.

In your SYS/BIOS installation directory, please back up and then replace your packages/ti/sysbios/family/arm/da830/Hwi_asm.s470 file with the attached version.

Then, if you aren't using the custom BIOS library build flow already, add the following to your configuration script:

var BIOS = xdc.useModule("ti.sysbios.BIOS");

BIOS.libType = BIOS.LibType_Custom;

Then, clean and rebuild your application.

This should take care of the problem.

We will be releasing a 6.33.04 SYS/BIOS product which includes this fix sometime next week.

Alan

5417.Hwi_asm.zip

Processors

Processors forum

Sys/Bios and preemptive multitasking