IMXRT1050-EVKB and J-Link state

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMXRT1050-EVKB and J-Link state

3,489 Views
andrew_walsh
Contributor II

Hello,

I'm trying to run one of the MCUXpresso demos (for Ethernet) on an IMXRT1050-EVK board, using a Segger J-Link Pro.

However, when I do this, it does not work. The firmware (which I've linked for RAM) seems to be downloaded, but the PC (and most of the other registers) end up at the location 0xDEADBEEE ("Break at address "0xdeadbeee" with no debug information available, or outside of program code.").

I get lots of error messages in the Disassembly view indicating that the memory address 0xDEADBExx cannot be accessed.

I then inspect the JLinkServer JLink<serial number> console. The messages appear to indicate that the target is reset (using the supplied JLink script), the RAM is programmed seemingly successfully.

It then sets the PC to an odd value (0xF0020080, but the image is loaded into RAM, starting at 0x80000000), some other things and then says "Starting target CPU...". After this point, there are messages of the sort "ERROR: Can not read register 0 (R0) while the CPU is running" and the access failures listed above.

I've included the text of the console as an attachment. I'm using MCUXpresso IDE v10.2.1 (build 795) and J-Link firmware v6.42f

Right now, I cannot get my development board to behave in any other way. I reset, power-cycle, reboot my development PC, etc, but all to no avail. If I try to connect and run code using JLink Commander, however, I do not seem to have these problems.

Sometimes I've seen this problem (or similar) caused by selecting a slightly wrong target processor (e.g. IMXRT1051 instead of IMXRT1052), but I've double-checked the processor type, so I don't think that's it.

What could I have done wrong here? It's getting frustrating!

Thanks,

Andrew.

0 Kudos
6 Replies

2,534 Views
andrew_walsh
Contributor II

Hi,

With our own PCB, I've been getting a problem like this, again, this morning (see my initial post, but, as far as I can see, without the endian issues, and the GDB Server Endian setting *is* set correctly), and I've no idea why.

It seemed to work before.

Best regards,

Andrew.

0 Kudos

2,535 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

Yes, default is little endian. All the kinetis and imxRT devices supported by MCUXpresso is little endian. It seems strange. MCUXpresso is updated to 10.3 now. Maybe you can update to new version.

Regards,

Jing

0 Kudos

2,535 Views
andrew_walsh
Contributor II

Hi Jing,

Well, as of this morning, most of my problems have gone away (although I've not updated MCUXpresso yet)!

I was pretty much unable to do anything yesterday (single stepping the first instruction would fail, which is the real reason for what I mentioned in my post yesterday) . I had previously updated my J-Link firmware to the latest version, as part of trying to fix the problem described in the original post, but it made no difference. Before I left the office yesterday, I downgraded it back to 6.40, and things are much better this morning, so perhaps the later J-Link version (or some incompatibility) was the cause of this problem.

Thanks,

Andrew.

0 Kudos

2,535 Views
andrew_walsh
Contributor II

Further to the above, I added some commands to the debug configuration run commands. As follows:

monitor halt
monitor reg PC
monitor reg MSP
monitor reg MSP=0x82000000
monitor reg MSP

I then examined the debug console output, and the behaviour was very strange. Below is the output of the added commands.

Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0xF0020080)
Received monitor command: reg PC
Reading register (PC = 0x800002F0)
Received monitor command: reg MSP
Reading register (F1 = 0x00102020)
Received monitor command: reg MSP=0x82000000
Writing register (F1 = 0x82000000)
Received monitor command: reg MSP
Reading register (F1 = 0x00000082)

Previously, the PC was set, as follows:


Writing register (PC = 0xf0020080)

It looks like there is a mix of little endian and big endian values when accessing the same processor registers (in this case, the PC and MSP)! This leads me not to trust what could be going on under the surface...

Andrew.

0 Kudos

2,535 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

Can you download code from the on board openSDA debugger?

Regards,

Jing

0 Kudos

2,535 Views
andrew_walsh
Contributor II

Hi Jing,

Thanks for your fast response.

Today, I've got it to work; there was a setting for the GDB Server Endian in the debug configuration: it was set to "big" and changing it to "little" made the problem go away. This is progress, but:

1. I have no memory of changing this setting and I didn't have to change this when I created a project previously. Assuming I hadn't changed it by accident (which I admit is possible!), can we sure that the default will always be little (i.e. matching the IMXRT1052)?

2. Even though this endian setting *was* incorrect, I was still surprised to notice what appeared to be two different endian values in the messages displayed in the console (see my comment immediately before yours); I would expected them to be consistently wrong.

Best regards,

Andrew.

0 Kudos