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.

C6657 EMIF Boot - SP?

Hi,

I'm modifying our bootstrap code and need to setup the stack. The first stage boot has no 'main' and no c_init - so we are doing no stack initialisation here.
I have a couple of questions if I may:
1. I note that by default - the SP appears to be in a sensible area - I have observed 0x008F,FA20. This does not appear to be documented anywhere? Can I rely on this?
2. If I initialise the SP to 0x008F,FFF0 (16 byte aligned) then our boot code fails. But if I set the SP to 0x008F,FF00 (256 byte aligned) then boot succeeds. Is there a reason for this?
(Documentation indicates the need for 16 byte alignment and stack growing down)
Thanks, Ian
  • Ian,

    SP is the compiler's use of the B15 register. It is uninitialized after power-up and reset, but the Boot ROM will likely be using this register. If there is any guaranteed value of B15/SP, it would be documented in the Bootloader User's Guide. The value may vary from one boot mode to the next, and it may vary if we modify the boot code or if a different process of booting occurs.

    You should not assume this register is at a fixed value unless it is clearly documented in the Bootloader User's Guide. If it is not, then you should not assume a value for it.

    If you set the SP to any other 16-byte-aligned value between 0x008F,FF00-0x008F,FFF0 will it also work?

    My guess is that the failure in the boot code is probably due to some interference with a hard-coded address such as the BOOT_MAGIC_NUMBER, and not the alignment.

    If setting the SP to a value is not sufficient, then it will be helpful if you can do some debug to determine at which point your boot code fails and describe that failure.

    Regards,
    RandyP

  • Hi Randy,

    I think I got to the bottom of this.

    At the start of a function - the C compiler generates asm to:

    1) store the return address - 4 bytes

    2) decrement the stack to reserve space for the local vars

    I was then setting the stack to 8F,FFF0 which was reserving insufficient space for the 4 32bit local vars in use.

    I can see the boot_table remnant in memory - but I doubt that writing to it causes an issue at this point (we have already vectored to 7000,0000 for EMIF boot at this point)

    Ian

  • Ian,

    Good work getting to the resolution of this. And thank you for reporting it back. This will help future readers who may have a similar problem.

    Regards,
    RandyP