Stack Pointer Alignment

John,

What are you trying to do?  Why do you need to align the stack pointer?  Ususally the compiler will manage that for you.  I looked in the Mnemonic Instruction Reference Guide (http://www-s.ti.com/sc/techlit/spru374) and don't see anything like that. 

Regards.

Hello TommyG,

I am doing things like:

mov dbl(*sp(#21)), RETA

John,

Not really sure what you are doing, but I don't see anything in the instruction set that is comparable to the C28x instructions you mentioned.  You could test the SP manually and make the adjustment, but that would burn cycles.  Maybe someone more clever than me will have an idea.

Regards.

TommyG,

I am not too worried about cycles right now - just want to get something working - and then I can work on optimizations.

I hope I am not up against errata with the TMX device - I am getting a TMS320C5515 device - may get my eZdsp USB stick reworked just in case.  I noticed quite a bit of errata involving the SP and having to manually place NOP's.  I looked for remarks from the assembler in my code listing but didn't see any - but I am not sure that I am not being affected by that errata.

Something else as well - might as well mention it.  The timers (timer IRQ's) and masks (IER0) seem to be poorly documented.  If it wasn't for the lpaxxx.inc (don't have my code in front of me at the moment) - I would not know what those masks really are.  Even though this is mentioned in a lot of places - and I think in one of the docs it says to look in the datasheet for the specific masks in the vector table and such - it isn't there - trying to find how to enable Timer2 in IER0 in the tms320c5515.pdf will yield zero.  Just thought I'd mention this - realize the PDF says draft copy as well.

Best Regards,
johnw

John,

Sorry, I'm a little confused.  What TMX device are you referring to?  I don't see anything about the SP in the errata for the C5515 device.  Can you explain why you need to adjust the SP the way you demonstrated with the write to the RETA register and what isn't working the way you want it to?

The information you are looking for on the General Purpose Timer is spread across multiple documents.  First, the C55x v3.x CPU Reference Guide (http://www-s.ti.com/sc/techlit/swpu73), Sec 2.8 gives the generic description of how interrupts are managed by the CPU used in the VC5504/05 and C5504/05/14/15 devices.  Next, the GP Timer/Watchdog Timer User's Guide (http://www-s.ti.com/sc/techlit/sprufo2), Sec 5 gives a description of interrupt management at the Timer peripheral level.  Finally, you need the mapping of the timer interrupts to the CPU interrupt management registers.  This information is in the file lpva200.inc as you mentioned.  It will also be in the C5515 System User's Guide which hasn't been published yet.  It should be out within the next month.  I will encourage the C5000 Product Team to get this released as soon as possible.  If you haven't seen it yet, a usage example is available in the CSL package for the C5515.  You want the C55XCSL-LOWPOWER version which is available here: http://focus.ti.com/docs/toolsw/folders/print/sprc133.html.  There are examples for both CCSv3.3 and CCSv4.x IDEs.  The example you want is in the \gpt folder.

Regards.

Hello TommyG,

In this case - I am speaking specifically of the TMX320C5515.

I am sorry - the 'errata' document that I meant is:  SPRU652G - The 'CC5x Programmer's Reference Supplement.  In this document, there are numerous CPU Advisories that could apply - I am not 100% sure since this document is a little dated - and the TMX devices aren't specifically listed - pretty sure the 'C5515 wasn't even developed yet.

The URL is http://focus.ti.com/lit/ug/spru652g/spru652g.pdf

Yes, the CSL Low-Power code has been helpful - and it is good also to know that TI is generating new documentation for the 'C55x series.

Thanks,
John W. 

John,

I'm not sure how many of the advisories from the Reference Supplement apply to the C5515 (TMX or TMS) because this document is referring to the v2.x of the CPU.  The C5515 class devices (04/05/14 also) are based on the v3.x CPU which was a significant rework of the previous generation.  I'll see if I can find out if there is a comparable document for the v3.x CPU.

Regards.

TommyG,

Yes - if you can find a comparable document for the v3.x (btw - what .x version is the 'c5515?) - CPU - that would be very helpful.

Thanks,
John W.

John,

My understanding is that all the new C5500 devices (VC5504/05 and C5504/05/14/15) are based off the v3.3 CPU.  Everything else is based on the v2.2 CPU.

Regards.

Hello Tommy,

Just a note - when reading the C/C++ Manual for the 'C55X series, it does say explicitly it is up to the programmer to make sure the stack pointer is aligned on 32-bit boundaries.

The compiler assumes that the stack is initialized at run time to an even
word address. If your assembly function calls a C/C++ function, you must
align the SP by subtracting an odd number from the SP. The space must
then be deallocated at the end of the function by adding the same number
to the SP. For example:

_func: AADD #−1, SP          ;  aligns SP
         ...                 ;  body of function
         AADD #1, SP         ;  deallocate stack space
         RET                 ;  return from asm function

I am calling C functions from assembly, and vice-versa, so I think this can explain that 1 offset I am seeing. 

At the top of the interrupt routine, the stack might not be aligned to an even
(long-aligned) address. You must write code to ensure that the stack
pointer is aligned properly.

The stack must be aligned to a 32-bit (even 16-bit word) boundary before
calling a function. The parent function pushes the 16-bit return PC.

Regards,
John W.

John,

Thanks for the explanation.  The C28x is a newer CPU design, so that might be the reason for the ASP / NASP instructions??

Regards.

TommyG,

Yes - that is what is looks like.  I wouldn't be surprised that if you were to examine the OPCODE's for ASP and NASP, if that didn't decode into something either exact or extremely similar to this manual fix-up that is required with the 'c55x.

Again, on the outside looking in - it's a little mysterious why TI has handled some of these cores so differently.

Thanks,
John W. 

John,

Since I'm not involved in the design process, I really can't comment on this much.  I know design goals are different for our different processor families, also that we learn over time so specs evolve and that within a product family backward compatabililty is important.  Don't know the specifics of C55x vs. C28x, except that C28x is a newer core. 

Regards.

Hello Tommy,

The above that I took out of the C/C++ UG is from 2003 - even an older 'epoch' than the Assembler UG.

I am finding the CPU 3.x Reference Manual to be the best - even though I think I am seeing different behavior than what is described as the 32-bit slow-return mode for function calls and interrupts.

Is there any chance the TMX silicon that I have is not behaving as documented?  For instance, even though I think I have processor in slow return mode (C54X_STK) in the reset vector, I still see the CPU using RETA - i.e. - I see the LCPTR (sp? - not looking at my debugger now) being used vs. seeing the return address popped off of (X)SP.

Maybe my app is somehow switching from slow-return to fast-return mode, I've tried looking for that but the docs say if the reset vector has the C54X_STK value written there - then it should be in slow-return 32-bit mode.

Thanks,
John W. 

John,

Are you sure you are booting using your vector table?  The RTS lib has a default vectors.asm file that gets linked in automatically if you don't override it.  It uses the fast return stack mode.  Look at your .map file and look at the section you put the vector table in.  It will be 200h long if the RTS version is linked in also.

Regards.

Tommy,

From my map file:

vector       0     00002c00  [ 00001600 ] 00000100          *   

                   00002c00  [ 00001600 ] 00000100          *   vector.obj (vector)

vectors      0     00002d00  [ 00001680 ] 00000100          *   NOLOAD SECTION

                   00002d00  [ 00001680 ] 00000100          *   rts55h.lib : vectors.obj (vectors)

John,

OK, looks like there's no problem there.  The NOLOAD SECTION comment means that the RTS vector table is not contained in your .out file.   So you are booting using your Reset vector and stack definition.

I think I know what the problem might be.  The boot ROM has a vector table and that is what is getting used at Reset.  Here is a Wiki article on how to change the stack mode to the type you want to use: http://processors.wiki.ti.com/index.php/55x_FAQ#How_do_I_change_stack_modes.3F.  Let me know if this works for you.

Regards.

Hello Tommy,

Yes - that could very well be the problem.  I didn't know you had to soft boot to enable other stack modes.

BTW - is there a location where all of the bit mask flags are defined for the stack mode you want to choose?  I've seen a couple of different bit flag definitions but I don't see those really defined anywhere.

I will try the above and let you know - but looks like that is definitely the issue.  If the processor reads the default stack mode from the boot ROM, and that can't be changed other than by the above which includes a soft-boot, then that is definitely an issue.

Thanks,
johnw

John,

Yea, I had forgotten about the fact that the new devices have to run the bootloader and thus use the pre-defined Reset vector.  On older devices you could run from external flash, but that option isn't available anymore.  The Wiki article I pointed you too explains the situation.

I had to look the stack mode info up today.  The generic information is described in the v3.x CPU Reference Guide (http://www-s.ti.com/sc/techlit/swpu073), sec 4.2.  This points to the Assembly Language Tool UG (http://www-s.ti.com/sc/techlit/spru280) for the definition of .ivec and it's options on page 4-64.

Regards.

Tommy,

I was looking at some code the other day - in the reset vector, instead of C54X_STK, things were defined there like:  FAST_STK | DATA_PTR_DIR(?), etc.  They seem to be self-explanatory, but it would be nice to see all of these defined somewhere and what exactly they mean.

I assume C54X_STK and FAST_STK are not the same, and that USE_RETA and FAST_STK are the same, but without a concise reference it's just an educated guess.

Thanks,
johnw

John,

The Assembly Language Tools RG that I pointed you to has that information under the .ivec description.  The CPU RG describes the options also, but don't have the definitions. 

The options that you are showing that are OR'd together look like options for the C55x+ CPU.  This is an enhanced core that was only implemented in some custom chips we made for large volume customers.  The only options available for the C55x CPU in the DSPs we sell are:
;        USE_RETA     : 2x16-bit fast return mode (RETA used)
;        NO_RETA      : 2x16-bit slow return mode (RETA not used)
;        C54X_STK     : 32-bit fast return mode
This is taken from the vectors.asm file from the CSL package.

Regards.

Tommy,

Hmmm, OK - guess it isn't always clear what is for the C55X+ and what is not.

Also - I did get the C54X_STK running - I have verified that.  The soft reset was what I was missing.  So, thanks for pointing out that example code.  I had looked at that in the past - but no where in the docs was it mentioned about the soft reset issue - the only place I saw that was on the Wiki.  Also - in the example code - it is mentioned to put the '05 EVM board into 'no-boot' mode - I don't see that option on the eZdsp 'c5515 board - so I assume that is not an issue on the eZdsp.

Now, I just need to learn how to deal with the issue of keeping both of the stacks synchronized since I am working on stack 'fix-ups'.

As far as you know - on the issues of context switching for both calls and ISR's - is that documented correctly in the CPU v.3.x Guide?  As far as a context switch from a function call - I have verified the operation of XSSP and XSP w.r.t. the return addr that gets loaded into the PC - but I have not verified DBSTAT, nor the status registers, ST0-ST3 as of yet.  

Thanks,
John W.

John,

The No Boot mode is not an option on the newer devices, so not an issue.  The code looks like it was written for the C5502 EVM.

As far as I know, the CPU v3.x RG is correct.  I have asked about the CPU advisory document for the v3.3 CPU, but no one in the C5000 Apps team seems to know about such a document.  They are continuing to investigate through the CPU design team.

Regards.

Tommy,

OK - I looked at the schematic from Spectrum Digital for the 'c5515 EVM - didn't see any reference to No Boot - so - thanks for that info.

Also - thanks for asking regarding an updated CPU v3.3 advisory document - it would be nice to know what is no longer an issue since 2.x.

Best Regards,
johnw

Hello Tommy,

Any update on the CPU 3.3 Advisory document?

Also - do you know of any assembly code examples that use C54X_STK?

Thanks,
johnw

John,

Nothing yet on the CPU 3.3 Advisor document from the C5500 Product team yet.  I'll ping them again.

I don't know of any current code examples.  My understanding is that this mode was implemented to ease migration of C54x code base to C55x based devices when they were first released. (about 10 years ago).  The C55x based stack modes (USE_RETA and NO_RETA) are more memory efficient, so these are the recommended modes to use.

Perhaps someone else in the Community might have something.  Any volunteers?

Regards.

Tommy,

OK - thanks for this!  I will await to hear any news regarding the CPU v.3.3 Advisory Doc.

Regards,
John W.

John,

I found out that there isn't an official document yet on v3.3 CPU advisories, but this Wiki page has a preliminary document which contains the information you were looking for:

http://processors.wiki.ti.com/index.php/55x_FAQ#Are_there_CPU_Advisories_for_the_new_v3.3_CPU_used_in_the_TMS320c5504.2F05.2F14.2F15_devices.3F

Look at FAQ #15.

Regards.

Tommy,

OK - will take a look at that.  Interesting to see that TI is 'tightening security' so to speak on this site.

Can you also take a look at the SSP question I posted?  

Thanks,
John W.

John,

What do you mean by "tightening security"?

I think I just saw your other post. 

Regards.

TommyG,

I think it was my computer doing that - not TI's site - my bad.

Thanks!
John W. 

John W,

In order to successfully change stack modes you need to execute a soft reset as mentioned in this FAQ:

http://processors.wiki.ti.com/index.php/55x_FAQ#How_do_I_change_stack_modes.3F

Have you done it this way?  If not, that would explain why it isn't behaving the way you expect.

Brad

Hello Brad,

Yes, earlier in this thread - that was uncovered by Tommy.  I have implemented that procedure to implement 'slow' stack mode which really isn't 'slow' IMHO.

Thanks,
John W.