iMXRT1050-EVKB runtime difficulties with project based on EVKB SDK v2.3.1

[edw8]

Hello MCUXpresso IDE support team,

We recently received qty 2 IMXRT1050-EVKB boards. Initially I ran into a similar problem as the one mentioned in this post: Download "evkmimxrt1050_demo_apps_hello_world_xip" demo faild on MCUXpresso IDE v10.1.1 

I downloaded the EVKB SDK v2.3.1 and imported it into MCUXpresso IDE. I then created a new project using this EVKB SDK's resources. The project has default settings with FreeRTOS support and assert support selected. I ported out existing project sources that currently only have dependencies on FreeRTOS calls to this new project. 

This new project builds and runs on MIMXRT1050-EVK the same way that it did on EVK-SDK-2.3.0. The project builds, loads, but fails shortly after set to run when using an IMXRT1050-EVKB. I've confirmed this behavior on two EVKB boards so far. The MCUXpresso IDE status bar states "Stalled on bus operation". When the IDE run state is stopped, the attached dialog is thrown by the IDE

Initially I had tried the native EVKB-SDK-2.3.1 hello_world example on the EVKB hardware and that ran without any issues.

I will create a sample FreeRTOS project from the SDK to see whether the behavior can be reproduced, however this appears to be strictly a board rev difference. 

Any ideas or troubleshooting tips are appreciated.

[lpcxpresso_supp]

Sorry for the delay in responding here. We are still looking into the problems that you report, but I suspect that you may be encountering the issue reported in :https://community.nxp.com/thread/474910 

Regards,

MCUXpresso IDE Support

[edw8]

Yes this seems to be the same issue. There are a large number of differences between the clock_config.c generated for a new project from the SDK and the one included in the demo SDK examples. The same is true for clock_config.h. I looked at the items provided in the gpio_led demo. I'm guessing this anomaly is true of other demos which explains why the FreeRTOS mutex demo and the hello world demo ran on the EVKB. 

Once I replaced the clock_config.c and clock_config.h in my project and library, the project ran on the EVKB.

I attached the clock_config.c/.h originals for my project creation from SDK as well as the clock_config.c/.h for the GPIO LED demo.

[lpcxpresso_supp]

First of all, I would suggest making sure that you don't have both the original EVK SDK and the new EVKB SDK installed at the same time.  There appears to be a strange interaction between the two that we are currently looking into.

But that aside, this seems very strange. If I understand you correctly, you are saying that your project runs correctly on the original EVK, but not on the EVKB. Now if you did have both SDKs installed at the same time when you created your project, or even just now, the comment I made above might possibly explain what you are seeing (as there are some differences between the two boards).

Could you clarify exactly what you, from the point that you start your debug session, to the point where you see the problem on the EVKB board.

It might also be worth going to the Breakpoints view before you start your debug session and deleting any breakpoints before you start (as the error does reference breakpoint removal, so I'm wondering if this is related).

If at all possible, it would be helpful if you could export your project (via the option in the Quickstart Panel) and attach it to this thread, so that we can try to replicate exactly what you are seeing.

Could you also provide the text from the debug logs from both debugging the project on the EVK board as well as the EVKB board? [See section 16.8, "The Console View" in the MCUXpresso IDE v10.1 User Guide for details of how to do this].

Regards,

MCUXpresso IDE Support

[edw8]

A small update. I was able to take one of our earlier versions of our project running similar code, ported it to use SDK 2.3.1 in a new workspace (ie: created a new project from the SDK and added in custom sources for our project by hand) and again was only able to test on EVKA. EVKB had the same "Stalled" message.

This project was a single C project (no static library) and was based on redlib with mostly default build options (ie: compiler set to default). It did print to UART using freescale PRINTs and not std lib printf, however the prints were only visible when running on EVKA.

[edw8]

I had a chance to run several tests on both the SDK dependencies and EVK/EVKB boards whose results I would like to share. I may make mention of EVKA vs EVKB behavior. For clarity, I am contrasting MIMXRT1050-EVK (EVKA) vs IMXRT1050-EVKB (EVKB).

First I removed all my existing SDKs. I then imported three new SDKs created today based on SDK v2.3.1: MIMXRT1052xxxxx, MK64FN1M0xxx12, MK28FN2M0xxx15. This gives me access to four of the five eval kits I have to play with. I am hoping that having multiple processor SDKs from the same version within MCUXpresso IDE does not cause issues. 

I created a new workspace and created two new projects – a C++ static library and a C++ project with the same options I used to create my actual projects that have proprietary code. The dependency tree was defined the same way, but I simplified the source by creating a test.hpp header in the C++ static library. This header defined a test class with a single member variable, a vanilla constructor and destructor and an access method that incremented the private var. The constructor, destructor and access method used the cout streaming directive to echo contents to UART.

I then edited the main function in the C++ project to instantiate an object from this library test class. The C++ test project then entered an infinite loop where it prints out the first ten counts for an ongoing counter, after which it calls the object’s access method in the next ten iterations and then runs silently until something overflows negative at which point the bad test code keeps printing "Initializing <negative number>"

Code for the c++ library test class:

class TestLib {

public:

       TestLib() : m_Tracker(0) { cout << "constructor" << "\r" << endl; }

       ~TestLib() { cout << "destructor" << "\r" << endl; }

       void TapTracker(int iter) {

              cout << "TapTracker count " << iter << " -- called " << m_Tracker << " times!\r" << endl;

              m_Tracker++;

       }

private:

       int m_Tracker;

};

Code for the C++ project main() function:

int main(void) {

       /* Init board hardware. */

    BOARD_InitBootPins();

    BOARD_InitBootClocks();

    BOARD_InitBootPeripherals();

       /* Init FSL debug console. */

    BOARD_InitDebugConsole();

    TestLib testLib;

    /* Force the counter to be placed into memory. */

    volatile static int i = 0 ;

    /* Enter an infinite loop, just incrementing a counter. */

    while(1) {

        i++ ;

        if (i < 10) {

             cout << "Initializing: " << i << "\r" << endl;

        }

        else if (i < 20) {

             testLib.TapTracker(i);

        }

    }

    return 0 ;

}

This code builds without issue and loads on both the EVKA and EVKB, however it only runs on the EVKA. It presents the “stalled” status message on EVKB.

I am attaching two items to this post.

1. step by step instructions on how I created the test project and dependent static library, built and tested on both EVK types 

2. an export of the two projects from my test workspace.

I am hoping that this allows you to reproduce the behavior I am seeing. Please let me know if this is not sufficient and I will grab the debug console dumps and include them as well.

[edw8]

Indeed I have multiple SDK's installed. I didn't see a problem doing this as they are contained within discrete zip archives (attached).

I realized that the SDK projects were running out of flash but using on-board SRAM resources. My project is based on SDRAM. At first switching the SDK demo projects from using SRAM to using BOARD_SDRAM resulted in hard faults. A co-worker traced the hard fault from a series of clock initializations that most likely should not be performed when running directly from SDRAM. Once the SDK demos had modified the preprocessor defined symbols to include SKIP_SYSCLK_INIT, those demos started running correctly out of SDRAM on both EVKA and EVKB. 

Adding the same preprocessor SKIP_SYSCLK_INIT define to my original project did not resolve the issue.

Additional differences between my project and the SDK demos are:

   - demos built using redlib (nohost) (C) with no support for floating point prints and scans

   - my project is built using newlibnano (nohost) (C++) with support for floating point prints and scans. Also my project depends on a C++ static lib residing in the same workspace and built as a dependency. 

I am going to run a couple of experiments:

1. I will remove all 2.3.0 SDKs and replace them with chip specific 2.3.1 SDKs

2. I will go thru the process of creating a skeleton project with static lib dependency based on C++ with some test code to see if I can reproduce the issue of running on EVKA but not on EVKB. If I am able to reproduce the issue, I will export that project and post it to the forum. Unfortunately I cannot post my existing project as some of its components are proprietary.

Will let you know what I find.