Skip to main content
Visitor II
January 13, 2003
Question

Cosmic compiler and problem with stack pointer.

  • January 13, 2003
  • 2 replies
  • 853 views
Posted on January 13, 2003 at 20:32

Cosmic compiler and problem with stack pointer.

    This topic has been closed for replies.

    2 replies

    eriklmsAuthor
    Visitor II
    January 10, 2003
    Posted on January 10, 2003 at 20:52

    Hello,

    At the moment I am writing some firmware upgrade routines. I use mixed ASM and C language. The first routine is attached below onto this message. This routine works very well, but I had to use the 'RSP' (Reset stack pointer) to get it working. The routine returns a 0x43 (ECMD) if I don't use 'RSP'. Normally I can't just reset the stack pointer in the ASM-part, but it doesn't matter in this case because the whole procedure (with reprogramming) will end with a watchdog activation (and this will cause a device reset). So I don't have to return to the main-program which called this routine.

    But what else can go wrong if I reset the stack pointer? I am using the USB library from ST to upgrade/update the firmware by USB. Will the USB communication fail after RSP (everything seems to work!?!?)? What other things does the compiler store on the stack than return addresses?

    How would you solve this problem? Does anyone have a better sollution? I don't want to use the standard FDU-routines from ST, because I have to add some extra functions.

    Kind regards,

    Erik

    void EraseSector(void)

    {

    #asm

    ;Enable Vpp & turn 'erased' LED off

    BSET _PBDR,#1

    BRES _PADR,#4

    BSET _PADR,#6

    #endasm

    mSecDelay(100);

    #asm

    FLASH_ECMD: EQU $FF

    FLASH_SECT: EQU $FE

    FLASH_PTRL: EQU $FD

    FLASH_PTRH: EQU $FC

    FLASH_ENDL: EQU $FB

    FLASH_ENDH: EQU $FA

    FLASH_DATA: EQU $F9

    FLASH_FREQ: EQU $F8

    FREQ: equ 1 ; Set to 1 for optimum programming time

    ;This function isn't allowed!!

    RSP

    ;Enable FCSR

    LD A,#0x56

    LD _FCSR,A

    LD A,#0xAE

    LD _FCSR,A

    ;.FLASH_EraseSector

    LD A,#1

    LD FLASH_SECT,A ; A = Sector to erase or option bytes

    LD FLASH_PTRH,A

    LD A,#3

    LD FLASH_ECMD,A ; 03h = Sector erasing command

    LD FLASH_PTRL,A

    LD A,#6

    LD FLASH_FREQ,A ; Set to 1 for optimum erasing time (see note 1Page 20)

    erase:

    ; LD X,#0x7F ; Watchdog update if used in USER application

    ; LD _WDGCR,X

    LD _FCSR,A ; Dummy write of FCSR = launch HDFlash command

    BTJT FLASH_ECMD,#7,erase ; Erase not yet completed => continue

    LD A,FLASH_ECMD ; Return the status code in A reg.

    LD _IOChar,A

    ;Turn 'erased' led on

    BRES _PBDR,#1

    #endasm

    ;Return ECMD code via USB

    WriteUSBChar(IOChar);

    ;Loop forever --> firmware update will be inserted and

    ;wdg will be set after update --> device reset

    while (1) ;

    }
    Visitor II
    January 13, 2003
    Posted on January 13, 2003 at 20:32

    I'm not very familliar with the USB library, but because your routine ends up with a watchdog reset, it should not be a problem to reset the stack pointer.

    The MCU is going to reset your stack pointer anyway during the reset phase.

    But this does not seem very clean to me...

    do you understand why do you need to reset the stack pointer?

    are you using a stack based memory model?

    is your stack full of function return addresses?

    are you using the stack to save data?