MIMXRT1170-EVKB multicore example question...

[EdSutter]

This is my first bit of experience with a low-level (not Linux) multicore device, so this may be a stupid question...

I'm walking through sections 6.4 and 6.5 of  "Getting Started with MCUXpresso SDK for MIMXRT1170-EVKB" (Rev. 0 — 31 December 2022), which refers to SDKTOP/boards/evkbmimxrt1170/multicore_examples/hello_world.  I'm working with SDK-2-16-100_MIMXRT1170-EVKB. I also have a JLink programmer attached to the 20-pin header on the EVKB.

I was able to build/load/run the cm4/cm7 applications the first time, but I didn't quite follow the instructions cause they don't make sense to me (I had to run gdb/load for both cores).

Section 6.4 says to "build" each of the applications.  That's fine; but section 6.5 says: "..The primary core debugger handles flashing of both the primary and the auxiliary core applications into the SoC flash memory...".  Is that correct? I found that I had to execute the "load" operation (using gdb) for each of the cores to get anything to work.

In addition, I tried to make a minor change to the CM4 code and it doesn't seem to be programming.  Does gdb's "load" also erase everything prior to programming?

Any thoughts here would be appreciated.

Thanks

[Pavel_Hernandez · Accepted solution]

Hello, my name is Pavel, and I will be supporting your case, I found this app notes where this could help you to understand more about the dual core process, please see the chapter 2.1.2 Detailed Boot flow.

There is some similar argument, maybe could help to understand.
"..The primary core debugger handles flashing of both the primary and the auxiliary core applications into the SoC flash memory..."

i.MX RT1170 Dual Core Application

Maybe this other thread could help you to test it on the IDE.

How to use JLINK to debug RT1170 dual core - NXP Community

Best regards,
Pavel

[EdSutter]

Ok, I think I get it now...

@Pavel_Hernandez , the pdf was quite useful, but the thread is just a set of instructions that tell you what buttons to push in the IDE.  Not much good if trying to really understand things.

I see now that the CM4's image is actually incorporated into the CM7's image as a section called ".core1_code".  The CM7's build depends on the CM4 image being built prior, so one of the CM7's build steps is to incorporate the CM4 image into the memory map of the CM7.  That explains why when doing a "load" when in gdb with the cm4, it was not being pushed to actual SPI flash space.  I don't really like the way this is done, but that's ok.  At least I understand it now.

Thanks much, big help!

[EdSutter]

More information...
I just noticed that my JLinkGDBServerCLExe window shows the following errors after I run "load" in gdb...
ERROR: Timeout while preparing target, RAMCode did not respond in time!
Failed to perform RAMCode-sided Prepare()
Error while determining flash info (Bank @ 0x30000000)

[EdSutter]

Well I don't want to claim that this fixed the problem, but I did manage to get both cores to execute my code...

I was/am suspicious of how gdb tells JLINK to write to flash, so instead of using gdb hooked to the jlink gdb server, I just created a simple jlink script that would load each of the sections manually (see below).  To do that I needed to extract each of the loadable sections from the .elf file into their own binary file. 

With each of the files created I was able to run this script:

eoe 1
device=MIMXRT1176DVMAA_cm7
speed 4000
si SWD
r
h
loadbin elfsect_.flash_config.bin,0x30000400
loadbin elfsect_.ivt.bin,0x30001000
loadbin elfsect_.core1_code.bin,0x33fc0000
loadbin elfsect_.interrupts.bin,0x30002000
loadbin elfsect_.text.bin,0x30002400
loadbin elfsect_.ARM.bin,0x30008d00
loadbin elfsect_.init_array.bin,0x30008d08
loadbin elfsect_.fini_array.bin,0x30008d0c
loadbin elfsect_.data.bin,0x30008d10
go
exit

to load the CM7 and things worked.  It appears that while the jlink server was saying that it verified the download, the verification was failing.

Can someone (NXP support) explain this?