• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 788 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CPU mode change and banked registers

Tero Vihavainen
Prodigy 60 points
Other Parts Discussed in Thread: TMS570LS1227, HALCOGEN, RM46L852, SEGGER

I have an issue with the initialisation of stack pointers after reset.

I have a following simple code that should initialise stack pointers of different CPU modes:

(1)        cps     #IRQ_MODE        
(2)        LDR     sp, =SFE(IRQ_STACK)     ; End of IRQ_STACK
(3)        cps     #FIQ_MODE        
(4)        LDR     sp, =SFE(FIQ_STACK)     ; End of FIQ_STACK
(5)        cps     #SYS_MODE        
(6)        LDR     sp, =SFE(CSTACK)        ; End of CSTACK
 
The four first lines works fine - those initialises R13_irg and R13_fiq correctly.
The problem occurs once I execute mode change to SYS_MODE (line 5):
 
Debugger shows that the mode change into the SYS_MODE affects (changes values) to following registers: R12, R13 (SP), R14, R12_fiq, R13_fiq, R14_fiq, SPSR_fiq,  R12_usr, R13_usr, R14_usr.
 
If I continue SW execution from this to main(), FIQ mode's stack pointer is out of range (debugger warns me about this).
 
I can't understand the reason why the mode change changes values in FIQ register banks. I'd priciate if someone could advice me?
 
An example of a proper stack initialisation routine would be nice.
 
I'm using TI's development kit with TMS570LS1227 processor
  • 0
    TI__Mastermind 22375 points

    Tero.

    Are you using Halcogen to generate the startup code for your device?
    If not I will highly suggest to do so. Here is the link. http://www.ti.com/tool/halcogen
    Because of the lockstep safety feature in this devices, there are some mandatory steps to be done during boot.

    Halcogen creates an asm file (sys_core.asm) that takes care of stack initialization.
    Here is the code for information:

    ;-------------------------------------------------------------------------------
    ; Initialize Stack Pointers

    .def _coreInitStackPointer_
    .asmfunc

    _coreInitStackPointer_

    cps #17
    ldr sp, fiqSp
    cps #18
    ldr sp, irqSp
    cps #19
    ldr sp, svcSp
    cps #23
    ldr sp, abortSp
    cps #27
    ldr sp, undefSp
    cps #31
    ldr sp, userSp
    bx lr

    userSp  .word 0x08000000+0x00001000
    svcSp   .word 0x08000000+0x00001000+0x00000100
    fiqSp   .word 0x08000000+0x00001000+0x00000100+0x00000100
    irqSp   .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100
    abortSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100
    undefSp .word 0x08000000+0x00001000+0x00000100+0x00000100+0x00000100+0x00000100+0x00000100

    .endasmfunc

     

    Please let me know if this is helpful.

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 60 points

    Thanks for the reply,

    Halcogen seems to be quite powerfull tool, unfortunately it is not SIL-3 qualified and therefore can not be used in our project. I have also noticed that it produces some bugs and other not so nice features into the code.

    However, I have analyzed also the code it produces for stack initialisation (same as you posted). There happens a similar issue once the CPU is moved into the USER mode on line "cps #31": The contents of R13_fiq and R14_fiq are changed ... WHY? can't understand the reason.

  • 0 in reply to Tero Vihavainen
    Prodigy 60 points

    I got a development board with another type of Hercules processor: RM46.

    With RM46 board my stack pointer initialization routine works without any problems. It seems that TMS570LS1227 behaves different way than RM46L852 model even if it shouldn't as I understood.

    It seems that, with TMS570LS1227, some CPU mode changes affects to banked registers of some other modes. RM46L852 doesn't behave like this.

    Is there some good explanation for this? ... or am I just doing something wrong way.

  • 0 in reply to Tero Vihavainen
    TI__Mastermind 22375 points

    Tero,

    I did some check on my side and I see similar results.
    The problem seems to be in CCS and the way the CPU Register/banked registers are displayed.
    The fact that it is working for another part is a good sign.

    The TMS570LS1227 is used in production by many customers so the problem can't be hardware.

    I will have to run additional test in CCS and other debug environment to find out the root cause.

  • 0 in reply to Jean-Marc Mifsud
    Prodigy 60 points

    Hi and thanks for your effort,

    I think, the problem can't be CCS since I see the unwanted behavior also with IAR's tools. However, I'm using TI's built in JTAG emulator as an interface.

     

     

  • 0 in reply to Tero Vihavainen
    TI__Mastermind 22375 points

    Tero,

    I should have been more precise in my last post when I was saying the problem may be in CCS.
    The problem is certainly in the R4 driver used by CCS to access the part.
    As far as I know, the XDS100 driver used in IAR is the TI driver. So I'm not surprise to see that it is also not working in IAR.
    I will driver using a segger driver in IAR and CCS environment. As soon as I have a result I will let you know.

  • 0 in reply to Jean-Marc Mifsud
    TI__Mastermind 22375 points

    Tero,

    I did a test using the J-LINK Segger under CCS5.5
    The problem is not visible. So this confirms my assumption that we have a driver issue.
    This may affect the XDS100, XDS560 emulator and certainly XDS510 class emulator (To be tested)

    I will contact our Emulation team to see what can be done.

    As I said in a previous post, this problem does not affect the code execution. It is only a debug display issue.