Debug bootloader example in eclipse with jlink

[ssaerdna 0]

Hi all,

 

I am trying to debug the bootloader example in eclipse with the jlink debugger.

 

And I am not sure about how to configure the jlink plugin in eclipse correctly,

where to point the stack and the pc register due to the fact that the gcc linker

script uses the VMA and the LMA for the sections and the bootcode is copied

into RAM in the reset handler.

 

The download seems to work correctly, but breakpoints are not reached correctly.

I would like to start debugging at the beginning in the assembler code, to see

the first steps of copying the bootloader code into RAM.

Is it possible to debug assembler code at this stage (in the reset handler) at all?

 

In the debugger plugin in eclipse I choose to break e.g. in ResetISR, but

it stops somewhere else.

 

Can anyone give me a hint what I am doin wrong, how to correctly setup

the debugger for this project?

 

Thanks in advance,

Andreas

[GrumpyOldPizza 15]

I have never tried this with exclipse, but with gdb (using openocd):

 

monitor halt

load <your file>.elf

monitor reset halt

file <your file>.elf

break <your reset handler>

c

 

 

You might get away without the "file <your file>.elf", for me that's just an extra insurance. Also the command "monitor reset halt" seems to fail some times, so you need to issue it again if it fails the first time.

 

One big issue with gdb is that it does not know where the "sp" is after reset. It assumes all registers are undefined. Thus you need to explicitly load the "sp" as the first instruction in <your reset handler>.

 

I suppose you could do that with eclipse, if you use this type of command sequence for the program load (there is a box where you could enter this). But because "monitor reset halt" fails every now and then, that's kind of rather fragile.

 

- Thomas

[OppaErich 25]

I don't use jlink but this plugin supports it. http://gnuarmeclipse.livius.net/blog/jlink-install/

[ssaerdna 0]

Hi Tomas,

 

thanks for your reply, I will try OpenOCD, had such thoughts already in my mind :-)

 

It might be really an issue of the eclipse/gdb plugin combination, because it works

fine with the uvision debugger in combination with the jlink.

 

So I will try it with the OpenOCD and play around with the commands and the

position of the first breakpoint.

 

@@Oppa, thanks for your reply, too, i already tried the jlink plugin, but it did not work

at all with that, but it works with the standard GDB plugin, maybe I configured it wrong,

I will try that again as well....

[GrumpyOldPizza 15]

Hi Tomas,

 

thanks for your reply, I will try OpenOCD, had such thoughts already in my mind :-)

 

It might be really an issue of the eclipse/gdb plugin combination, because it works

fine with the uvision debugger in combination with the jlink.

 

So I will try it with the OpenOCD and play around with the commands and the

position of the first breakpoint.

 

@@Oppa, thanks for your reply, too, i already tried the jlink plugin, but it did not work

at all with that, but it works with the standard GDB plugin, maybe I configured it wrong,

I will try that again as well....

 

JLINK will not work with Ecplise (unless you have a special pluging). The normal one issues a couple of commands to the gdb-remote that the jlink gdb server does not understand:

 

monitor delay

monitor halt

monitor reset

monitor reset halt

 

(I don't claim to know which one of the 4 combinations is at fault ;-)). 

 

It's also possible to configure an "extended remote". In that case eclipse uses the "run" command to tell gdb to restart. I suspect that this will not allow breakpoints across a reset. But I might be wrong. Perhaps checking this eclipse box might help.

 

- Thomas

[ssaerdna 0]

Hi Thomas,

I have installed a plugin for gdb (dsf) Hardware Debugging which works quite fine with a normal

application.

The Problem occurs only with the bootloader Project. I have set the Registers for sp to 0x00000000 

and the pc to 0x00000004 but I am not sure if this is okay because the linker locates everything in

ram, just the load addresses are in Flash. So the first few steps are in Flash until the assembler

Routine copies everything into ram and branches into ram for further execution.

Maybe ist really an issue that the cpu is not haltet that fast.

I Will try that with the Monitor commands too, but in the example i have for a normal application

the break command is without that Monitor prefix...

I am off for the Weekend and try it on sun or mon and tell you...

 Andreas.

[GrumpyOldPizza 15]

Hi Thomas,

I have installed a plugin for gdb (dsf) Hardware Debugging which works quite fine with a normal

application.

The Problem occurs only with the bootloader Project. I have set the Registers for sp to 0x00000000 

and the pc to 0x00000004 but I am not sure if this is okay because the linker locates everything in

ram, just the load addresses are in Flash. So the first few steps are in Flash until the assembler

Routine copies everything into ram and branches into ram for further execution.

Maybe ist really an issue that the cpu is not haltet that fast.

I Will try that with the Monitor commands too, but in the example i have for a normal application

the break command is without that Monitor prefix...

I am off for the Weekend and try it on sun or mon and tell you...

 Andreas.

 

Off for the weekend ... "German Reunification Day" ;-)

 

Mind quickly posting your link script ?

 

There are a few things that sound fishy. First off the "sp" is the content of memory location 0x0000000, not the value 0x00000000. Same goes for your PC.

 

I am also a tad surprised about the "linker locates everything in ram". If it does so, how does the reset know that it's in RAM ? Usually execution starts from FLASH, and then ".data" is copied from flash, and ".bss" is zeroed out. 

 

Now TM4C can map the internal ROM to address 0x00000000 (see RMCTL), but not the internal RAM (unlike other ARM chips). 

 

- Thomas

[ssaerdna 0]

SECTIONS
{
    .text 0x20000000 : AT (0x00000000)
    {
        _text = .;
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
        _etext = .;
    }

    .data 0x20000000 + SIZEOF(.text) : AT (SIZEOF(.text))
    {
        _data = .;
        *(.data*)
        _edata = .;
    }

    .bss 0x20000000 + SIZEOF(.text) + SIZEOF(.data) :
        AT (ADDR(.data) + SIZEOF(.data))
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
    }
}

Hi Thomas,

 

yeah, have been hiking in the mountains with great weather :-)

 

I set the Registers of SP and PC to 0x00000000 and 0x00000004 where the vector table is located.

Then the complete code is copied into ram in the ResetISR handler and the pc is then set to the new

Location of the copied code.

 

But thats exactly my problem. The project I am playing with is the bootloader example which is provided

from TI.

 

I have just tried it without Setting the SP and the PC within the jlink plugin and putting in a initialization

command "monitor halt". It seems that the halt is at address 0x0 in the disassembly view, without

source code available. But since this is an Assembler file, no sourcecode might be available anyway...

 

But here is the linker file:

 

 

Andreas

[GrumpyOldPizza 15]

I see. That is gonna be more tricky. How do you set up your isr vectors ? If I'd know how, I could try and work out some boot code.

 

There are a bunch of problems with this approach you are trying to take, so mind asking as to why you want your .text section in RAM ?

 

Again, if you attach the project files I could quickly fix that (you are on TM4C123 ?)