--- In l..., groups@... wrote:
>
> Hi,
>
> I've ported my bootloader from the LPC24xx family to the LPC17xx family
> and encounter strange problems with uVision 4:
>
> In my bootloader I check if the application (located at 0x6000) is ok
> and jump to it as follows:
>
> #define APP_START_ADDR 0x6000
>
> typedef void (*APP_MAIN)(void);
> static APP_MAIN app_main;
>
> int main(void)
> {
> :
> // checking app data area at 6000
> :
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
> }
>
> This seems to work as expected (the application is build with a scatter
> file loading all flash data at 0x6000, so the Reset_Handler in the
> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
> my application (I was able to do that with the LPC24xx where I directly
> could jump to 0x6000).
>
> When loading the application project, going into the debugger and
> setting a breakpoint to main() and starting the application by pressing
> the run button, the debugger stops at main() shortly and terminates the
> debug session immediately then by returning to the normal compile mode.
> If I set the option "Load Application at Startup" in the "Options for
> Target 'Debug'" I see exactly the same behaviour.
>
> Does anybody have a idea how to debug my LPC17xx application ??
>
> Any help is highly appreciated!
>
> Best regards
> Herbert
>
I thought for Thumb code, branch destination addresses had to be odd. have you
tried adding +5 instead of +4?
Richard
LPC2138 /01 and Non/01 versions
Started by ●January 30, 2010
Reply by ●February 3, 20102010-02-03
Reply by ●February 4, 20102010-02-04
Hi:
I just finished a bootloader for LPC1700 and it is working without problem.
I have three targets in uVision: Debug, Release and Bootloader.
Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
Release target places all the application at 0x6000.
Bootloader is placed at 0x00000000
The Release application only works when called from the bootloader.
Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
What I do is use the debug target to debug the application.
Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
Regards,
Alex
--- In l..., groups@... wrote:
>
> Hi,
>
> I've ported my bootloader from the LPC24xx family to the LPC17xx family
> and encounter strange problems with uVision 4:
>
> In my bootloader I check if the application (located at 0x6000) is ok
> and jump to it as follows:
>
> #define APP_START_ADDR 0x6000
>
> typedef void (*APP_MAIN)(void);
> static APP_MAIN app_main;
>
> int main(void)
> {
> :
> // checking app data area at 6000
> :
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
> }
>
> This seems to work as expected (the application is build with a scatter
> file loading all flash data at 0x6000, so the Reset_Handler in the
> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
> my application (I was able to do that with the LPC24xx where I directly
> could jump to 0x6000).
>
> When loading the application project, going into the debugger and
> setting a breakpoint to main() and starting the application by pressing
> the run button, the debugger stops at main() shortly and terminates the
> debug session immediately then by returning to the normal compile mode.
> If I set the option "Load Application at Startup" in the "Options for
> Target 'Debug'" I see exactly the same behaviour.
>
> Does anybody have a idea how to debug my LPC17xx application ??
>
> Any help is highly appreciated!
>
> Best regards
> Herbert
>
I just finished a bootloader for LPC1700 and it is working without problem.
I have three targets in uVision: Debug, Release and Bootloader.
Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
Release target places all the application at 0x6000.
Bootloader is placed at 0x00000000
The Release application only works when called from the bootloader.
Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
What I do is use the debug target to debug the application.
Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
Regards,
Alex
--- In l..., groups@... wrote:
>
> Hi,
>
> I've ported my bootloader from the LPC24xx family to the LPC17xx family
> and encounter strange problems with uVision 4:
>
> In my bootloader I check if the application (located at 0x6000) is ok
> and jump to it as follows:
>
> #define APP_START_ADDR 0x6000
>
> typedef void (*APP_MAIN)(void);
> static APP_MAIN app_main;
>
> int main(void)
> {
> :
> // checking app data area at 6000
> :
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
> }
>
> This seems to work as expected (the application is build with a scatter
> file loading all flash data at 0x6000, so the Reset_Handler in the
> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
> my application (I was able to do that with the LPC24xx where I directly
> could jump to 0x6000).
>
> When loading the application project, going into the debugger and
> setting a breakpoint to main() and starting the application by pressing
> the run button, the debugger stops at main() shortly and terminates the
> debug session immediately then by returning to the normal compile mode.
> If I set the option "Load Application at Startup" in the "Options for
> Target 'Debug'" I see exactly the same behaviour.
>
> Does anybody have a idea how to debug my LPC17xx application ??
>
> Any help is highly appreciated!
>
> Best regards
> Herbert
>
Reply by ●February 4, 20102010-02-04
rtstofer schrieb:
> --- In l..., groups@... wrote:
>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>>
>
> I thought for Thumb code, branch destination addresses had to be odd. have you tried adding +5 instead of +4?
>
> Richard
>
Richard, thanks for your suggestion, but (APP_START_ADDR + 4) contains
the *pointer* to the Reset_Handler (which I load into the app_main
variable by dereferencing the location (APP_START_ADDR + 4) via the "*")
, not the Reset_Handler itself. The Reset_Handler itself *is* located on
a odd address. At APP_START_ADDR the application's stack pointer value
is located followed by the vector table (as it is at any Cortex M3
usually at location 0).
Herbert
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
> --- In l..., groups@... wrote:
>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>>
>
> I thought for Thumb code, branch destination addresses had to be odd. have you tried adding +5 instead of +4?
>
> Richard
>
Richard, thanks for your suggestion, but (APP_START_ADDR + 4) contains
the *pointer* to the Reset_Handler (which I load into the app_main
variable by dereferencing the location (APP_START_ADDR + 4) via the "*")
, not the Reset_Handler itself. The Reset_Handler itself *is* located on
a odd address. At APP_START_ADDR the application's stack pointer value
is located followed by the vector table (as it is at any Cortex M3
usually at location 0).
Herbert
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
Reply by ●February 4, 20102010-02-04
Alex,
thanks for your help. In fact your approach is exactly the same as mine.
I've located the bootloader at 0 and jump to the Reset_Handler location
of the application if the application is valid. I can debug the
bootloader, it does jump to the correct location, the Reset_Handler
seems to call the __scatter.o stuff correctly. I am aware of the stack
pointer issue, this should be ok. If I debug via the bootloader project
the application program seems to run somewhere in the application area
as expected, but I see the assembler instructions only, as the
bootloader project does not know anything about the application source
code / symbols.
When I try to debug via the application project I get the problems
described: Even when I place a breakpoint to the very first assembler
instruction of Reset_Handler (located at 0x00006389) the debugger
terminates immediately after reaching this instruction and returns to
compile mode without issuing any warning or error message. So this seems
to be rather an Keil issue than an issue of my source code as far as I
can see currently, because when debugging via the bootloader project I
can see that the applications Reset_Handler at 0x00006389 *is* called
and calls the __scatter.o stuff.
Any further ideas ???
Best regards
Herbert
alexander_ribero schrieb:
> Hi:
>
> I just finished a bootloader for LPC1700 and it is working without problem.
>
> I have three targets in uVision: Debug, Release and Bootloader.
>
> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>
> Release target places all the application at 0x6000.
>
> Bootloader is placed at 0x00000000
>
> The Release application only works when called from the bootloader.
>
> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>
> What I do is use the debug target to debug the application.
> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>
> Regards,
>
> Alex
> --- In l..., groups@... wrote:
>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>> This seems to work as expected (the application is build with a scatter
>> file loading all flash data at 0x6000, so the Reset_Handler in the
>> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
>> my application (I was able to do that with the LPC24xx where I directly
>> could jump to 0x6000).
>>
>> When loading the application project, going into the debugger and
>> setting a breakpoint to main() and starting the application by pressing
>> the run button, the debugger stops at main() shortly and terminates the
>> debug session immediately then by returning to the normal compile mode.
>> If I set the option "Load Application at Startup" in the "Options for
>> Target 'Debug'" I see exactly the same behaviour.
>>
>> Does anybody have a idea how to debug my LPC17xx application ??
>>
>> Any help is highly appreciated!
>>
>> Best regards
>> Herbert
>>
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
thanks for your help. In fact your approach is exactly the same as mine.
I've located the bootloader at 0 and jump to the Reset_Handler location
of the application if the application is valid. I can debug the
bootloader, it does jump to the correct location, the Reset_Handler
seems to call the __scatter.o stuff correctly. I am aware of the stack
pointer issue, this should be ok. If I debug via the bootloader project
the application program seems to run somewhere in the application area
as expected, but I see the assembler instructions only, as the
bootloader project does not know anything about the application source
code / symbols.
When I try to debug via the application project I get the problems
described: Even when I place a breakpoint to the very first assembler
instruction of Reset_Handler (located at 0x00006389) the debugger
terminates immediately after reaching this instruction and returns to
compile mode without issuing any warning or error message. So this seems
to be rather an Keil issue than an issue of my source code as far as I
can see currently, because when debugging via the bootloader project I
can see that the applications Reset_Handler at 0x00006389 *is* called
and calls the __scatter.o stuff.
Any further ideas ???
Best regards
Herbert
alexander_ribero schrieb:
> Hi:
>
> I just finished a bootloader for LPC1700 and it is working without problem.
>
> I have three targets in uVision: Debug, Release and Bootloader.
>
> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>
> Release target places all the application at 0x6000.
>
> Bootloader is placed at 0x00000000
>
> The Release application only works when called from the bootloader.
>
> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>
> What I do is use the debug target to debug the application.
> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>
> Regards,
>
> Alex
> --- In l..., groups@... wrote:
>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>> This seems to work as expected (the application is build with a scatter
>> file loading all flash data at 0x6000, so the Reset_Handler in the
>> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
>> my application (I was able to do that with the LPC24xx where I directly
>> could jump to 0x6000).
>>
>> When loading the application project, going into the debugger and
>> setting a breakpoint to main() and starting the application by pressing
>> the run button, the debugger stops at main() shortly and terminates the
>> debug session immediately then by returning to the normal compile mode.
>> If I set the option "Load Application at Startup" in the "Options for
>> Target 'Debug'" I see exactly the same behaviour.
>>
>> Does anybody have a idea how to debug my LPC17xx application ??
>>
>> Any help is highly appreciated!
>>
>> Best regards
>> Herbert
>>
--
demmel products
Radnitzkygasse 43
A-1100 Vienna / Austria / Europe
Voice: +43-1-6894700-0
Fax: +43-1-6894700-40
Email: d...@demmel.com
WWW: http://www.demmel.com
Reply by ●February 4, 20102010-02-04
Hi Herbert,
IMHO it's better to find out the assembly output of this section:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
Regards,
-daniel
From: l... [mailto:l...] On Behalf Of g...@demmel.com
Sent: Thursday, February 04, 2010 1:33 PM
To: l...
Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
Alex,
thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
Any further ideas ???
Best regards
Herbert
alexander_ribero schrieb:
Hi:
I just finished a bootloader for LPC1700 and it is working without problem.
I have three targets in uVision: Debug, Release and Bootloader.
Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
Release target places all the application at 0x6000.
Bootloader is placed at 0x00000000
The Release application only works when called from the bootloader.
Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
What I do is use the debug target to debug the application.
Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
Regards,
Alex
--- In l..., groups@... wrote:
Hi,
I've ported my bootloader from the LPC24xx family to the LPC17xx family
and encounter strange problems with uVision 4:
In my bootloader I check if the application (located at 0x6000) is ok
and jump to it as follows:
#define APP_START_ADDR 0x6000
typedef void (*APP_MAIN)(void);
static APP_MAIN app_main;
int main(void)
{
:
// checking app data area at 6000
:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
}
This seems to work as expected (the application is build with a scatter
file loading all flash data at 0x6000, so the Reset_Handler in the
vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
my application (I was able to do that with the LPC24xx where I directly
could jump to 0x6000).
When loading the application project, going into the debugger and
setting a breakpoint to main() and starting the application by pressing
the run button, the debugger stops at main() shortly and terminates the
debug session immediately then by returning to the normal compile mode.
If I set the option "Load Application at Startup" in the "Options for
Target 'Debug'" I see exactly the same behaviour.
Does anybody have a idea how to debug my LPC17xx application ??
Any help is highly appreciated!
Best regards
Herbert
IMHO it's better to find out the assembly output of this section:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
Regards,
-daniel
From: l... [mailto:l...] On Behalf Of g...@demmel.com
Sent: Thursday, February 04, 2010 1:33 PM
To: l...
Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
Alex,
thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
Any further ideas ???
Best regards
Herbert
alexander_ribero schrieb:
Hi:
I just finished a bootloader for LPC1700 and it is working without problem.
I have three targets in uVision: Debug, Release and Bootloader.
Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
Release target places all the application at 0x6000.
Bootloader is placed at 0x00000000
The Release application only works when called from the bootloader.
Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
What I do is use the debug target to debug the application.
Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
Regards,
Alex
--- In l..., groups@... wrote:
Hi,
I've ported my bootloader from the LPC24xx family to the LPC17xx family
and encounter strange problems with uVision 4:
In my bootloader I check if the application (located at 0x6000) is ok
and jump to it as follows:
#define APP_START_ADDR 0x6000
typedef void (*APP_MAIN)(void);
static APP_MAIN app_main;
int main(void)
{
:
// checking app data area at 6000
:
if (app_data_ok)
{
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
}
}
This seems to work as expected (the application is build with a scatter
file loading all flash data at 0x6000, so the Reset_Handler in the
vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
my application (I was able to do that with the LPC24xx where I directly
could jump to 0x6000).
When loading the application project, going into the debugger and
setting a breakpoint to main() and starting the application by pressing
the run button, the debugger stops at main() shortly and terminates the
debug session immediately then by returning to the normal compile mode.
If I set the option "Load Application at Startup" in the "Options for
Target 'Debug'" I see exactly the same behaviour.
Does anybody have a idea how to debug my LPC17xx application ??
Any help is highly appreciated!
Best regards
Herbert
Reply by ●February 4, 20102010-02-04
Daniel,
I do not agree: APP_MAIN contains the vector table of the application
(first unsigned long value is the stack pointer value, 2nd unsigned long
value is the address of the application's Reset_Handler), so as I'm
dereferencing the (*((dword *) (APP_START_ADDR + 4))) via the "*" it
does point to the odd address of the application's Reset_Handler 0x00006389.
When looking into the assembler source code, the app_main() call is done
via BLX R0, where R0 does contain the value 0x00006389 as it should be.
I hope using BLX R0 is correct (I never learned the thumb instructions,
C code did it well until now).
Best regards
Herbert
Daniel Widyanto schrieb:
> Hi Herbert,
>
> IMHO it's better to find out the assembly output of this section:
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
>
> The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
>
> Regards,
> -daniel
>
> From: l... [mailto:l...] On Behalf Of g...@demmel.com
> Sent: Thursday, February 04, 2010 1:33 PM
> To: l...
> Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
>
>
> Alex,
>
> thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
>
> When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
>
> Any further ideas ???
>
> Best regards
> Herbert
>
> alexander_ribero schrieb:
> Hi:
>
> I just finished a bootloader for LPC1700 and it is working without problem.
>
> I have three targets in uVision: Debug, Release and Bootloader.
>
> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>
> Release target places all the application at 0x6000.
>
> Bootloader is placed at 0x00000000
>
> The Release application only works when called from the bootloader.
>
> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>
> What I do is use the debug target to debug the application.
> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>
> Regards,
>
> Alex
> --- In l..., groups@... wrote:
>
> Hi,
>
> I've ported my bootloader from the LPC24xx family to the LPC17xx family
> and encounter strange problems with uVision 4:
>
> In my bootloader I check if the application (located at 0x6000) is ok
> and jump to it as follows:
>
> #define APP_START_ADDR 0x6000
>
> typedef void (*APP_MAIN)(void);
> static APP_MAIN app_main;
>
> int main(void)
> {
> :
> // checking app data area at 6000
> :
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
> }
>
> This seems to work as expected (the application is build with a scatter
> file loading all flash data at 0x6000, so the Reset_Handler in the
> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
> my application (I was able to do that with the LPC24xx where I directly
> could jump to 0x6000).
>
> When loading the application project, going into the debugger and
> setting a breakpoint to main() and starting the application by pressing
> the run button, the debugger stops at main() shortly and terminates the
> debug session immediately then by returning to the normal compile mode.
> If I set the option "Load Application at Startup" in the "Options for
> Target 'Debug'" I see exactly the same behaviour.
>
> Does anybody have a idea how to debug my LPC17xx application ??
>
> Any help is highly appreciated!
>
> Best regards
> Herbert
>
I do not agree: APP_MAIN contains the vector table of the application
(first unsigned long value is the stack pointer value, 2nd unsigned long
value is the address of the application's Reset_Handler), so as I'm
dereferencing the (*((dword *) (APP_START_ADDR + 4))) via the "*" it
does point to the odd address of the application's Reset_Handler 0x00006389.
When looking into the assembler source code, the app_main() call is done
via BLX R0, where R0 does contain the value 0x00006389 as it should be.
I hope using BLX R0 is correct (I never learned the thumb instructions,
C code did it well until now).
Best regards
Herbert
Daniel Widyanto schrieb:
> Hi Herbert,
>
> IMHO it's better to find out the assembly output of this section:
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
>
> The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
>
> Regards,
> -daniel
>
> From: l... [mailto:l...] On Behalf Of g...@demmel.com
> Sent: Thursday, February 04, 2010 1:33 PM
> To: l...
> Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
>
>
> Alex,
>
> thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
>
> When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
>
> Any further ideas ???
>
> Best regards
> Herbert
>
> alexander_ribero schrieb:
> Hi:
>
> I just finished a bootloader for LPC1700 and it is working without problem.
>
> I have three targets in uVision: Debug, Release and Bootloader.
>
> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>
> Release target places all the application at 0x6000.
>
> Bootloader is placed at 0x00000000
>
> The Release application only works when called from the bootloader.
>
> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>
> What I do is use the debug target to debug the application.
> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>
> Regards,
>
> Alex
> --- In l..., groups@... wrote:
>
> Hi,
>
> I've ported my bootloader from the LPC24xx family to the LPC17xx family
> and encounter strange problems with uVision 4:
>
> In my bootloader I check if the application (located at 0x6000) is ok
> and jump to it as follows:
>
> #define APP_START_ADDR 0x6000
>
> typedef void (*APP_MAIN)(void);
> static APP_MAIN app_main;
>
> int main(void)
> {
> :
> // checking app data area at 6000
> :
>
> if (app_data_ok)
> {
> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
> app_main();
> }
> }
>
> This seems to work as expected (the application is build with a scatter
> file loading all flash data at 0x6000, so the Reset_Handler in the
> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
> my application (I was able to do that with the LPC24xx where I directly
> could jump to 0x6000).
>
> When loading the application project, going into the debugger and
> setting a breakpoint to main() and starting the application by pressing
> the run button, the debugger stops at main() shortly and terminates the
> debug session immediately then by returning to the normal compile mode.
> If I set the option "Load Application at Startup" in the "Options for
> Target 'Debug'" I see exactly the same behaviour.
>
> Does anybody have a idea how to debug my LPC17xx application ??
>
> Any help is highly appreciated!
>
> Best regards
> Herbert
>
Reply by ●February 4, 20102010-02-04
Hi,
I found the problem: When having set the JTAG port instead of the SW
port on the "Cortex-M Target Driver Setup" screen of Vision 4, flash
download works as expected, but debugging shows the strange effect
described (returning from debug mode into compile mode without issuing a
warning or error message when hitting a breakpoint). As I've already
setup the SW port in the bootloader project, everything worked fine
there. The application project did not have SW set (it was JTAG),
although I've copied the *.uvproj file from the bootloader project to
the application project.
Thanks for any suggestions and your help!
BTW:
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
*is* correct and works as expected ;-)
Best regards
Herbert
g...@demmel.com schrieb:
> Daniel,
>
> I do not agree: APP_MAIN contains the vector table of the application
> (first unsigned long value is the stack pointer value, 2nd unsigned long
> value is the address of the application's Reset_Handler), so as I'm
> dereferencing the (*((dword *) (APP_START_ADDR + 4))) via the "*" it
> does point to the odd address of the application's Reset_Handler 0x00006389.
>
> When looking into the assembler source code, the app_main() call is done
> via BLX R0, where R0 does contain the value 0x00006389 as it should be.
> I hope using BLX R0 is correct (I never learned the thumb instructions,
> C code did it well until now).
>
> Best regards
> Herbert
>
> Daniel Widyanto schrieb:
>
>> Hi Herbert,
>>
>> IMHO it's better to find out the assembly output of this section:
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>>
>> The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
>>
>> Regards,
>> -daniel
>>
>> From: l... [mailto:l...] On Behalf Of g...@demmel.com
>> Sent: Thursday, February 04, 2010 1:33 PM
>> To: l...
>> Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
>>
>>
>> Alex,
>>
>> thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
>>
>> When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
>>
>> Any further ideas ???
>>
>> Best regards
>> Herbert
>>
>> alexander_ribero schrieb:
>> Hi:
>>
>> I just finished a bootloader for LPC1700 and it is working without problem.
>>
>> I have three targets in uVision: Debug, Release and Bootloader.
>>
>> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>>
>> Release target places all the application at 0x6000.
>>
>> Bootloader is placed at 0x00000000
>>
>> The Release application only works when called from the bootloader.
>>
>> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>>
>> What I do is use the debug target to debug the application.
>> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>>
>> Regards,
>>
>> Alex
>> --- In l..., groups@... wrote:
>>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>> This seems to work as expected (the application is build with a scatter
>> file loading all flash data at 0x6000, so the Reset_Handler in the
>> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
>> my application (I was able to do that with the LPC24xx where I directly
>> could jump to 0x6000).
>>
>> When loading the application project, going into the debugger and
>> setting a breakpoint to main() and starting the application by pressing
>> the run button, the debugger stops at main() shortly and terminates the
>> debug session immediately then by returning to the normal compile mode.
>> If I set the option "Load Application at Startup" in the "Options for
>> Target 'Debug'" I see exactly the same behaviour.
>>
>> Does anybody have a idea how to debug my LPC17xx application ??
>>
>> Any help is highly appreciated!
>>
>> Best regards
>> Herbert
>>
I found the problem: When having set the JTAG port instead of the SW
port on the "Cortex-M Target Driver Setup" screen of Vision 4, flash
download works as expected, but debugging shows the strange effect
described (returning from debug mode into compile mode without issuing a
warning or error message when hitting a breakpoint). As I've already
setup the SW port in the bootloader project, everything worked fine
there. The application project did not have SW set (it was JTAG),
although I've copied the *.uvproj file from the bootloader project to
the application project.
Thanks for any suggestions and your help!
BTW:
app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
app_main();
*is* correct and works as expected ;-)
Best regards
Herbert
g...@demmel.com schrieb:
> Daniel,
>
> I do not agree: APP_MAIN contains the vector table of the application
> (first unsigned long value is the stack pointer value, 2nd unsigned long
> value is the address of the application's Reset_Handler), so as I'm
> dereferencing the (*((dword *) (APP_START_ADDR + 4))) via the "*" it
> does point to the odd address of the application's Reset_Handler 0x00006389.
>
> When looking into the assembler source code, the app_main() call is done
> via BLX R0, where R0 does contain the value 0x00006389 as it should be.
> I hope using BLX R0 is correct (I never learned the thumb instructions,
> C code did it well until now).
>
> Best regards
> Herbert
>
> Daniel Widyanto schrieb:
>
>> Hi Herbert,
>>
>> IMHO it's better to find out the assembly output of this section:
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>>
>> The app_main() should be translated as "BX ", with odd address or the Thumb bit is dismissed (and generate unknown error). I think the correct one is "app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 5)));"
>>
>> Regards,
>> -daniel
>>
>> From: l... [mailto:l...] On Behalf Of g...@demmel.com
>> Sent: Thursday, February 04, 2010 1:33 PM
>> To: l...
>> Subject: Re: [lpc2000] Re: Own bootloader on LPC17xx - debug problem with ULINK2
>>
>>
>> Alex,
>>
>> thanks for your help. In fact your approach is exactly the same as mine. I've located the bootloader at 0 and jump to the Reset_Handler location of the application if the application is valid. I can debug the bootloader, it does jump to the correct location, the Reset_Handler seems to call the __scatter.o stuff correctly. I am aware of the stack pointer issue, this should be ok. If I debug via the bootloader project the application program seems to run somewhere in the application area as expected, but I see the assembler instructions only, as the bootloader project does not know anything about the application source code / symbols.
>>
>> When I try to debug via the application project I get the problems described: Even when I place a breakpoint to the very first assembler instruction of Reset_Handler (located at 0x00006389) the debugger terminates immediately after reaching this instruction and returns to compile mode without issuing any warning or error message. So this seems to be rather an Keil issue than an issue of my source code as far as I can see currently, because when debugging via the bootloader project I can see that the applications Reset_Handler at 0x00006389 *is* called and calls the __scatter.o stuff.
>>
>> Any further ideas ???
>>
>> Best regards
>> Herbert
>>
>> alexander_ribero schrieb:
>> Hi:
>>
>> I just finished a bootloader for LPC1700 and it is working without problem.
>>
>> I have three targets in uVision: Debug, Release and Bootloader.
>>
>> Debug target places the RESET area at 0x00000000 and the rest of the application at the desired application area (in your case 0x6000)
>>
>> Release target places all the application at 0x6000.
>>
>> Bootloader is placed at 0x00000000
>>
>> The Release application only works when called from the bootloader.
>>
>> Note that the Cortex M3 processors load the Stack Pointer from the first four bytes of Flash (0x00000000) after reset. If you target all your application for 0x6000, the processor might be loading invalid stack pointer and generating exceptions when executing routines (like jumping to main), if your don't program a bootloader or other app at 0x00000000
>>
>> What I do is use the debug target to debug the application.
>> Then, use the Bootloader target to debug the bootloader, and confirm that it jumps to the application.
>>
>> Regards,
>>
>> Alex
>> --- In l..., groups@... wrote:
>>
>> Hi,
>>
>> I've ported my bootloader from the LPC24xx family to the LPC17xx family
>> and encounter strange problems with uVision 4:
>>
>> In my bootloader I check if the application (located at 0x6000) is ok
>> and jump to it as follows:
>>
>> #define APP_START_ADDR 0x6000
>>
>> typedef void (*APP_MAIN)(void);
>> static APP_MAIN app_main;
>>
>> int main(void)
>> {
>> :
>> // checking app data area at 6000
>> :
>>
>> if (app_data_ok)
>> {
>> app_main = (APP_MAIN) (*((dword *) (APP_START_ADDR + 4)));
>> app_main();
>> }
>> }
>>
>> This seems to work as expected (the application is build with a scatter
>> file loading all flash data at 0x6000, so the Reset_Handler in the
>> vector table at 0x6000 can be found on 0x6004) but I'm unable to debug
>> my application (I was able to do that with the LPC24xx where I directly
>> could jump to 0x6000).
>>
>> When loading the application project, going into the debugger and
>> setting a breakpoint to main() and starting the application by pressing
>> the run button, the debugger stops at main() shortly and terminates the
>> debug session immediately then by returning to the normal compile mode.
>> If I set the option "Load Application at Startup" in the "Options for
>> Target 'Debug'" I see exactly the same behaviour.
>>
>> Does anybody have a idea how to debug my LPC17xx application ??
>>
>> Any help is highly appreciated!
>>
>> Best regards
>> Herbert
>>
