CSTACK issue with IAP

[idealsim]

Posted on February 18, 2016 at 13:37

Hi, i'm trying to make an app for my card to introduce IAP (update by ethernet, http in my case)

To do this, i'm starting from the example give by stm32 cube STM324x9I_EVAL\Applications\LwIP\LwIP_IAP\EWARM (I test with STM32439I-EVAL2). The example work fine (i can load the binaries give in example). But

now, I want to compile another project (STM324x9I_EVAL\Applications\STemWin\STemWin_HelloWorld\EWARM) to load it with IAP.

On the IAP example, they redefine the start address like this :

#define USER_FLASH_FIRST_PAGE_ADDRESS 0x08020000

On the second example (that I want to load with IAP) I need to modify the project to start at 0x08020000, to do this I change this on IAR :

In file system_stm32f4xx.c I do this :

#define VECT_TAB_OFFSET  0x20000

And after in the code they have this instruction :

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

FLASH_BASE is equal to

#define FLASH_BASE            ((uint32_t)0x08000000)

The map generated with the linker :

*******************************************************************************

*** PLACEMENT SUMMARY

***

''A1'':  place at 0x08020000 { ro section .intvec };

''P1'':  place in [from 0x08020000 to 0x081fffff] { ro };

''P2'':  place in [from 0x20000000 to 0x2002ffff] { rw, block CSTACK, block HEAP };

  Section            Kind        Address     Size  Object

  -------            ----        -------     ----  ------

''A1'':                                       0x1ac

  .intvec            ro code  0x08020000    0x1ac  startup_stm32f429xx.o [1]

                            - 0x080201ac    0x1ac

''P1'':                                      0xddc3

  .text              ro code  0x080201ac   0x11fc  LCDConf_stm324x9i_eval_MB1063.o [1]

If i launch the card and load the file with IAP, it's ok, but at reboot the system doesn't start the app. To debug it i do this (in the IAP) :

main :

uint32_t test,calcul;

.

.

.

test=(*(__IO uint32_t*)USER_FLASH_FIRST_PAGE_ADDRESS);

    calcul = test & 0x2FFE0000;

    /* Check if valid stack address (RAM address) then jump to user application */

    if (calcul  == 0x20000000)

    {

      /* Jump to user application */

      JumpAddress = *(__IO uint32_t*) (USER_FLASH_FIRST_PAGE_ADDRESS + 4);

They check the stack address, in my case if I use the bin that I make, calcul is equal to 0x20020000 

à

 the same offset that I add for the flash. If i remove the test the app start correctly. In the map file (downloaded app) : CSTACK                      0x2002bd60   0x2000  <Block>    CSTACK           uninit   0x2002bd60   0x2000  <Block tail>                            - 0x2002dd60  0x2dd60

Here we can see the stack address start at 0x2002xxxx, do you know how i can resolve this please ?

[Tesla DeLorean]

Posted on February 18, 2016 at 14:57

Here we can see the stack address start at 0x2002xxxx, do you know how i can resolve this please ?

Change the test so it accepts a stack placed anywhere in the larger SRAM?The test currently assumes a device with 128KB of SRAM, but would have issues with a valid 0x20020000 starting point (stack predecrements)

[idealsim]

Posted on February 18, 2016 at 15:14

Thanks for your reply. But i didn't catch all you said.

In fact if i modify the test to compare with this 0x20020000, it's ok. That i didn't understand is why i didn't have the address of stack at 0x20000000 (SRAM1 112 KB) in the loaded app. 0x2002 0000 (SRAM3 64 KB) --> I loose some place ? Let me know if i'm wrong. How do you compute the 128KB of RAM

[Tesla DeLorean]

Posted on February 18, 2016 at 19:33

The test is a crude one to ensure that the stack pointer falls in SRAM, and is not 0xFFFFFFFF, which would indicate a blank flash area instead of code.

You are masking with ~0x1FFFF ie 128KB-1 A better, or clearer test, would look like this

test=(*(__IO uint32_t*)USER_FLASH_FIRST_PAGE_ADDRESS);
/* Check if valid stack address (RAM address) then jump to user application */
if ((test >= 0x20000000) && (test <= 0x20030000)) // 192KB Device
{
/* Jump to user application */
JumpAddress = *(__IO uint32_t*) (USER_FLASH_FIRST_PAGE_ADDRESS + 4);

It could also check if it is 32-bit aligned too. I didn't write the IAP examples, so they are what they are, you need to understand the purpose of test, rather than the specific implementation details. I, personally, checksum my firmware images, because that ensures they are complete, and intact, rather than just look at the first block.

[idealsim]

Posted on February 19, 2016 at 14:31

Thanks a lot for your precisions. Just a little point, if my cstack start start at address 0x20020000 and the end of the stack (in the doc) is 0x2003000, my loaded app can't use more than 64Kb --> let me know if i'm true. In this case, if my app need more RAM how i can modify my loaded project to ensure this ? 

Otherwise, i'm agree with you about the crc, i can use this for my app : 

https://www.iar.com/support/tech-notes/general/calculate-crc32-as-in-stm32-hardware-v.5.50-and-later/

[Tesla DeLorean]

Posted on February 19, 2016 at 14:41

Well you want to let the linker do it's job and place the size heap and stack allocation you specify. Provided you tell the linker it has 0x30000 bytes at 0x20000000, then exactly how much gets used depends on the size of your statics, and the stack/heap.

Keil and IAR usually assign the stack address in the linker. GNU/GCC implementations tend to just define it as the end of SRAM and let it descend from there. If you nail it to 0x20020000 then you're likely to create a 64K void, which you could then describe as another memory region.I'm not sure you have an issue with wasting space, rather you're just using all of it.