Apologies if this is not the correct place for writing this.
I recently installed emIDE 2.16, and J-Link GDB Server V4.80h (on windows).
I am trying to debug and NS7520 (arm7tdmi).
My first issue is that no breakpoints are working, the program just keeps executing, unless I hit "break debugger" in the ide, in which case it stops and the CPU registers is updated, seeing the program counter far past the main entry points address.
My second issue is that, ok if I can stop the program flow manually and look at the memory then maybe I can do some work.
But if I try to look at address 0xFFB00020 (PORT A, for the NS7520), segger outputs the following errrors
And they also use the attached jlink settings file
I also noticed that segger have an almost identical settings file (C:\Program Files (x86)\SEGGER\JLinkARM_V480h\Samples\GDB\GDBInit\gdbns7520.jlink)
Anyways, could these somehow be used to enable breakpoints and reading of memory?
I haven't seen any copyright notices about these files but if there is, then please remove the attachments of this thread .
Any help is appreciated
Yours Sincerely
Rikard Söderström
============== EDIT ====================
Apparently the problem with breakpoints had nothing to jlink/gdbinit files. I was building as little endian and the segger expected big endian, so I just told the segger to expect little endian and things started working. well, also there was an issue with emIDE's sample code (the watchdog disable part of that example, caused the program to reset (since the address for the watchdog was invalid)).
The problem now is looking at the memory still remains, but apparently it is only a problem for high addresses ragnes (0x0F000000 - 0xFFFFFFFF).
Sadly those are the ranges that I wanted to see.
However the Watches window can be used to see these addressses and its values. So I guess I don't really need the memory window anymore.
Yours Sincerely
Rikard Söderström
I recently installed emIDE 2.16, and J-Link GDB Server V4.80h (on windows).
I am trying to debug and NS7520 (arm7tdmi).
My first issue is that no breakpoints are working, the program just keeps executing, unless I hit "break debugger" in the ide, in which case it stops and the CPU registers is updated, seeing the program counter far past the main entry points address.
My second issue is that, ok if I can stop the program flow manually and look at the memory then maybe I can do some work.
But if I try to look at address 0xFFB00020 (PORT A, for the NS7520), segger outputs the following errrors
So then I started thinking that maybe I have to define the register addresses in gdbinit, the vendor uses the attached gdbinit scriptWARNING: Failed to read memory @ address 0xC0FC0900
Read 4 bytes @ address 0xC0FC0900 (Data = 0xAAAAAAAA)
WARNING: Failed to read memory @ address 0x38001000
Read 4 bytes @ address 0x38001000 (Data = 0xAAAAAAAA)
WARNING: Failed to read memory @ address 0x38001000
Read 4 bytes @ address 0x38001000 (Data = 0xAAAAAAAA)
WARNING: Failed to read memory @ address 0xFFB00050
Read 1 bytes @ address 0xFFB00050 (Data = 0xAA)
WARNING: Failed to read memory @ address 0xFFB00050
Read 1 bytes @ address 0xFFB00050 (Data = 0xAA)
Read 1 bytes @ address 0xFFB00020 (Data = 0xEF)
And they also use the attached jlink settings file
I also noticed that segger have an almost identical settings file (C:\Program Files (x86)\SEGGER\JLinkARM_V480h\Samples\GDB\GDBInit\gdbns7520.jlink)
Anyways, could these somehow be used to enable breakpoints and reading of memory?
I haven't seen any copyright notices about these files but if there is, then please remove the attachments of this thread .
Any help is appreciated
Yours Sincerely
Rikard Söderström
============== EDIT ====================
Apparently the problem with breakpoints had nothing to jlink/gdbinit files. I was building as little endian and the segger expected big endian, so I just told the segger to expect little endian and things started working. well, also there was an issue with emIDE's sample code (the watchdog disable part of that example, caused the program to reset (since the address for the watchdog was invalid)).
The problem now is looking at the memory still remains, but apparently it is only a problem for high addresses ragnes (0x0F000000 - 0xFFFFFFFF).
Sadly those are the ranges that I wanted to see.
However the Watches window can be used to see these addressses and its values. So I guess I don't really need the memory window anymore.
Yours Sincerely
Rikard Söderström
The post was edited 1 time, last by Soderstrom ().