Sys/Bios Runtime Exception when executing an Assembly code

Nios Ensa

Other Parts Discussed in Thread: SYSBIOS

Hello,

I've written a standard C66 assembly routine in C6678, which is tested without exceptions and provided expected results when no "Sys/Bios" is used.

Now, when I run it on a single task of Sys/Bios, where I repeat the call to the assembly routine over a loop, it shows the exception:

0x3dc8bcec
A20=0x10 A21=0xb
A22=0x3d720ec0 A23=0x3ccd40d0
A24=0x3dbeddf4 A25=0xbd44ecd2
A26=0x3d830037 A27=0x3cde2a2e
A28=0xbd801a79 A29=0x3d978654
A30=0x3cfb0dec A31=0x3cd43fab
B0=0x200 B1=0x827fb8
B2=0x0 B3=0x806de8
B4=0x15000103 B5=0x4003
B6=0x80010c B7=0x0
B8=0x10 B9=0xb
B10=0x4003 B11=0xe9dfdf6f
B12=0xbdc8bd31 B13=0xfb2a
B14=0x82bd94 B15=0x827fb8
B16=0xbf61c558 B17=0x3ef15aa7
B18=0xbf7fb0a2 B19=0xbd48fac8
B20=0xbc182488 B21=0x3cc96b7f
B22=0x400f B23=0x0
B24=0x3d9e27d4 B25=0xbd6bdc4f
B26=0x3d6b8c83 B27=0x3cb1ec0c
B28=0xbd720b5d B29=0x3d943eaa
B30=0x3c948898 B31=0x3c728413
NTSR=0x1020d
ITSR=0x400f
IRP=0x80010c
SSR=0x0
AMR=0x0
RILC=0x10
ILC=0xb
Exception at 0xe9dfdf6e
EFR=0x2 NRP=0xe9dfdf6e
Internal exception: IERR=0x12
Fetch packet exception
Resource conflict exception
ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0xe9dfdf6e, sp = 0x00827fb8.
To see more exception detail, use ROV or set 'ti.sysbios.family.c64p.Exception.enablePrint = true;'
xdc.runtime.Error.raise: terminating execution

Note that no errors are reported when repeating the call to the assembly routine over a smaller number of iterations (each iteration does the same processing [=inits buffers + asm call], on the same buffers !); for example, it just works fine for 50 iterations with correct data being computed, but shows this exception for 100 iterations or more ... the same processing executed without Sys/Bios works no matter how many iterations are made !

I just wander why it correctly runs the processing for first iterations, while exactly the "same processing" fails just a while after !

Apparently, the exception comes from the fact that the code just jumps into a region containing wrong instructions, jumping for "really unknown reasons"

I tried to debug my code, to know when the exception is raised, executing this code using the step-by-step feature (assembly step-into), when i do this, it just works fine !! i can't detect anything weird in the assembly and consequently runs fine for the entire range of iterations .. while it shows an exception when i run the whole code at once !

step-by-step execution (assembly step-into) -> works fine ; normal execution (resume button) -> exception !!

So, please first: is it normal that a code changes its behaviors (or won't work) when using SysBios ?

What might be the causes of this phenomenon ?

Is there a configuration to add in SysBios, to let it execute the assembly code as if there were no OS ?

Is it normal that the same processing works at times, and fails at times ? making a loop changes something ?

Additional information:

used buffers are in MSMC or L2SRAM

only 1 task is created, where i added the processing

i believe i got enough knowledge writing standard c66 assembly, therefore i won't plan to use the C version (for efficiency reasons)

in the .cfg file, there's only very basic configurations ...

Sys/Bios version: 6.34.2.18

I would appreciate your help

Thanks

over 12 years ago

0 Chad Courtney over 12 years ago

TI__Mastermind 30825 points

It's reporting that it has a resource exception. Can you open the assembly window at 0xe9dfdf6e and screen capture at least 10 lines before and after this location and post it?

The issue is most likely a violation in the hand written assembly you mentioned. I'd like to examine the code there.

Also, there's information on what you may have a resource conflict in the C66x CPU and Instruction Set UG http://www.ti.com/lit/ug/sprugh7/sprugh7.pdf

Best Regards,
Chad

0 Nios Ensa over 12 years ago in reply to Chad Courtney

Intellectual 300 points

Thanks for your answer Chad,

The address 0xe9dfdf6e is located outside my assembly program range, therefore containing garbage code. I mention that minor changes in the sys/bios project code, leads to different run-time errors, now it's:

[C66xx_0] x0
A16=0x0 A17=0x3f800000
A18=0x0 A19=0x3f800000
A20=0x4 A21=0x0
A22=0x3cd63e6f A23=0xbc41a947
A24=0xbeaa4930 A25=0x3e29a200
A26=0x3d8bf654 A27=0xbcfd0823
A28=0xbc219418 A29=0xbe1140a4
A30=0xbeaf55d1 A31=0x3cc30adc
B0=0x300 B1=0x827ff8
B2=0x0 B3=0x806de8
B4=0x15000103 B5=0x4003
B6=0x800288 B7=0x0
B8=0x4 B9=0x0
B10=0x4003 B11=0xddf79ff7
B12=0xbec3ef02 B13=0xd9ee
B14=0x82bddc B15=0x827ff8
B16=0xbec3ef02 B17=0x3f6c8347
B18=0xbf0e39c5 B19=0x3f54db11
B20=0x3d12e46b B21=0x3d50ffb3
B22=0xf B23=0x0
B24=0xbdf3880f B25=0x3ea99318
B26=0x3d551830 B27=0xbd15c556
B28=0xbe3890b7 B29=0xbd98e61e
B30=0xbec02b2e B31=0x3f67f7d5
NTSR=0x1020d
ITSR=0xf
IRP=0x800288
SSR=0x0
AMR=0x0
RILC=0x4
ILC=0x0
Exception at 0xddf79ff6
EFR=0x2 NRP=0xddf79ff6
Internal exception: IERR=0x2
Fetch packet exception
ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0xddf79ff6, sp = 0x00827ff8.
To see more exception detail, use ROV or set 'ti.sysbios.family.c64p.Exception.enablePrint = true;'
xdc.runtime.Error.raise: terminating execution

Code at 0xddf79ff6:

ddf79f90: BDDDF7CB [!A2] CLR.S2 B23,15,23,B27
ddf79f94: FFFF5FFF || .word 0xffff5fff
ddf79f98: FFC339FC || .word 0xffc339fc
ddf79f9c: FFFFFF6F .word 0xffffff6f
ddf79fa0: F7BFF57F .word 0xf7bff57f
ddf79fa4: FFFFFFEF || .word 0xffffffef
ddf79fa8: EFFFFFB6 || .word 0xefffffb6
ddf79fac: FBFF1B8F .word 0xfbff1b8f
ddf79fb0: DFFEFFFE || [!A0] STW.D2T2 B31,*+B15[32511]
ddf79fb4: FFFFFF7F .word 0xffffff7f
ddf79fb8: FB6BF97B || .word 0xfb6bf97b
ddf79fbc: 7FFE9FEE || [!B2] LDW.D2T2 *+B15[32415],B31
ddf79fc0: FFBFBFDF .word 0xffbfbfdf
ddf79fc4: FFF7FFBD || .word 0xfff7ffbd
ddf79fc8: FF7EDFE6 .word 0xff7edfe6
ddf79fcc: EFFFDFFF .word 0xefffdfff
ddf79fd0: FEBF7FFF || .word 0xfebf7fff
ddf79fd4: FFFFFBFF || .word 0xfffffbff
ddf79fd8: FBBEDFBE || .word 0xfbbedfbe
ddf79fdc: 8F76DDF7 [ A1] STNDW.D2T2 B31:B30,*B29--(B22)
ddf79fe0: FFF7FFFF || .word 0xfff7ffff
ddf79fe4: EFFDFFFD || .word 0xeffdfffd
ddf79fe8: D5F975EB || [!A0] MVKH.S2 0xf2eb0000,B11
ddf79fec: B7FBFFDF || [!A2] STH.D2T2 B15,*+B15[31743]
ddf79ff0: FFFFFFFD || .word 0xfffffffd
ddf79ff4: FFFFBFEF .word 0xffffbfef
ddf79ff8: E67EDDEB .word 0xe67eddeb
ddf79ffc: FFF7677B || .word 0xfff7677b
ddf7a000: FFFDFFFF || .word 0xfffdffff
ddf7a004: FFFFFDFF || .word 0xfffffdff
ddf7a008: E1EFFF7D || .word 0xe1efff7d
ddf7a00c: FF7D3F62 || .word 0xff7d3f62
ddf7a010: BFFF7FFF [!A2] STW.D2T2 B31,*+B15[32639]
ddf7a014: BFFFFFFF || [!A2] STW.D2T2 B31,*+B15[32767]
ddf7a018: F33FDFD9 || .word 0xf33fdfd9
ddf7a01c: 77F75FF6 || [!B2] STNDW.D2T2 B15:B14,*B29++[B26]
ddf7a020: FFDFFFFE .word 0xffdffffe
ddf7a024: FFFFFFFF .word 0xffffffff
ddf7a028: FF85FFEF || .word 0xff85ffef
ddf7a02c: DFE7FEFD || [!A0] STW.D2T1 A31,*+B15[26622]

The core jumps to this address somehow. I remind you that the hand-written assembly code runs without issues on a project with no sysbios, it also runs without issues in sysbios if called outside a loop only once, this problem emerges only in sysbios when repeating in loop the call to our assembly routine.

And this is the part of our standard ASM code where the exception "occasionally" raises (initially: A0=1, B31=256, A1/B1: pointers in the input buffer, A2/B2/A7/B7/A4/B4: pointers in the input buffer, ...) :

main_loop:

MVC .S2 B31,ILC
NOP 3

[A0] SPLOOP 8
|| MVC .S2 B31,RILC
|| SUB .L1 A0,1,A0

LDDW .D1 *++A1[2],A27:A26 ; m1
|| LDDW .D2 *++B1[2],B27:B26 ; m1'

LDDW .D1 *+A1[A6],A21:A20 ; m3
|| LDDW .D2 *+B1[B6],B21:B20 ; m3'

LDDW .D1 *-A1[A5],A23:A22 ; m0
|| LDDW .D2 *-B1[B5],B23:B22 ; m0'

LDDW .D1 *+A1[A5],A25:A24 ; m2
|| LDDW .D2 *+B1[B5],B25:B24 ; m2'

NOP 2

DSUBSP .L1 A21:A20,A27:A26,A27:A26 ; a3
|| DSUBSP .L2 B21:B20,B27:B26,B27:B26 ; a3'

DADDSP .L1 A21:A20,A27:A26,A23:A22 ; a1
|| DADDSP .L2 B21:B20,B27:B26,B23:B22 ; a1'

DADDSP .L1 A23:A22,A25:A24,A29:A28 ; a0
|| DADDSP .L2 B23:B22,B25:B24,B29:B28 ; a0'

ROTL .M1 A26,0,A31 ; a3ii2
|| ROTL .M2 B26,0,B31 ; a3ii2'
|| DSUBSP .L1 A23:A22,A25:A24,A29:A28 ; a2
|| DSUBSP .L2 B23:B22,B25:B24,B29:B28 ; a2'

CMPYSP .M1X A15:A14,B13:B12,A31:A30:A29:A28 ; W1 x W2S
|| CMPYSP .M2 B15:B14,B13:B12,B31:B30:B29:B28 ; W1' x W2S

DADDSP .L1 A29:A28,A23:A22,A23:A22 ; v1
|| DADDSP .L2 B29:B28,B23:B22,B23:B22 ; v1'
|| DSUBSP .S1 A29:A28,A23:A22,A25:A24 ; v2
|| DSUBSP .S2 B29:B28,B23:B22,B25:B24 ; v2'

CMPYSP .M1 A17:A16,A11:A10,A31:A30:A29:A28 ; W2 x W4S
|| CMPYSP .M2X B17:B16,A11:A10,B31:B30:B29:B28 ; W2' x W4S
|| XOR .L1X A27,B0,A30 ; a3ii1
|| XOR .L2 B27,B0,B30 ; a3ii1

CMPYSP .M1 A19:A18,A13:A12,A31:A30:A29:A28 ; W3 x W6S
|| CMPYSP .M2X B19:B18,A13:A12,B31:B30:B29:B28 ; W3' x W6S
|| DSUBSP .S1 A29:A28,A31:A30,A21:A20 ; v4
|| DSUBSP .S2 B29:B28,B31:B30,B21:B20 ; v4'
|| DADDSP .L1 A29:A28,A31:A30,A27:A26 ; v3
|| DADDSP .L2 B29:B28,B31:B30,B27:B26 ; v3'

CMPYSP .M1 A17:A16,A25:A24,A31:A30:A29:A28 ; v2 x W2
|| CMPYSP .M2 B17:B16,B25:B24,B31:B30:B29:B28 ; v2' x W2'
|| STDW .D1 A23:A22,*A2++[2] ; store v1
|| STDW .D2 B23:B22,*B2++[2] ; store v1'
|| DADDSP .S1 A31:A30,A29:A28,A15:A14 ; W1
|| DADDSP .S2 B31:B30,B29:B28,B15:B14 ; W1'

NOP 1

DADDSP .S1 A31:A30,A29:A28,A17:A16 ; W2
|| DADDSP .S2 B31:B30,B29:B28,B17:B16 ; W2'
|| CMPYSP .M1 A15:A14,A27:A26,A23:A22:A21:A20 ; v3 x W1
|| CMPYSP .M2 B15:B14,B27:B26,B23:B22:B21:B20 ; v3' x W1'

DADDSP .S1 A31:A30,A29:A28,A19:A18 ; W3
|| DADDSP .S2 B31:B30,B29:B28,B19:B18 ; W3'

DSUBSP .S1 A31:A30,A29:A28,A25:A24 ; f2
|| DSUBSP .S2 B31:B30,B29:B28,B25:B24 ; f2'

CMPYSP .M1 A19:A18,A21:A20,A31:A30:A29:A28 ; v4 x W3
|| CMPYSP .M2 B19:B18,B21:B20,B31:B30:B29:B28 ; v4' x W3'

DSUBSP .S1 A23:A22,A21:A20,A25:A24 ; f3
|| DSUBSP .S2 B23:B22,B21:B20,B25:B24 ; f3'

STDW .D1 A25:A24,*A7++[2] ; store f2
|| STDW .D2 B25:B24,*B7++[2] ; store f2'

NOP 1

DSUBSP .S1 A31:A30,A29:A28,A25:A24 ; f4
|| DSUBSP .S2 B31:B30,B29:B28,B25:B24 ; f4'
|| STDW .D1 A25:A24,*++A4[2] ; store f3
|| STDW .D2 B25:B24,*++B4[2] ; store f3'

NOP 4

STDW .D1 A25:A24,*+A4[A5] ; store f4
|| STDW .D2 B25:B24,*+B4[B5] ; store f4'

SPKERNEL 0,0

setup_iter:

ADDAD .D1 A1,A3,A1 ; inp
|| ADDAD .D2 B1,B3,B1 ; inp

NOP 6

SPMASKR ; reload

NOP 1

ZERO .L1 A15:A14 ; W1=ZERO
|| DMV .L2 B11,B10,B15:B14 ; W1=W1S

NOP 1

DMV .L2 B13,B12,B17:B16 ; W2=W2S

NOP 1

MVKH .S1 3F800000h,A15 ; W1=ONE
|| CMPYSP .M2 B11:B10,B13:B12,B31:B30:B29:B28 ; W3 = W1S x W2S

ADDAD .D1 A2,A3,A2 ; outp v1
|| ADDAD .D2 B2,B3,B2 ; outp v1

NOP 1

DMV .S1 A15,A14,A17:A16 ; W2=ONE

DADDSP .S2 B31:B30,B29:B28,B19:B18 ; W3=W3S

[A0] B .S2 setup_iter
|| [A0] SUB .S1 A0,1,A0

NOP 1

DMV .S1 A15,A14,A19:A18 ; W3=ONE

ADDAD .D1 A7,A3,A7 ; outp v2
|| ADDAD .D2 B7,B3,B7 ; outp v2

NOP 1

ADDAD .D1 A4,A3,A4 ; outp v34
|| ADDAD .D2 B4,B3,B4 ; outp v34

; end.

SHRU .S1 A5,2,A5 ; qpas
|| SHRU .S2 B5,2,B5 ; qpas
|| MV .L1 A8,A1 ; inp
|| ADD .L2X 8,A8,B1 ; inp+8

SHRU .S1 A6,2,A6 ; 2 x qpas
|| SHL .S2 B8,2,B8 ; N/PAS *=4
|| ADDAD .D1 A1,A5,A1 ; inp + qpas x 8
|| ADDAD .D2 B1,B5,B1 ; inp+8 + qpas x 8
|| MV .L2X A10,B10 ; W4S -> W1S

SHRU .S1 A3,2,A3 ; 3 x qpas
|| SUB .D1 A1,16,A1 ; inp + qpas x 8 -= 16
|| SUB .D2 B1,16,B1 ; inp+8 + qpas x 8 -= 16
|| MV .L1 A8,A2 ; outp v1
|| ADD .L2X 8,A8,B2 ; outp v1

SHRU .S2 B6,2,B6 ; 2 x qpas
|| MV .D1X B8,A0 ; *= 4
|| MVKL .S1 3F800000h,A15 ; ONE

SHRU .S2 B3,2,B3 ; 3 x qpas
|| ADDAD .D1 A2,A5,A7 ; outp v2
|| ADDAD .D2 B2,B5,B7 ; outp v2+8
|| MVKH .S1 3F800000h,A15 ; ONE
|| ZERO .L1 A14 ; ONE
|| MV .L2X A11,B11 ; W4S -> W1S

ADDAD .D1 A7,A5,A4 ; outp v34
|| ADDAD .D2 B7,B5,B4 ; outp v34+8
|| DMV .L1 A15,A14,A17:A16 ; W2=ONE
|| DMV .L2 B11,B10,B15:B14 ; W1=W1S
|| CMPYSP .M2 B11:B10,B11:B10,B23:B22:B21:B20 ; W1S x W1S = W2S

SUB .L2 B4,16,B4 ; outp v34+8 -= 16
|| SUB .L1 A4,16,A4 ; outp v34 -= 16
|| SHRU .S2 B5,1,B31 ; qpas/2
|| DMV .S1 A15,A14,A19:A18 ; W3=ONE

MVK .S2 8,B19
CMPLT .L2 B5,B19,B0 ; stop if qpas<8
DADDSP .S2 B23:B22,B21:B20,B13:B12 ; W2S
NOP 2
DMV .L2 B13,B12,B17:B16 ; W2=W2S
|| CMPYSP .M2 B11:B10,B13:B12,B23:B22:B21:B20 ; W1S x W2S = W3S
NOP 3
DADDSP .S2 B23:B22,B21:B20,B19:B18 ; W3S
NOP 2
CMPYSP .M2 B11:B10,B19:B18,B23:B22:B21:B20 ; W1S x W3S = W4S
NOP 1
CMPYSP .M2 B19:B18,B19:B18,B23:B22:B21:B20 ; W3S x W3S = W6S
NOP 1
DADDSP .S2 B23:B22,B21:B20,B27:B26 ; W4S
[!B0] B .S2 main_loop
DADDSP .S2 B23:B22,B21:B20,B27:B26 ; W6S

MV .L1X B27,A11 ; W4S
MV .S1X B26,A10 ; W4S

MV .L1X B27,A13 ; W6S
|| MVKL .S2 80000000h,B0 ; XOR

MV .S1X B26,A12 ; W6S
|| MVKH .S2 80000000h,B0 ; XOR

Sorry if the code isn't clear, as I was obliged to take this special concerned part out of the entire code.

As you can see, there's no way here, that the code jumps to: 0xe9dfdf6e or 0xddf79ff6

I'm aware of resource and write conflicts, and i don't think the above code commits these.

The remaining question is: is it possible that such a code works well in a project without sysbios, while it "occasionally" fails in a project with sysbios

Thanks Chad

0 Chad Courtney over 12 years ago in reply to Nios Ensa

TI__Mastermind 30825 points

Ok, I wasn't certain if that was garbage location or not. In that case can you dump the assemble window around the address that's in B3. That's the return pointer from the previous jump. Maybe we can find something there which will explain why it's jumping to garbage data, such as a potential corrupted pointer.

Best Regards,
Chad

0 Nios Ensa over 12 years ago in reply to Chad Courtney

Intellectual 300 points

Code around address B3=0x806de8 (same code, after exception or after fresh reload):

$C$L1254, $C$RL674:
00806db8: 051003E2 MVC.S2 IER,B10
00806dbc: 029003E2 MVC.S2 IER,B5
00806dc0: 9D4D LDW.D2T2 *B15[8],B4
00806dc2: 6C6E NOP 4
00806dc4: 0210AF9A ANDN.L2 B5,B4,B4
00806dc8: 021003A2 MVC.S2 B4,IER
00806dcc: 020403E2 MVC.S2 CSR,B4
00806dd0: 02102FDA OR.L2 1,B4,B4
00806dd4: 009003A2 MVC.S2 B4,CSR
00806dd8: 002C0362 B.S2 B11
00806ddc: E0200000 .fphead n, l, W, BU, nobr, nosat, 0000001b
00806de0: 01826162 ADDKPC.S2 $C$RL675 (PC+8 = 0x00806de8),B3,3
00806de4: 02380FD8 MV.L1 A14,A4
$C$RL675:
00806de8: 10004000 DINT
00806dec: 02B54F7B AND.L2 B10,B13,B5
00806df0: 021003E2 || MVC.S2 IER,B4
00806df4: 0210AFFA OR.L2 B5,B4,B4
00806df8: 021003A2 MVC.S2 B4,IER
00806dfc: 003CE2E5 LDW.D2T1 *+B15[7],A0
00806e00: 01D79C28 || MVK.S1 0xffffaf38,A3
00806e04: 0257A228 MVK.S1 0xffffaf44,A4
00806e08: 01804168 MVKH.S1 0x820000,A3
00806e0c: 018C0264 LDW.D1T1 *+A3[0],A3
00806e10: 02004168 MVKH.S1 0x820000,A4
00806e14: 01000FD9 MV.L1 A0,A2
00806e18: D0001491 || [!A0] B.S1 $C$L1256 (PC+164 = 0x00806ea4)
00806e1c: C2100264 [ A0] LDW.D1T1 *+A4[0],A4
00806e20: B00C6810 [!A2] B.S1 ti_sysbios_knl_Swi_restoreHwi__E (PC+25408 = 0x0080d160)
00806e24: C2D7A028 [ A0] MVK.S1 0xffffaf40,A5
00806e28: C2804168 [ A0] MVKH.S1 0x820000,A5
00806e2c: 0C6E NOP 1
00806e2e: 6608 AND.L1 A3,A4,A0
00806e30: D03C6123 [!A0] BNOP.S2 $C$RL676 (PC+120 = 0x00806e98),3
00806e34: C2140265 || [ A0] LDW.D1T1 *+A5[0],A4
00806e38: C2D7A428 || [ A0] MVK.S1 0xffffaf48,A5
00806e3c: E1000000 .fphead n, l, W, BU, nobr, nosat, 0001000b
00806e40: C2804168 [ A0] MVKH.S1 0x820000,A5
00806e44: 00106F78 AND.L1 A3,A4,A0
00806e48: D2140264 [!A0] LDW.D1T1 *+A5[0],A4
00806e4c: 02D7A62A MVK.S2 0xffffaf4c,B5
00806e50: 0280416A MVKH.S2 0x820000,B5
00806e54: 00002000 NOP 2
00806e58: D2100204 [!A0] LDHU.D1T1 *+A4[0],A4
00806e5c: 00006000 NOP 4
00806e60: D0106F79 [!A0] AND.L1 A3,A4,A0
00806e64: C00000A8 || [ A0] MVK.S1 0x0001,A0
00806e68: C29402E7 [ A0] LDW.D2T2 *+B5[0],B5
00806e6c: C258D029 || [ A0] MVK.S1 0xffffb1a0,A4
00806e70: C257AA2A || [ A0] MVK.S2 0xffffaf54,B4
00806e74: C2004169 [ A0] MVKH.S1 0x820000,A4
00806e78: C200416A || [ A0] MVKH.S2 0x820000,B4
00806e7c: D00E4121 [!A0] BNOP.S1 $C$RL676 (PC+56 = 0x00806e98),2
00806e80: C3100204 || [ A0] LDHU.D1T1 *+A4[0],A6
00806e84: C0140362 [ A0] B.S2 B5
00806e88: C21002E4 [ A0] LDW.D2T1 *+B4[0],A4
00806e8c: 0C6E NOP 1
00806e8e: 91C7 MV.L2X A3,B4
00806e90: 032C1FDA MV.L2X A11,B6
00806e94: 01860162 ADDKPC.S2 $C$RL676 (PC+24 = 0x00806e98),B3,0
$C$L1255, $C$RL676:

I'd like to signal an important issue in my main file, which is :

/*
* ======== taskFxn ========
*/
Void taskFxn(UArg a0, UArg a1)
{

System_printf("enter taskFxn()\n");

do_processing();

System_printf("exit taskFxn()\n");
BIOS_exit(0);
}

void taks_fn() {
do_processing();
}

/*
* ======== main ========
*/
Void main()
{
do_processing();
do_processing();
do_processing();
do_processing();
taks_fn();
/*
* use ROV->SysMin to view the characters in the circular buffer
*/
System_printf("Start Test\n");

BIOS_start(); /* enable interrupts and start SYS/BIOS */
}

The weird thing is, that the same function which contains the assembly routine (do_processing();), when called in the main function doesn't cause an exception (even when called 5 times in the example above), while it causes the problem when called inside the sysbios task function. Is this problem related to interrupts ?

Regards

0 Nios Ensa over 12 years ago in reply to Nios Ensa

Intellectual 300 points

Here, perhaps i'm getting to understand something; in my built assembly routine, I use all the available registers A0-A31 and B0-B31, after saving B3 and A10-A15; B10-B15 into an external buffer, i restore those last values just before quitting my ASM routine ...

Is it possible that sysbios tries to interrupt my routine, jumping into the interrupt_isr whose address is supposed to be stored among one of the reserved internal registers (B3 and A10-A15; B10-B15); while i used those for other things in ASM, then corrupted in the sense of sysbios use ?

Perhaps my ASM is not interruptible. Does sysbios interrupts my routine even if only 1 task is in progress ?

Thanks

0 Nios Ensa over 12 years ago in reply to Nios Ensa

Intellectual 300 points

And, what supports my last claim, is that B11 always contains the weird address where the core "erroneously" jumps ..

0 Nios Ensa over 12 years ago in reply to Nios Ensa

Intellectual 300 points

Indeed, interrupts caused the problem; even if there's only 1 task, sysbios executed in background lower priority tasks, interrupting my asm routine, which i didn't expect ..

No exception occurred when I disabled and restored interrupts (IER), before and after the assembly routine ..

Thanks Chad for your help !

0 Chad Courtney over 12 years ago in reply to Nios Ensa

TI__Mastermind 30825 points

00806dd8: 002C0362 B.S2 B11

The B11 is definitely what's being corrupted. The question is how. The ISR should return everything (all registers) to the state they were in prior to the interrupt being taken.

A couple questions.

Is the ISR running any assembly routine or is it all compiled? If it's all compiled it will return everything to the state it was before, but if you have hand written assembly and you didn't restore everything then you could have such an issue.

Where is B11 coming from? Go back further in the code and find out where it's coming from? If it's coming off the stack it maybe that you're stack is overflowing and then getting trampled on.

You're mentioning hand assembled code, the code where B3 is located at, is that hand assembled code? Can you load the file if it is?

Best Regards,

Chad

0 Nios Ensa over 12 years ago in reply to Chad Courtney

Intellectual 300 points

The code in B3 is not my hand written assembly.

The register B11 is used in my assembly routine, then I changed its initial value there; even if in the end of my routine I restore these registers, sysbios interrupts me in the middle, where registers are not restored yet.

Thanks

0 Nios Ensa over 12 years ago in reply to Nios Ensa

Intellectual 300 points

Then, can we write interruptible assembly code, which saved and using the registers (B3, A10-A15, B10-B15) ?

0 Chad Courtney over 12 years ago in reply to Nios Ensa

TI__Mastermind 30825 points

You can write assembly code which is interruptable as long as you fully follow the C calling conventions with regards to what your assembly routine must push/pop to/from the stack in the time frame it must be done. This is described in the C6000 Optimizing Compiler UG.

The C/C+ Compiler Forum may have a twiki page or other reference where this is simplified if you want to post this part of the question over there.

Best Regards,
Chad

Processors

Processors forum

Sys/Bios Runtime Exception when executing an Assembly code