Application/Bootloader stack size

[ngsoftuser]

Hi all,

I recently finished development of firmware upgrade for MC9S08DZ60 using bootloader using UART via GPRS modem.
My application works great with stack size of 0x280 bytes.
My bootloader has stack size of 0x250 bytes.
I have noticed weird behavior in my application when it is loaded from BL:
I have the following stack:

#define MODEM_RESPONSE_BUFF_SIZE 0xD2
typedef struct _MODEM_RESPONSE

{

    byte PrevLen;

    byte WaitForRestOfMessage:1;

    byte ResponseIndex;

    byte Response[MODEM_RESPONSE_BUFF_SIZE];

    byte TempResponse[MODEM_RESPONSE_BUFF_SIZE];

}MODEM_RESPONSE;

The weird behavior is that in some cases when I clear Response[] buff using MEMSET(), TempResponse[] buff data is being set with garbage.
I was thinking that maybe it is related to the fact that the BL stack size is small and needs to be increased. The problem is that when I set BL stack size to the same stack size of the app the application also starts having weird behaviors (UART).

Which stack size effects the app stack size, the one in the app prm or the one in the BL prm?

Thanks.

[ngsoftuser · Accepted solution]

Well I basically solved it by calling Application's _Startup code from Bootloader's _EntryPoint instead of calling application main() from bootloader _Startup.

[ZhangJennie]

STACKSIZE value setting in prm file effects the project stack size

[ngsoftuser]

I know it is the STACKSIZE wich sets the size of the stack. Since I have two prms,in bootloader project and application project, which one of the two should i set?

[weapon]

Hi,

Actually, the actual stack size is determined by the initial value of SP register, generally, SP will be assigned in start08.C, compiler will calcualte the initial value for  SP register based on PRM file.

In your project, MCU will use the stack size of bootloader firstly because MCU is started from bootloader. if later the application is started by bootloader, then SP will be reassigned based on

PRM file of the applicaiton.

In one word,  when bootloader is running,the stack size is from PRM file of bootloader, when applicaiton is runing, the stack  size is from PRM file of application, as SP is modified during the transfer

from bootloader to application.

Hope my reply can be helpful. Have a nice day.

[ngsoftuser]

Hello Weiping,
Thank you for your reply.

My bootloader always starts before application.

In _Startup() it calls app main by checking 2 bytes in the EEPROM before JMP opcode to its main or to app main.

So if I understand you correct, the used STACKSIZE will always be the bootloader's and not the app.

My problem is that when my app starts by boot loader i don't see the same behavior when it starts directly.
In case of bad behavior, some buffers are being garbage when clearing others.  When i decrement their size it works.

The problem is that I can't decrease the buff size.

Another issue I experiencing is that some counters are being also garbage when I call strstr, even though I increased the stack size to the
same on in the application.

Is there any special requirement when starting from bootkloader or not in case of buffers allocation/size/init?

I wasted about 3 weeks in trying to solve this issue but NADA.

What I don't understand is why my code works ok when not starting from bootloader but has bad behavior when it does.

Thanks

.

[bigmac]

Hello,

eran yasso wrote:

My bootloader always starts before application.

In _Startup() it calls app main by checking 2 bytes in the EEPROM before JMP opcode to its main or to app main..

If this is what you are actually doing, it is wrong.  When the application code is to be engaged, the bootloader will need to directly jump to the address of _Startup() for the application, given by the contents of the reset vector for the application.  Otherwise, the stack pointer will not be initialised to the position required by the application, and ANSI initialisation of global variables used by the application will not occur.

Therefore, the bootloader will require to sense the application reset vector data and transfer this to a location within the unprotected application flash.  Usually, the application reset vector would be placed immediately below the bootloader code block, and above the redirected application vector table data.

Regards,

Mac