Sysstack Disclosure for 'C5515 and 'C5535

Despite its name, sysstack is just part of the user stack.  It exists for backwards compatibility.  It typically holds the upper 7 bits of values such as the return register.  The usual calling convention uses both the stack and sysstack, through the push instruction.  When you perform a context switch, you need to update both XSP and XSSP.  This should all be covered in the CPU reference guide SWPU073 revision E http://www.ti.com/lit/ug/swpu073e/swpu073e.pdf

What sort of "pre-5x CC" code do you have?  Is it assembly code?  For which ISA?

Hello Archaeologist,

Quick responses are always appreciated.  I am pretty sure the last time I asked this - the same doc you pointed out was referred to - I will check that again.

Is the use of sysstack optional?  Meaning - can it be disabled if backward compatibility isn't needed?  Probably not - but it is much simpler obviously dealing with only one stack.  And as far as you know there are no user restrictions regarding sysstack?

The code I am running is circa '2010 - mid year - so was that still CC 3.1 or 4?  There is a lot of assembly routines - vector.asm, stuff that deals with I/O and i2s - all of which summarily spew the obligatory amount of error messages now under CC v5x.  

I have both a USBSTK 5515 and 5535  - I was hoping to use the USBSTK5535 for my code - to 'easily' port over what I had to the '5535 but that is proving to be more of a challenge than I had anticipated.

Thanks!

Oh I see, you mean CCS version 5.x, not a CPU version.

Using sysstack is not optional.  It is distinct from stack to provide a distinct stack mode for compatibility with C54x code.  If you  are not attempting to use native C54x code, I recommend you put the stack mode in "fast" mode.  In this mode, sysstack is primarily used for the upper 7 bits of the return address.

You can write directly to sysstack, but I recommend you don't.  Use PSHBOTH if you must write to sysstack.  Generally, you should stick to stack.

Perhaps if you showed me one of the mystery error messages that you now get?

Yes Archaeologist - I meant CCS version - sorry about that.   I have had my 'C5535 board since last year - the silicon on this USBSTK is as follows as printed on the device:

TMX320C55
35AZHHIO
16ADS9W
WFI7    GI

Board says Rev C.  I also have the 'C5515 USBSTK - and that is what 'spews' errors.  I have culled that somewhat - but I can re-import that into CCS V5 and show you some of the original error messages - note I am not trying to make anything mysterious.  Did the assembler change that much for this DSP family in the toolset?

Oh, and I want to say thanks - I will disable 'c54x compatibility mode - if all I have to worry about regarding sysstack is the upper 7 bits of the return address should be a piece of cake.  I assume also you mean I need to POPBOTH as well.  I am doing a complete context-switch stack fix-up for both IRQ's and regular c-style function calls.

Thanks,
johnw 

Here's one example of the errors that I am seeing:

"C:\Users\John\AppData\Local\Temp\1428810", REMARK at line 288: [R5670]
This software reset instruction will not reset the C16, XF, and HM
bits in the ST1 register (see the C55x silicon exceptions errata;
Advisory CPU_91)
reset

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 855: [E9999]
Syntax Error
BIT (ST1, #ST1_INTM) = #0

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 855: [E9999]
Invalid instructionsyntax, Xmem or Ymem expected
BIT (ST1, #ST1_INTM) = #0

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 855: [E9999]
Invalid mnemonic specified
BIT (ST1, #ST1_INTM) = #0

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 855: [E9999]
Invalid mnemonic specified
BIT (ST1, #ST1_INTM) = #0

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 892: [E9999]
Syntax Error
BIT (ST1, #ST1_INTM) = #1

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 892: [E9999]
Invalid instructionsyntax, Xmem or Ymem expected
BIT (ST1, #ST1_INTM) = #1

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 892: [E9999]
Invalid mnemonic specified
BIT (ST1, #ST1_INTM) = #1

"C:\Users\John\AppData\Local\Temp\1428810", ERROR! at line 892: [E9999]
Invalid mnemonic specified
BIT (ST1, #ST1_INTM) = #1

8 Assembly Errors, No Assembly Warnings

Regards,
johnw 

Here are some more:

[R5672]
If there is a long MMR write with no intervening single MMR before
this return from interrupt, then an interrupted conditional
execution may be corrupted; (see the C55x silicon exceptions errata;
Advisory CPU_94)
RETI

"..\tASM.asm", REMARK at line 330:
[R5674]
If processor is in fast-return mode, and this return from interrupt
instruction is stalled in the ADDRESS or ACCESS1 phase, then the
execution of a subsequent conditional execution may be corrupted;
(see the C55x silicon exceptions errata; Advisory CPU_99)
RETI

"..\ASM.asm", REMARK at line 339:
[R5650]
Be sure you are familiar with rev 1.0 silicon errata advisory CPU_68
before reading the BRAF bit from ST1
mov mmap(ST1_55), t1

"..\ASM.asm", REMARK at line 350:
[R5672]
If there is a long MMR write with no intervening single MMR before
this return from interrupt, then an interrupted conditional
execution may be corrupted; (see the C55x silicon exceptions errata;
Advisory CPU_94)
RETI

"..\tASM.asm", REMARK at line 350:
[R5674]
If processor is in fast-return mode, and this return from interrupt
instruction is stalled in the ADDRESS or ACCESS1 phase, then the
execution of a subsequent conditional execution may be corrupted;
(see the C55x silicon exceptions errata; Advisory CPU_99)
RETI

"..\ASM.asm", REMARK at line 396:
[R5650]
Be sure you are familiar with rev 1.0 silicon errata advisory CPU_68
before reading the BRAF bit from ST1
mov mmap(ST1_55), t1

"..\ASM.asm", REMARK at line 403:
[R5672]
If there is a long MMR write with no intervening single MMR before
this return from interrupt, then an interrupted conditional
execution may be corrupted; (see the C55x silicon exceptions errata;
Advisory CPU_94)
RETI

"..\ASM.asm", REMARK at line 403:
[R5674]
If processor is in fast-return mode, and this return from interrupt
instruction is stalled in the ADDRESS or ACCESS1 phase, then the
execution of a subsequent conditional execution may be corrupted;
(see the C55x silicon exceptions errata; Advisory CPU_99)
RETI

More errors:

"..\..\asm\aic_test_i2c.asm", ERROR! at line 336: [E9999] Syntax Error
AC1 = 0

"..\..\asm\aic_test_i2c.asm", ERROR! at line 336: [E9999] Invalid mnemonic
specified
AC1 = 0

"..\..\asm\aic_test_i2c.asm", ERROR! at line 337: [E9999] Syntax Error
AR1 = 0x00

"..\..\asm\aic_test_i2c.asm", ERROR! at line 337: [E9999] Invalid mnemonic
specified
AR1 = 0x00

"..\..\asm\aic_test_i2c.asm", ERROR! at line 340: [E9999] Illegal directive or
mnemonic
@BRC0_L = #0x02FF || mmap()

"..\..\asm\aic_test_i2c.asm", ERROR! at line 341: [E9999] Syntax Error
localrepeat {

"..\..\asm\aic_test_i2c.asm", ERROR! at line 341: [E9999] Invalid mnemonic
specified
localrepeat {

"..\..\asm\aic_test_i2c.asm", ERROR! at line 342: [E9999] Syntax Error
repeat(#0xFFFF)

"..\..\asm\aic_test_i2c.asm", ERROR! at line 342: [E9999] Invalid mnemonic
specified
repeat(#0xFFFF)

"..\..\asm\aic_test_i2c.asm", ERROR! at line 345: [E9999] Illegal directive or
mnemonic
}

\inc\lpva200.inc", WARNING! at line 1091:
[W9999]
Attempt to redefine symbol EMIF25_IODFT_LGC_OFFSET, ignored
EMIF25_IODFT_LGC_OFFSET .set 0x88 ; IODFT Test Logic Global Control Register

\inc\lpva200.inc", WARNING! at line 1092:
[W9999]
Attempt to redefine symbol EMIF25_IODFT_LGC_0, ignored
EMIF25_IODFT_LGC_0 .set EMIF25_BASE + EMIF25_IODFT_LGC_OFFSET

\lpva200.inc", WARNING! at line 1093:
[W9999]
Attempt to redefine symbol EMIF25_IODFT_LGC_1, ignored
EMIF25_IODFT_LGC_1 .set EMIF25_IODFT_LGC_0 + 1

\asm\vector.asm", ERROR! at line 122:
[E9999]
Syntax Error
bit (ST1, #11) = #1 ; Disable interrupts

"asm\vector.asm", ERROR! at line 122:
[E9999]
Invalid instructionsyntax, Xmem or Ymem expected
bit (ST1, #11) = #1 ; Disable interrupts

"\asm\vector.asm", ERROR! at line 122:
[E9999]
Invalid mnemonic specified
bit (ST1, #11) = #1 ; Disable interrupts

"\asm\vector.asm", ERROR! at line 122:
[E9999]
Invalid mnemonic specified
bit (ST1, #11) = #1 ; Disable interrupts

"\asm\vector.asm", ERROR! at line 123:
[E9999]
Illegal directive or mnemonic
 @IVPD_L = #(_RST >> 8) || mmap()

Archaeologist,

OK - cobwebs are clearing a bit.

Issue is algebraic vs. mnemonic assembly - seems to compile I need to be in one mode and to successfully run the assembler I need to be in the other - looking at this a little closer - guess there's not a good way to have one file that can be mnemonic and another algebraic in the same project?  Maybe I can assign individual rules to each file - I will look at that.

Regards,
johnw 

Ah, spoke too soon on that one - seems like it is a more fundamental issue than what I described above.

Actually, it is an algebraic and mnemonic thing.  I guess so much for the import tool into CC 5x from earlier projects.

I am somewhat limping along now.

The compiler can generate algebraic or mnemonic assembly equally well, so if the input is a C file, it shouldn't matter whether you compile it for algebraic or mnemonic, unless you've got inline assembly in the file.  Yes, you can assign file-specific options; I'm not sure exactly how this is done.

johnw said:

"..\ASM.asm", REMARK at line 339:
[R5650]
Be sure you are familiar with rev 1.0 silicon errata advisory CPU_68
before reading the BRAF bit from ST1
mov mmap(ST1_55), t1

I'm having trouble figuring out which CPU revision the C5535 is, but I doubt that it's CPU revision 1.0; you need to use the --silicon_version option to limit the assembler's warnings to only those silicon errata which apply to that device.

Hello Archaeologist,

Yes - my old 'main' file has some in-line algebraic assembly for enabling and disabling interrupts - the compiler didn't seem to like that.

I have stubbed that for now in favor of getting something to compile and load and run somewhat - and I will take a closer look at the inline assembly issue soon.

Regards,
John 

Archaeologist.

I am starting with my old project that is the 'C5515 - also a TMX part released circa 2010.   So that warning is from the 'C5515 compile.

Once I get this project quasi-stable I will move on to the 'C5535.

Thanks,
JohnW