Adjusting the MAX_ADDRESS within the target structure for the msp430 in
msp430-gdbproxy would correct the problem.
Does anyone know how to contact the author or is capable of getting
these changes made?
Sergey A. Borshch wrote:
Hugh Hartwig wrote:
My colleague and I are having difficulty getting a simple program to run
with the __far__ attribute on one of the function calls. The program runs
as long as the __far__ attribute is not used. We are unable to debug this
problem with GDB either because GDB apparently doesn't know how to load data
in the extended address space. It attempts to load the code at address
0x0000 instead of 0x10000 and fails.
Actually it loads at correct address, but truncates displayed value. Problem is that msp430-gdbproxy
answers:
error: msp430: bad address 0x10000
Here is msp430-gdbproxy respond to "info mcu" gdb command:
Current target device is a 'MSP430F2618' (type 66), so:
Main memory is from 0x3100 to 0xFFFF (52992 bytes)
Info memory is from 0x1000 to 0x10FF (256 bytes)
RAM is from 0x200 to 0x9FF (2048 bytes)
Up to 8 breakpoints are supported
Emulation level is 3
Clock control level is 2
VCC is from 1.800V to 3.600V
as we can see, msp430-gdbproxy dont't knows about high flash and knows about
mirrored RAM only :(
We should somehow wakeup msp430-gdbproxy author.
Is anyone using GDB to debug programs
with __attribute__((__far__)), and has anyone successfully run a program
using the __far__ attribute period? We are using the msp430f2618 processor.
I think no - I just started fixing gdb yesterday, but it seems meanless until msp430-gdbproxy
supports high memory.
