Hi
We have two different projects bootloader(without RTX kernal) and Application code (with RTX Kernal).When we laod the bootlaoder and the application code, part of the RAM data will be corrupted.Please guide to resolve this problem.
Software interrupts is not required for the bootlaoder we have not shifted the interrupt address, we are using the same interrupt address
Meomory mapping is as below Bootloader 0 - 0x2000 Application code starts from 0x2000
Thank you Harish
Whos RAM data gets corrupted? Which startup file is responsible for initializing this RAM data? When does it get corrupted?
The boot loader would normally setup whatever RAM it needs. Then jump to the application, who will take over the ownership of all RAM and initialize again.
An alternative is to reserve a small part of the RAM for the boot loader, to allow the boot loader so send information to the application. This could let the boot loader complain if it detects multiple watchdog resets, possibly informing the application to try to report an alarm and switch to a fail-safe mode with limited functionality.
Thanks for the reply
Ram data of the application is getting corrupted. The Ram is initialized by the Application code.
As per our observation The Ram data is not getting corrupted in the single step The Ram data is getting corrupted when the application is allowed to Run normally
The Above problem started when we upgraded our startup file from 2006 version to 2007 version(for both bootloader and Application code).
Before this upgradation both the bootloader and application code were working fine.
Hi Harish,
(I don't know much about this.)
Just curious about what are the below settings of both your bootloader and application?
UND_Stack_Size EQU 0x00000000 SVC_Stack_Size EQU 0x00000008 ABT_Stack_Size EQU 0x00000000 FIQ_Stack_Size EQU 0x00000000 IRQ_Stack_Size EQU 0x00000100 USR_Stack_Size EQU 0x00000400
Hi John,
thanks for your reply
The settings for the bootloader and applicaiton code are given below
Bootloader UND_Stack_Size EQU 0x00000000 SVC_Stack_Size EQU 0x00000008 ABT_Stack_Size EQU 0x00000000 FIQ_Stack_Size EQU 0x00000000 IRQ_Stack_Size EQU 0x00000100 USR_Stack_Size EQU 0x00000400
Application code UND_Stack_Size EQU 0x00000000 SVC_Stack_Size EQU 0x00000020 ABT_Stack_Size EQU 0x00000000 FIQ_Stack_Size EQU 0x00000000 IRQ_Stack_Size EQU 0x00000100 USR_Stack_Size EQU 0x00000200
The memory for variables, arrays of both bootloader and Application code are allocated in the same RAM area,
Since bootloader is not enabled with the interrupts, The Control will not jump back to the bootloader once the applicaiton code starts running.
diff between the startup files...?
maybe you don't configure external RAM (do you use it...?) correctly?
Could you confirm that, when your application starts, it is running in the Supervisor mode?
Hi ,
The difference is
1. External memory control functionality is added 2. power control for the pheripherals is added 3. Some part of the startup code is modified
we are not using any external RAM .. External flash is used
The Application starts with the supervisor mode and jumps to the user mode once the control comes to main function
you must make sure that both your bootloader and application start in supervisor mode, otherwise stacks will not be configured correctly. make your jump to application function a SWI function.
"The memory for variables, arrays of both bootloader and Application code are allocated in the same RAM area,"
I did expect that. But I was thinking about their relative location, according to the map file. Is your corrupted variables stored directly before or after a stack or an array/buffer, in which case an overflow/underflow would reach into the corrupted variables?
So, when the application comes to main(), is the R13(SP) of supervisor mode 0x40001570?
Hi,
Thanks for your reply..
Only 3 bytes of the buffer is getting corrupted. The buffer is of size 200 bytes, it is used for communication between the boards The Corrutped location is alomost at the centre of the buffer,the corruped location is almost at the centre of the buffer.
We have already verified the above in the map file, it is not getting corrupted due to the overflow or underflow of any other variables
=> So, when the application comes to main(), is the R13(SP) of supervisor mode 0x40001570? <=
Sorry for that I made a mistake here. I do need to learn something about Memory Usage.
=> Each task is allocated with its own stack. <=
What does this mean? All tasks are created by os_tsk_create_user() function?
when creating RTX tasks, you can either provide your own buffer to store the stack or rely on the buffer provided by the kernel ('os_tsk_create').
Startup file with/without PRESERVE8. Data Align?
View all questions in Keil forum