SPT 8 fail to detect entry point of elf

[mastupristi]

Hello,,

SPT seems to misdetect the entry point of one of my elf

the popup reports 0x0000 as the entry point while readelf correctly detects it at 0x30002101

even exporting the binary data from the .vector section I find the right entry point

The doubt I have is that my .vector section will have to reside in ITC (VMA 0x0000) and has LMA 0x300508c4

in linker script:

If this was the problem how can I deal with it?

EDIT:

I tried placing the .vector section in flash (at 0x30002000), modifying the linker script. By doing this, SPT 8 no longer detects problems. However we have to have the .vectors section in ITC for application needs, so I guess this must be considered a bug. Besides, SPT 7 and SPT 6 have always worked correctly with my elfs.

best regards

Max

[liborukropec · Accepted solution]

Hello Massimiliano,

I did a quick test and I can see the same error in v8 and no error for the "upcoming" version. So without further deep analysis it looks like an error in the tool or underlying library, than in your application.

At this moment I do not see other workaround other than using fake source image, e.g.

1. copy <SEC_INSTALL>\bin\_internal\data\targets\MIMXRT1176\source_images\evkmimxrt1170_iled_blinky_cm7_QSPI_FLASH.s19 to destination where the final SREC (if you can convert elf to SREC)
   1. conversion of elf to srec can be done using `nxpimage utils binary-image convert -i source.elf -o target.s19-f S19`
      nxpimage is located in <SEC_INSTALL>/bin/_internal/tools/spsdk
2. select on Build tab this SREC, hit build button
3. on Write tab write the application (or just update the write script)
4. Close Sec GUI
5. replace the SREC file with your application
6. double check / tweak the BD file in the <workspace>/bd_files/<yourapp>.bd
7. edit <workspace>/write_image_* script and manually tweak the erase region size (it will be bigger than the example app)
8. manually execute the build and then write script from command line

Migrate to SEC to v9, once it is available (~1 month - I cannot promise exact date).

Regards,

Libor

[mastupristi]

Hi @liborukropec 

I did a quick test and I can see the same error in v8 and no error for the "upcoming" version.

I don't know how you can say that with the “upcoming” version it works for you.
I tried SPT9 with the file I attached in the first post and the result is identical to SPT8:

I remind you again that with STP7 this same file worked, which is why I consider this bug a regression,

regards

[liborukropec]

Hi,

Image is parsed, but the `XIP` is not detected as in compare to v7. I'll share with the team for analysis and we'll be back to you.

Regards,
Libor

[marek-trmac]

Hi @mastupristi ,

I'm analyzing the problem. The SEC tool found the image is located in memory at address 0x30002000. SEC tool expects the image starts with the interrupt vector address, so it loads the reset vector from the 0x30002004. It founds reset vector 0, so SEC tool assumes it is non XIP (load-to-RAM) image. 

It seems the image format is different than SEC tool expects. Can you please confirm? Can you provide more information, where the interrupt vector table is located?

For S19, the entry point is explicitly specified in the S19 file, so there is no such issue.

Thank you

[mastupristi]

Hi @marek-trmac 

it loads the reset vector from the 0x30002004. It founds reset vector 0, so SEC tool assumes it is non XIP (load-to-RAM) image.

It seems the image format is different than SEC tool expects. Can you please confirm? Can you provide more information, where the interrupt vector table is located?

I have .vectors section that has VMA @0x00000000 (so it is located into ITCM) but has LMA in flash. This is for performance requirements.

the LMA address is decided by the linker (in this case is 0x300508c4) and I don't think there is any way to force it.

This is a completely legitimate scenario that therefore must be covered by SPT, or the documentation must clearly describe what the constraints are on the use of the tool.
Either way being the possible scenario, NXP must describe a way to deal with it.

So in my opinion the way to get the entry point is another way, and here I link to another statement you made:

For S19, the entry point is explicitly specified in the S19 file, so there is no such issue.

Even in elf the entry point is specified:

so it's possible to get the entry point from the.elf instead of reading it to a specific address in the flash.

In fact, it's possible for design requirements that you may need to move the interrupt vector to other addresses as well (e.g., 0x30004400), and even then it couldn't work.

best regards

[marek-trmac]

Hi @mastupristi ,

thank you for detailed information. For next release, we will improve documentation and describe more requirements about image format (chapter 5.2.1)

We will also investigate whether we could retrieve entry point from ELF

[marek-trmac]

We will add the following paragraph:

The SEC tool partially parses the image to retrieve entry point, to detect whether the image is XIP and validate the target address. In S19 file format, the entry point can be listed explicitly, while for the other formats the entry point is retrieved from interrupt vector table (so interrupt vector table must be at the beginning of the application image).

[mastupristi]

Hi @liborukropec 

Image is parsed, but the `XIP` is not detected as in compare to v7

it seems clear to me that if I use SPT it is to get a working image. My micro has both XIP and HAB enabled.
And SPT9 misinterprets the elf and “thinks” that it should be run from external RAM (exactly as SPT8 did)

regards

Max