We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
Are all stack sizes reasonable?
Any use of dynamic memory?
Is it just RAM data that gets corrupted, or does the program crash in any way?
Hi..
The stack size is within the limits.
Each task is allocated with its own stack.
The Dynamic memory is not used.
Only few bytes of RAM data is getting corrupted.
Thank you
maybe this is what's wrong: it could be that the memory maps of the 2 binaries overlap, namely: some address(es) used in boot mode are also used in application mode. this could be deadly if your bootloader does not really transfer all control to the application, but rather continues to handle some interrupts, but example.
Hi,
Thanks for the reply.
None of the interrupts are used in the bootloader. All the pheripherals functions are in the polling mode
And how do the address of these variables correlate with the map files for the boot loader and the application? And where are they located in relation to stacks, or buffers/arrays you use?
Do you mix assembler and C, so the assembler code may garble any unexpected register, either destroying a value or making the processor use the incorrect address when reading/writing a variable?
does it also go wrong if you burn your application at the entry point to flash, hence if you don't use a bootloader?
It is working fine if i load the Application code at the entry point to flash.
It will also work fine if i use the LPC2300.s (Copyright 2006) in the bootloader
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?