MX7 M4: Loading/executing freeRTOS BSP example code with and without SD card

[demoniacmilk]

Hello! I have some questions on running bare metal/freeRTOS on the MX7's Cortex-M4 core.

WITH SD CARD on SABRE

For the sabre board it is possible to start the M4 core through uboot using the fatload {source path}{address} command where uboot copies a prevously stored file from the file system to a memory address. After loading a .bin/.elf file, bootaux {address} starts the M4 and runs the program starting at the specified address.

The FreeRTOS BSP Hello World example has been built succesfully using GNU MCU Eclipse.

Two terminal instances are connected to the virtual com ports to see the A7 and M4 debug output.

Using the A7 terminal, the M4 application is loaded and started as follows:

=> fatload mmc 0:1 0x80800000 M4_HelloWorld.elf
reading M4_HelloWorld.elf
33400 bytes read in 32 ms (1018.6 KiB/s)
=> bootaux 0x80800000
## Starting auxiliary core at 0x80800000 ...

I do not see any output on the M4 terminal, including echo. So something went wrong.

The fatload address is located in RAM. I randomly picked an address to load to and execute from. Are there any restrictions on what addresses might be chosen (while within RAM boundaries)?

A couple loader files like MCIMX7D_M4_ddr.ld are included in the BSP (platform/devices/MCIMX7D/linker). I have not understood what I should do with these.

Is the Hello World example meant to work out of the box or are any adjustments needed?

WITHOUT SD CARD

Our custom MX7 hardware does not have an SD card. Instead, EMMC and NAND are used in the system. JTAG is avilable, the next revision will have a USB connector on USB OTG 1 as well.

How can I actually get my program to run on the M4 under these conditions? May I use JTAG? With a JLink debugger I can connect to the two A7 cores but not to the M4 (target cpu could not be halted).

What are the steps to load a binary and execute on the M4?

(No Linux available).

[dry]

Hi Lars,

If you using Segger J-Link & Eclipse tools , and just working on M4 with no Linux booting on A7, then in my experience that should be straight forward. I've experienced more issues when /after Linux runs, but that's sorted too.

(Have you seen this thread? https://community.nxp.com/thread/461296 ).

I'll be happy to share any setting if they may be of use.

[demoniacmilk]

Hello,

thank you for the hint. That is quite a good thread!

However, on trying to connect to the M4 through Eclipse (or standalone JLinkGDBServerCL.exe) I run into the following problem (even if the Segger MX7 M4 connect script is used):

This did not change if I use the script provided in your thread at first.

Adding the options to the debug configurations startup tab and disabling Pre-run/Restart reset I get the following error instead:

Error in services launch sequence
Starting J-Link GDB Server timed out.

Any idea what might be the cause for this? Starting Eclipse in Admin mode did not have any effect (I thought maybe Eclipse is not allowed to start the GDB Server)
Here are my startup settings:

[demoniacmilk]

Alright I figured that part out. It was actually a misconfiguration in the eclipse settings that was pointing to the wrong executable in the Jlink folder (RemoteServer instead of GDBServer).

Eclipse is now able to start a debug session.

However, I do not see anything happen. As in:
The project is built, uploaded, and the status bar adjusts to "Launching <debug session name>:(100%)".
Eclipse switches to debug view. But all buttons like Resume, Suspend, Step over/into/etc are greyed out, except for "Terminate". No breakpoints are reached. So I assume PC/SP are set up incorrectly.

When looking at the SEGGER JLink control panel that pops up as a tray icon, I can see R13 and R15 (Stack pointer, Program counter) are 0.

I can set registers and correctly read their value back, so I assume this is not a readout error.

This is probably a misconfiguration in Eclipse?

After uploading the binary, the PC/SP should be set by Eclipse through the jlink i assume.
How can I find out what values these registers should have?

I am using a freeRTOS example project for this. I read they are all meant to be built for tightly coupled memory. Not sure if this refers to the usage of the provided batch/shell files for building a project. I have not set up any linker file from what I remember.

[dry]

>I have not set up any linker file from what I remember.

All linker files as provided in examples are good & usable.

If I can ask, sorry for obvious thing, but have you verified you can connect to the M4 core with J-Link commander properly?  And read registers, from command line.  I really like that :smileyhappy:  . Followed by command line JLinkGDBServer + gdb test.

I use Segger's Linux command line tools but I know you can do with JLink windows commander same thing for testing.

Also just to understand, when you wrote  "(no Linux is available)",  do you mean you do not run Linux on A7 core(s) of the target?  Do you at least boot U-boot?

[demoniacmilk]

All linker files as provided in examples are good & usable.

Guess i need to figure out how to use them :smileygrin:

If I can ask, sorry for obvious thing, but have you verified you can connect to the M4 core with J-Link commander properly?  And read registers, from command line. 

Whenever the connection has been established (like right now using the JLinkGDBServerCL.exe through the command prompt) a JLink control panel tray icon shows up. Clicking on that i can go ahead and read all registers.I can modify the register values and when I read them back the values remain.

When the connection is established using JLink.exe it seems to work as well.

J-Link>connect

[...]
Cortex-M4 identified.
J-Link>mem32 0,1
00000000 = 4C1B8F02

Also just to understand, when you wrote  "(no Linux is available)",  do you mean you do not run Linux on A7 core(s) of the target?  Do you at least boot U-boot?

The hardware at hand was developed for a customer. The customer does all the software stuff (Linux image, application to run on the system etc). All I want to do is check/verify my hardware design as in: reading/writing data on some interfaces like i2c, uart, ethenet and read out e.g. device IDs of components attached to these interfaces. The whole point of this is to verify the hardware functionality. As i've never done any Linux development or built a custom kernel or figured out how to get a kernel/uboot image into the system (it does not have an SD card) I'd like to not use Linux at all. I just want to run some simple, bare metal interface tests.

[dry]

> Guess i need to figure out how to use them 

They are used, when the examples get built, so you don't do anything unless you need to modify them. 

> r figured out how to get a kernel/uboot image into the system

May be check it out,  U-boot may be handy, even without rest (Linux) running.

[demoniacmilk]

I think I only need to figure out how to enable the CPU to be halted (either help the Emulator to halt the cpu or ... i dont know if this may require a setup or hardware change?). Can you halt the CPU multiple times with your setup?

[dry]

Hey Lars,

Even if I do not build them with the provided makefiles/batch scripts/shell scripts? Just the source files have been imported to eclipse, I haven't told the build system anything about the loader files.

No, sorry, I didn't realize you not using the standard provided build setup (as delivered by NXP) for your FreeRTOS examples.   

Of course linker files must be used, and required for the binaries to be loaded correctly into memory. 

I suggest you use provided build system.

I will not help you with re-creating that setup as you want, sorry.  

(Otherewise, my PayPal account is ..... :smileysilly: )

I think I only need to figure out how to enable the CPU to be halted (either help the Emulator to halt the cpu or ... i dont know if this may require a setup or hardware change?). Can you halt the CPU multiple times with your setup?

If you loaded junk (which you did,  like 0's for those values), you won't be able to re-halt it, as by now the CPU is in a fault state (if those addresses looked valid before M4 started). Power cycle would cleanly fix that.

Start with building all as is  /provided in examples. Proceed to test with command line, then proceed to Eclipse.

G'luck

[demoniacmilk]

I will not help you with re-creating that setup as you want, sorry.  

(Otherewise, my PayPal account is .....  )

Yes i totally understand this :smileyhappy:

I installed MinGW and CMake to be able to compile the provided examples with the script files.
Compilation was succesful.

I went with the Hello World OCRAM example. Started the GDB server, followed by arm-none-eabi-gdb, set the file to the created elf file, loaded it (console prints different sections being loaded), then "monitor go", but i do not see any console output unfortuntely (Putty on COM port). I see symbols being sent to the SABRE board (indicator LEDs) so I know the putty setup is okay.

[dry]

It sounds like you almost there.

You could try do as: after clean start, connect JLinkGDBServer, then connect gdb to it, then load elf file (as you were doing), then before anything else (not going monitor go), set the break point in reset handler , e..g with tbreak. Then use gdb's command continue. You should hit the break point and gdb should stop on it.

Try single step, then set another breakpoint in the console stuff or where that threat prints hello.

(Also handy , Cntrl^C in gdb I believe is to break immediately the current execution).

[demoniacmilk]

GDB Client:

(gdb) tbreak Reset_Handler
Temporary breakpoint 1 at 0x202102f4: file C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\startup\gcc\startup_MCIMX7D_M4.S, line 207.
(gdb) continue
Continuing.

Temporary breakpoint 1, Reset_Handler ()
at C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\startup\gcc\startup_MCIMX7D_M4.S:207
207 cpsid i /* Mask interrupts */
(gdb)

GDB Server:

Starting target CPU...
...Breakpoint reached @ address 0x202102F4
Reading all registers
Removing breakpoint @ address 0x202102F4, Size = 2
Read 4 bytes @ address 0x202102F4 (Data = 0xF001B672)
Read 2 bytes @ address 0x202102F4 (Data = 0xB672)

Well that looks pretty decent!

I used the step command in the GDB client, first step looked good, second kinda failed.

(gdb) step
209 bl SystemInit
(gdb) step

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00492f84 in ?? ()

So I tried a reset and setting the breakpoint in the reset handler again:

(gdb) monitor reset
Resetting target
(gdb) tbreak Reset_Handler
Temporary breakpoint 2 at 0x202102f4: file C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\startup\gcc\startup_MCIMX7D_M4.S, line 207.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00492f84 in ?? ()
(gdb) tbreak main
Ignoring packet error, continuing...
The target is not responding to GDB commands.

So I think its not ideal yet, but rather close to what is needed.

You have been an awesome help so far, thanks a lot!

 - - - - EDIT - - - - - 

Program received signal SIGTRAP, Trace/breakpoint trap.

0x00490f84 in ?? ()

--> Always lands here, no matter if breakpoints have been set or not. Wonder if the program counter might accidently point to some forbidden location?

The datasheet names a "reserved" area from 0040 000 to 004F FFFF. Whatever this "reserved" tells me. None of the data during load is put in this location (0x2021.. is OCRAM_128KB), so i wonder why the program counter even gets there. The .elf file is ~254 KB in size, but "load size" is 14796 (what is exactly the size of the gerated .bin file). So this should fit into OCRAM?

Loading section .interrupts, size 0x240 lma 0x20210000
Loading section .text, size 0x370c lma 0x20210240
Loading section .ARM, size 0x8 lma 0x2021394c
Loading section .init_array, size 0x4 lma 0x20213954
Loading section .fini_array, size 0x4 lma 0x20213958
Loading section .data, size 0x70 lma 0x2021395c
Start address 0x202102f4, load size 14796

 - - - - EDIT 2 - - - - - 

Using the Hello World DDR example instead of the OCRAM example, i get the folowing (even after deleting all breakpoints).

Starting target CPU...
...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Read 4 bytes @ address 0x20212138 (Data = 0xAF00B480)
Starting target CPU...
...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Read 4 bytes @ address 0x20212138 (Data = 0xAF00B480)
Starting target CPU...
...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Read 4 bytes @ address 0x20212138 (Data = 0xAF00B480)
Starting target CPU...
...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Read 4 bytes @ address 0x20212138 (Data = 0xAF00B480)

On "step" command, the GDB Server goes crazy, spamming 

...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Performing single step...
...Target halted (DBGRQ, PC = 0x20212138)
Reading all registers
Performing single step...

So it basically never leaves that line. some sort of trap?

[dry]

(Sorry  I may not read every line you post, but I try pick up stuff I may help with)

Lars Heinrichs wrote:

The .elf file is ~254 KB in size, but "load size" is 14796 (what is exactly the size of the gerated .bin file). 

Yes elf has more information, the bin file size should be the firmware blob size.

Lars Heinrichs wrote:

So I tried a reset and setting the breakpoint in the reset handler again:

(gdb) monitor reset

That's the default reset type 0.  You can't really do that as it will besides resetting also loose SP,PC values for registers.

You need to redo those Run/Restart monitor sequence commands, as was inserted under Eclipse. So that is a full reset type for M4. ( I also checked now that, using the Eclipse' Replay button  / Restart debug without terminating debug session does the sequence as I inserted;  Good, I forgot about it, so you can re-launch without termination cleanly).

It may be possible to do just reset 1  - only core.  May or not be clean reset, haven't  really used much besides simple test, I guess depends, may be ok with whatever state those peripherals will be, depending on what you do.  (This is where you dig into the manual).For simple hello world example, I tested it actually works as far as the code restarts and runs. 

So you can try triggering it (from gdb command line, or JLinkExe):  you fist halt, then execute 'monitor reset 1'.  After you resume, the execution starts from beginning & runs.

Another (useless) way to reset is just to halt and reset PC, SP, and hope for the best, as it doesn't reset anything else. (Hopefully reset 1 does more).

I do want to note a couple of things for you.

1. My 'hacked' script for JLink was because I do not want to be resetting the entire SoC (A7 core(s) in particular) while debugging M4, as there is Linux running on the other side.   (I had enough of the nightmare from Vybrid , iMX is better on resets). You, on the other hand, I don't know what you doing  :smileyhappy: , and it may be perfectly Ok for you to reset whole thing every time & start from 0.   Just through away my script  & use default's Segger.
2. I think you wrote you not using U-boot, right? It may be a very good idea for you to use it. It should be possible to program it into your target using the iMX7's internal serial loader (over USB now, was it?).  It (u-boot) may actually help you with your HW testing - many useful things, like talk to I2C devices, SPI, flash, nand, mmc, etc ...  Ignoring that, there is an early SoC init code in it, which prepares the platform for use (like init DDR), which you may want or even need, to do before you carry on with your stuff.  It is possible however to do that init with JLink too, it just the connect & init becomes longer .....  Anyway, I don't know & probably do not want to know what you setting up :smileyhappy:

And lastly, I've had to update that script (which I include), because of a limitation of Segger's script parser / interpreter. 

I'll attach it to my original NXP thread.   (Hmmm, need to update my glorious Segger' thread too..)

[demoniacmilk]

Hm I tried to pretty much build the easiest thing possible:

Took the UART_polling driver example, built it with the provided batch files, started a GDB server, connected the GDB client, set and uploaded the elf file created before, set a breakpoint in the Reset_Handler. Continued.

Breakpoint is hit immediately, as expected. CPU halts.

On continuing two SIGTRAP signals follow ( and i do not see any activity in putty, the example should print out some lines):

Program received signal SIGTRAP, Trace/breakpoint trap.
0x64000090 in ?? ()
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x70000000 in ?? ()

Between the first and second SIGTRAP a few seconds pass.

I think for some reasons, my program counter just disappears into the void.

But I do not understand why.
Watchdog or anything like that? (Im testing on the sabre board)

The program does not even get to the main function ...

(gdb) monitor reset
Resetting target
(gdb) tbreak main
Temporary breakpoint 2 at 0x1fff8c8e: file C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\examples\imx7d_sdb_m4\driver_examples\uart_imx\uart_interrupt\main.c, line 60.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x64000090 in ?? ()
(gdb)

So I stepped through it, not getting very far

(gdb) continue
Continuing.

Temporary breakpoint 3, Reset_Handler ()
at C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\startup\gcc\startup_MCIMX7D_M4.S:207
207 cpsid i /* Mask interrupts */
(gdb) step
209 bl SystemInit
(gdb) step
SystemInit () at C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\startup\system_MCIMX7D_M4.c:62
62 SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
(gdb) step
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xfffffff9

0x64000090 in ?? ()

Also sorry for asking so many questions, its probably a bit annoying. But I am trying to understand what is happening here.

- - - - EDIT: - - - -

I have recreated and built the project in my eclipse setup, then loaded the created .elf file instead of the one created by the NXP batch files. Same result.

[dry]

Hey,

Reading your original first post:

>  => fatload mmc 0:1 0x80800000 M4_HelloWorld.elf

You cannot be loading elf files from U-boot.   (It may be a good time to RTFM :smileyhappy: .  I know I often need to).

>I do not see any output on the M4 terminal, including echo. So something went wrong.

Got back to SABRE, and make all examples work, with U-boot running. They all must, they all do.  Then test your connecting with JTAG, to the M4, on SABRE,  __with___ U-boot running.  (As mentioned,  it does init without which likely you won't be able to do anything on the M4 side too).  Once you got that working, move to your board.

>Our custom MX7 hardware does not have an SD card. Instead, EMMC and NAND are used in the system.

My current Hw comes with EMMC too, and U-boot programmed into it. It's very handy to have it .. consider it. 

Also,  I found your thread on Segger too. (Say hello to v01d).   Some notes: it is probably best not using my connect script when asking Segger for help (i saw a trace in one output you posted there), it's confusing to them.

Also just in case (apologies if it's obvious, treat it as discussion):  In particular, any connect , go , reset/restart M4 core tests will not work. 

Even without hack connect script, any connect, halt, start restart go on the M4 core are invalid, before A7 enabled it properly.  The proper procedure described in manual and the app note, and the Segger's wiki (which refers back to app note).

Following that, all your tests should work ...

[demoniacmilk]

You cannot be loading elf files from U-boot.   (It may be a good time to RTFM  .  I know I often need to).

hm I saw the elf files being used here:  FreeRTOS on the Cortex-M4 of a Colibri iMX7 so I think it should be possible. I tried using the bin files as well.

Got back to SABRE, and make all examples work, with U-boot running.

I have installed MinGW and CMAKE, compiled the examples and using uboot on the sabre they run. My own test-firmware is running as well when loaded using uboot.

My current Hw comes with EMMC too, and U-boot programmed into it. It's very handy to have it .. consider it. 

I tried to get uboot intalled on my system. Unfortunately, i cannot get any PC to recognize the custom board as an HID-USB-device (tried different PCs and cables) and therefore MFGtools cannot find the board to load/store uboot. Our customer got one of the boards as well and it works fine for them, so I will try to get another board for testing.

Until then, I am trying to set up the clocks and RAM based on an excel sheet provided by NXP that generates the register configuration for the A7. The registers are set with help of a JLink Script before the firmware is uploaded using GDB. I have no idea if this is supposed to work, I will post the results here.

[dry]

Hey Lars,

.. 

Until then, I am trying to set up the clocks and RAM based on an excel sheet provided by NXP that generates the register configuration for the A7. The registers are set with help of a JLink Script before the firmware is uploaded using GDB. I have no idea if this is supposed to work, I will post the results here.

...

Yea this should work.   That's what I would suggest next if you cannot (or refuse to ) use u-boot.   

For bootloader debugging I have a registers init in the JLink script. The inconvenience may be for you is that you have to do this from A7 size, but I'm not entirely sure if it may/not work from M4  .. (I only did from A7).

[demoniacmilk]

> They are used, when the examples get built, so you don't do anything unless you need to modify them. 

Even if I do not build them with the provided makefiles/batch scripts/shell scripts? Just the source files have been imported to eclipse, I haven't told the build system anything about the loader files.

Edit:
I added a linker file in

Project Preferences - C/C++ Build - Settings - GNU ARM Cross C Linker - General - Script files

that I have found in

<RTOS BSP>/platform/devices/linker/

I am not sure of arm or gcc shall be used so i tried both.

When using the file in the arm folder ,I get:

c:/eclipse_mcu_and_toolchains/gcc-arm-none-eabi-7-2017-q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe:C:\Eclipse_MCU_And_Toolchains\RTOS_BSP\platform\devices\MCIMX7D\linker\arm\MCIMX7D_M4_ocram.scf:1: syntax error

and with the file in folder gcc the created elf file suddenly has a size of 2.9 MB instead of 33 kB.

So I have tried to debug the new elf file through eclipse and got the following console output:

Halting target CPU...
...Target halted (PC = 0x00000000)
Read 4 bytes @ address 0x00000000 (Data = 0x00000000)
Read 2 bytes @ address 0x00000000 (Data = 0x0000)
WARNING: Failed to read memory @ address 0xFFFFFFFE
WARNING: Failed to read memory @ address 0xFFFFFFFE
Reading 64 bytes @ address 0x20214180
Read 2 bytes @ address 0x202141A6 (Data = 0x404E)
Read 2 bytes @ address 0x202141A6 (Data = 0x404E)
Read 2 bytes @ address 0x202141A6 (Data = 0x404E)
Received monitor command: regs
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 00000000, MSP= 00000000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 00000000
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Setting breakpoint @ address 0x202141A6, Size = 2, BPHandle = 0x0001
Starting target CPU...
Debugger requested to halt target...
WARNING: CPU could not be halted
Reading all registers
WARNING: CPU could not be halted

I assume the debugger requesting a target halt happened on hitting the breakpoint that was set before?

But halting the target didnt work, so .. hm.

> U-boot may be handy, even without rest (Linux) running.

Not sure how uboot would help me. Maybe by doing the RAM setup?

The current hardware version has neither an USB connector (for mfgtools) nor an SD card slot.

[dry]

Hey,

So the commands as you inserted into Eclipse

eval "monitor memU32 0x00180000 %p", &__stack
eval "monitor memU32 0x00180004 %p", &Reset_Handler + 1

So those set the values SP and PC in the M4 reset control register (if i got the name right), through J-Link. They get loaded to SP,PC respectively, on M4 reset.

(Also note, you can't just hit Eclipse re-load / restart button with the configuration, you have to kill debug session and start it again each time you want to restart).

Set the break point in the reset handler. The temporary bpoint should work  - tbreak .

If you do not get there, there is a setup problem . You should hit it on the debug session start . If you do and can single step then it should all work .. (does for me).

If you suspecting Eclipse setup, I say do JLinkExe  / JLinkGDBServer + gdb from command line first.

[demoniacmilk]

I got a new error message that I hadnt seen before. I am not sure why. Setup should be similar to what was set up before.

Error message from debugger back end:
No symbol table is loaded. Use the "file" command.
Failed to execute MI command:
eval "monitor memU32 0x00180000 %p", &__stack
Error message from debugger back end:
No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.
Failed to execute MI command:
eval "monitor memU32 0x00180004 %p", &Reset_Handler + 1

This is interesting cause it did not appear before. It happens in both cases, Pre-Run/Restart reset ticked or not ticked.

I had changed the startup settings as in removing the custom commands in Run/Restart Commands and ticking Pre-run/Restart reset. Using these options, the debug session starts and Eclipse displays a running thread.
However, I cannot hold the CPU so I cannot read any registers.

I guess its all about finding a way to properly halt/resume CPU functionality and doing the initial setup. I can connect to the M4 using your updated connect script.

Output of JLink.exe on trying to connect:

Device "MCIMX7D7_M4" selected.

Connecting to target via JTAG
*************************************************
J-Link script: iMX7D Cortex-M4 core J-Link script
*************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[1]: APB-AP (IDR: Not set)
AP[2]: CUSTOM-AP (IDR: Not set)
AP[3]: CUSTOM-AP (IDR: Not set)
AP[4]: AHB-AP (IDR: Not set)
AP[4]: Core found
AP[4]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
ROMTbl[0][7]: E0043000, CID: B105900D, PID: 001BB908 CSTF
ROMTbl[0][8]: E0044000, CID: B105900D, PID: 004BB906 CTI
Cortex-M4 identified.

Running the JLinkGDBServer from the windows command line with command

JLinkGDBServerCL.exe -if jtag -speed 300 -scriptfile Devices\NXP\iMX7D\NXP_iMX7D_Connect_CortexM4_DRy_Mod.JLinkScript -device MCIMX7D7_M4

gives the following result (text in bold may be an issue?):

SEGGER J-Link GDB Server V6.30b Command Line Version

JLinkARM.dll V6.30b (DLL compiled Feb 2 2018 18:36:54)

Command line: -if jtag -speed 300 -scriptfile Devices\NXP\iMX7D\NXP_iMX7D_Connect_CortexM4_DRy_Mod.JLinkScript -device MCIMX7D7_M4
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: Devices\NXP\iMX7D\NXP_iMX7D_Connect_CortexM4_DRy_Mod.JLinkScript
J-Link settings file: none
------Target related settings------
Target device: MCIMX7D7_M4
Target interface: JTAG
Target interface speed: 300kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Feb 2 2018 18:12:40
Hardware: V10.10
S/N: 50117772
Feature(s): GDB
Checking target voltage...
Target voltage: 1.81 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x5BA00477 (Cortex-M4)
WARNING: CPU could not be halted
Halting target device failed. Trying again with reset
WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
Connected to target
Waiting for GDB connection...

ill go ahead and start arm-none-eabi-gdb with the elf file to see what happens.

[dry]

Hey,

Lars Heinrichs wrote:

WARNING: CPU could not be halted
Halting target device failed. Trying again with reset
WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
Connected to target
Waiting for GDB connection...

Thats all good, ignore second warning. It attempts the reset which succeeds.

I get same traces too when uploading code.

No symbol table is loaded. Use the "file" command.
No symbol table is loaded. Use the "file" command.

That looks like your binary & symbols were not loaded , check your elf file. The other gdb/monitor commands fail to execute because of that, you didn't load the elf with gdb