Hi,

I am developing software for the STR912FAW44 using the IAR Embedded Workbench version 5.50.5. I am facing a problem when the code size exceeds about 64K. The code does not execute from the flash. The same code works when I debug it using a the J-Link debugger. But when I download it using the J-Link debugger it doesn’t work. I tried both the builds i.e. debug and release. The only difference between these 2 is that the “DEBUG” is defined in the debug build and NOT in the release build.

I have set the bank 0 as a boot bank and don’t have a boot loader. I believe the debugger downloads the code to the bank 0. The bank 0 address is set as 0x0000. If I comment out some code it works. I observed the code size ( Code and Read only data) in the map file and observed that the code doesn’t work if the size exceeds about 64K. The STR912FAW44 has 512K bytes of flash in the bank 0 and it’s divided into 8 sectors. Each sector is 64K. I have different licensed dongles and tried with them .
Is there any issue in downloading the code or building it if the code size crosses the first sector boundary?

I use the FreeRTOS ver 7.0.1 and use the initialization files 91x_init.s and 91x_vect.s come with that. I use the heap_2.c implementation from the FreeRTOS for heap. It allocates the heap as a fixed size array. Also, I have 2 projects:
1.FreeRTOS project is built as a library using “C” complier and
2.The application project built as an executable with the “Embedded C++” compiler option.

The Flash memory configuration used is:
FMI_BankRemapConfig(4, 2, 0, 0x80000 ); /* FMI_BootBankSize, FMI_NonBootBankSize, FMI_BootBankAddress, FMI_NonBootBankAddress */
FMI_Config( FMI_READ_WAIT_STATE_2, FMI_WRITE_WAIT_STATE_0, FMI_PWD_ENABLE, FMI_LVD_ENABLE, FMI_FREQ_HIGH );

Thanks for the help you provide.

One thing I remember having a problem with this part was you need to make sure the startup file loads low enough in memory, the flash register power up with a predefined amount of flash, which is much smaller than you actually have, and if the start-up code is outside that, then the CPU will address-error when accessing memory outside that initial bound until the startup adjusts those registers. If you run under the debugger, the debugging executive will have done this automatically, so it won't have caused the problem.

Sorry, I can't help you with the technical specifics of the chip boot process or memory lay out. I thought maybe the vector table was using direct branches to the interrupt handler functions, and the when the code size grew too large, the branch distance was too far away. However, having looked at the files you reference, that is not the case as indirect 32 bit branches are used, which will always be fine.

Regards.

Hi Richard,

Thanks for the response. It looks like that is the case. I was looking into the map file to check the code size. The part of the code that exceeds the 64KB boundry is:
Section Kind Address Size Object
Initializer bytes ro data 0x00009706 0x75fe
- 0x00010d04 0x10b6c

So the initializer bytes are crossing the boundry. How do I force the linker to place it in the lower memory area?

Thanks

What I did was to edit the linker control file and defined a new region of memory for initialization code, that was limited to the bottom 16k of memory, and placed the startup module into that region.

Richard,

The linker file fix worked for me, although I did it differently. I just made the STR9 init module as the first module to be put in the ROM, after the interrupt vector.

Thank you very much; this was a great help.