Program not reaching ResetISR, appears to be stuck in BOOTROM

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

Program not reaching ResetISR, appears to be stuck in BOOTROM

Jump to solution
1,855 Views
CraigCo
Contributor III

I am using the imxrt1060 evk with MCUXpresso (v10.3.1 [Build 2233] [2019-02-20]) and MQX. I'm attempting to build my project with C++ using Newlib-nano.

Starting a debug session does not reach my code. It doesn't even reach the entry point ResetISR. When I stop the debugger, the PC is in the same region, but not exactly the same location. Examples:

pc    0x2173a6    Program Counter (r15)

pc    0x20e362    Program Counter (r15)

I checked the reference manual and this is the ROMCP.

FYI, this same board works with other projects, and this project does not work on other boards. So there is definitely a project specific issue that I cannot figure out.

Here are the steps I've taken:

  1.  I have been able to build and start debugging the SDK example "evkmimxrt1060_iled_blinky_SWO " after following a similar process to below. I added a cpp file and it built, ran as expected.
  2. Changed project nature to C++ by doing New > Other > Convert to a C/C++ Project (Adds C/C++ Project Nature)
    1. note: at this point the program makes it to ResetISR. From here to get the project to build there are a lot of changes and I don't know how to narrow down the issue.
  3. Changed all libraries (bsp,psp,etc)  used in the same fashion
  4. Ensured that all libraries and project are building with Newlib-nano libraries
  5. Clean rebuild everything
    1. Had to supply system call definitions for _exit, _kill, _getpid, _write, _close, _fstat, _isatty, _lseek, _read. They are all dummy implementations and have infinite loops for now. Does this exist already?
    2. Had to include each library several times for it to find symbols
    3. Defined the same symbols for C++ as with C. The _REDLIB_ was replaced with _NEWLIB_
  6. Linker file(s)
    1. Tried using the same linker files with the Redlib libraries replaced by Newlib libraries.
    2. Tried instead using the "Managed linker script" option.
    3. Diff'ing the generated linker files, the linker files that worked with my previous C project config and also with the evkmimxrt1060_iled_blinky_SWO didn't shed any light.
  7. Made sure that ResetISR is extern C'd. I found extern "C" in the startup code already so I assume any C/C++ linkage issues have already been resolved, plus again I got it working with an example project.
  8. I've tried on a different eval board, same result.
  9. FWIW, the boot dip switch SW7 setting is off-off-on-off (1-2-3-4).

Linker file sections that changed from C to C++ setups (if the entire contents are needed I can add them):

Previous C Libraries:

GROUP (
  "libcr_semihost_nf.a"
  "libcr_c.a"
  "libcr_eabihelpers.a"
)

New C++ Config:

GROUP (
  "libgcc.a"
  "libc_nano.a"
  "libstdc++_nano.a"
  "libm.a"
  "crti.o"
  "crtn.o"
  "crtbegin.o"
  "crtend.o"
  "libcr_newlib_none.a"
)

***** Find the added section wrapped in my comments

.text : ALIGN(4)
    {
        *(KERNEL)
       *(.text*)
       *(.rodata .rodata.* .constdata .constdata.*)
       . = ALIGN(4);

/* START OF NEW SECTION FOR C++ */
            /* C++ constructors etc */
            . = ALIGN(4);
            KEEP(*(.init))
            
            . = ALIGN(4);
            __preinit_array_start = .;
            KEEP (*(.preinit_array))
            __preinit_array_end = .;
            
            . = ALIGN(4);
            __init_array_start = .;
            KEEP (*(SORT(.init_array.*)))
            KEEP (*(.init_array))
            __init_array_end = .;
            
            KEEP(*(.fini));
            
            . = ALIGN(4);
            KEEP (*crtbegin.o(.ctors))
            KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
            KEEP (*(SORT(.ctors.*)))
            KEEP (*crtend.o(.ctors))
            
            . = ALIGN(4);
            KEEP (*crtbegin.o(.dtors))
            KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
            KEEP (*(SORT(.dtors.*)))
            KEEP (*crtend.o(.dtors))
            . = ALIGN(4);
            /* End C++ */

/* END OF NEW SECTION FOR C++ */
    } > BOARD_FLASH

0 Kudos
1 Solution
1,671 Views
CraigCo
Contributor III

Wanted to follow this up. I fixed my problem. It turned out not to be related at all to C/C++ linkage. I can reliably recreate the behavior by simply linking to a library that has the xip files instead of including them in the project directly. I still don't understand this because the files are identical, the projects have identical board.h files, the are both made from the exact same SDK, etcetera. If anyone can shed light on this I'd love to learn.

Resolution: 

Ensure the main project (the one making the executable) is building the xip files, not linking to a library containing them

Setup information:

Eval board MIMXRT1060-EVK (SCH-313357 Rev.A2)

MCUXpresso IDE v10.3.1 [Build 2233] [2019-02-20]

SDK_2.x_EVK-MIMXRT1060  version 2.5.1

XIP_DEVICE driver version 2.0.0.

J-Link PLUS debugger

Steps to reproduce:

Click on Import SDK example(s)...

Select evkmimxrt1060, click Next

Import a simple project ( I used the "iled_blinky" demo)

Add a basic C static library to the project (see steps below if needed)

Exclude the xip folder from the build (Right click on project, Resource Configurations, Exclude from Build...)

Now build and load the program to the board, it will not boot. If you suspend the debugger you will find the PC in the bootrom address range.

Steps to add a basic library (if needed):

Create a C static library for the same board:

Click New project...

Leave everything to default except change to C Static Library

Click Finish

Build the library

Add the library to the evkmimxrt1060_iled_blinky project:

Properties>Paths and Symbols>Libraries, click Add..., enter library name (default for me was MIMXRT1062xxxxA_Project)

Properties>Paths and Symbols>Library Paths, click Add..., click Workspace..., select the folder containing the .a file (in my case this was /MIMXRT1062xxxxA_Project/Debug). It will only be there after you build.

View solution in original post

0 Kudos
3 Replies
1,672 Views
CraigCo
Contributor III

Wanted to follow this up. I fixed my problem. It turned out not to be related at all to C/C++ linkage. I can reliably recreate the behavior by simply linking to a library that has the xip files instead of including them in the project directly. I still don't understand this because the files are identical, the projects have identical board.h files, the are both made from the exact same SDK, etcetera. If anyone can shed light on this I'd love to learn.

Resolution: 

Ensure the main project (the one making the executable) is building the xip files, not linking to a library containing them

Setup information:

Eval board MIMXRT1060-EVK (SCH-313357 Rev.A2)

MCUXpresso IDE v10.3.1 [Build 2233] [2019-02-20]

SDK_2.x_EVK-MIMXRT1060  version 2.5.1

XIP_DEVICE driver version 2.0.0.

J-Link PLUS debugger

Steps to reproduce:

Click on Import SDK example(s)...

Select evkmimxrt1060, click Next

Import a simple project ( I used the "iled_blinky" demo)

Add a basic C static library to the project (see steps below if needed)

Exclude the xip folder from the build (Right click on project, Resource Configurations, Exclude from Build...)

Now build and load the program to the board, it will not boot. If you suspend the debugger you will find the PC in the bootrom address range.

Steps to add a basic library (if needed):

Create a C static library for the same board:

Click New project...

Leave everything to default except change to C Static Library

Click Finish

Build the library

Add the library to the evkmimxrt1060_iled_blinky project:

Properties>Paths and Symbols>Libraries, click Add..., enter library name (default for me was MIMXRT1062xxxxA_Project)

Properties>Paths and Symbols>Library Paths, click Add..., click Workspace..., select the folder containing the .a file (in my case this was /MIMXRT1062xxxxA_Project/Debug). It will only be there after you build.

0 Kudos
1,671 Views
converse
Senior Contributor V

Did you remember to define ALL of your exception/interrupt handlers as 

extern C

?

0 Kudos
1,671 Views
CraigCo
Contributor III

There was already an extern C around the forward declarations. I just extern C'd the entire file containing the vector table - startup_mimxrt1062.c. Still stuck in the ROMCP section. Thanks for the advice.

0 Kudos