CCS/TM4C1294NCPDT: Build and load results in abnormal termination and register dump

Carlos Alva

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL, SYSBIOS, , UNIFLASH

Tool/software: Code Composer Studio

Greetings,

I am trying to run the tcpEcho example on a custom board which has an Ethernet section the same as the one in the EK-TM4C1294XL development kit.

When loading the code (proven to run in the development kit, verifying tools and related equipment) it fails with the following output:

FSR = 0x0004
HFSR = 0x40000000
DFSR = 0x00000000
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
Terminating execution...

Tracing execution, the code enters an abnormal termination at Hwi_HwiProxy_switchFromBootStack(); (Hwi.c)

The error is non recoverable.

In order to run with a fixed IP address the following was added to the *.cfg file

Ip.autoIp = false;
Ip.address = "192.168.1.12";
Ip.mask = "255.255.255.0";
Ip.domainName = "mydomain";
Ip.socketMaxConnections = 4;
Ip.socketTimeToLive = 64;

This was confirmed to work with the SDK.

Several of my colleagues have reported the same issue on different projects. It is suspected that there is a configuration issue for the tool.

I would appreciate to be able to speak to an engineer that would help getting passed this issue. Development time is seriously impacted.

Thank you

over 6 years ago

0 Carlos Alva over 6 years ago

Prodigy 170 points

Greetings,

More information on the subject.

ROV evaluation data:

address 0x2000fb64

activeInterrupt: 3

pendingInterrupt: 35

Exception: Yes

hwiStackPeak: 956

hwiStackSize: 2048

Basic Data:

Type: dispatched

Int No: 35

Priority: 224

Group: 7

fxn: ti_sysbios_family_arm_lm4_Timer_isrStub_E

Decoded: Hard Fault: FORCED:USAGE:INVPCBUSFAULT:IBUSERR

Exception Context
$addr 0x2000f5b4

$type ti.sysbios.family.arm.m3.Hwi.ExcContext

ThreadType ti.sysbios.BIOS.ThreadType_Task

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Can you confirm if the identical code runs on the launchpad but not the custom board? If the identical code runs on the launchpad but not your custom board then it seems to have something to do with the custom board. If you have a different code that is creating the hard fault problem, can you run this code on the launchPad? Does it fail the same?

In the meantime, this video may have you troubleshoot common TI-RTOS issues.

https://training.ti.com/debugging-common-application-issues-ti-rtos

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles,

The only thing different between the development kit and the custom board is that the custom board uses JTAG as the debug interface (Segger J-Link) and does not have the Stellaris device.

The code is the tcpEcho example and it has been reduced to the least possible:

int main(void)
{
    /* Call board init functions */
    //Board_initGeneral();
    //Board_initGPIO();
    //Board_initEMAC();

    //System_printf("Starting the TCP Echo example\nSystem provider is set to "
    //              "SysMin. Halt the target to view any SysMin contents in"
    //              " ROV.\n");
    /* SysMin will only print to the console when you call flush or exit */
    //System_flush();

/* Start BIOS */
BIOS_start();

return (0);
}

Only running BIOS, the fault is the same at any point (systematic commented out the Board calls in main.

Still there is an exception 11 for a pending interrupt 35 apparently a timer.

Could you provide more information about this interrupt?

I am hopping that this is tied to a pin that we may have not tied down (or up) with a pull up or pull down resistor causing a spurious interrupt.

I am tying to map this interrupt to an actual pin or a configuration.

Conversely if there is a way to mask this interrupt so that it does not triggers it would probably help.

Thank you for your support,

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Yes, the interrupt 35 is the Timer0. Please note that the Timer0 is taken by BIOS for the system tick. What you are seeing is normal even in the absence of the EMAC. Are you saying that with only the BIOS_start() and everything else commented out, you are getting a hard fault or you are just getting an timer0 interrupt?

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Indeed!!

0 Carlos Alva over 6 years ago in reply to Carlos Alva

Prodigy 170 points

I meant the hard fault is still observed with only the BIOS_start();

I am using the Segger J-Link jtag interface.

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

ok, I'm going to run the same example (the tcpEcho_EK_TM4C1294XL_TI) on my LaunchPad to see if I can reproduce it. I want to make sure two things.

1. You can observe the hard fault with the tcpEcho_EK_TM4C1294XL_TI example as is. The example you are using is the below one.

2. You can observe the hard fault on the launchPad board.

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles,

Yes that is the example and it fails with only the BIOS_start() call in my custom board.

At this point there should be no interaction with anything external other than the clock which is providing the 25MHz and is structured the same as the development kit.

The difference is that in the development kit the debug interface is through the Stelaris device while in my board it is J-Link (Segger) I don't assume that is the issue.

I have ran other examples such as the uart_echo and the blinky with no issues.

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Can you please answer me if you have run the exact same example on the 'launchPad', not your custom board? I can only run the example on the launchPad. I've just run it for a couple of minutes and I don't see any hard fault.

I don't think the debug interface has anything to do with the problem.

At the bottom of this post, I attached the tcpEcho example I just run. I didn't comment out any lines. I just run as is. I do not see any hard fault. Again, I run it on my launchPad. This is the reason I asked if you can see the hard fault on the launchPad. If you can see the hard fault on launchPad, then we can debug the problem. If the problem only occurs on your custom board then it will be more difficult. I don't know if there is any difference between the example you run and mine. Therefore, I suggest you try my attached example. If you can see hard fault, then please let me know how long you need to run to see it.

I use the provided executable tirtos_tivac_2_16_00_08\packages\examples\tools\tcpSendReceive.exe to send/receive data with the MCU. For details. refer to the tcpEcho_readme.txt file in the project directory.

Below is the screenshot on the PC side.

Below is the console on the MCU side. As can be seen I don't see the hard fault after running for a couple of minutes.

Here is the example project I used.

tcpecho.zip

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

The example runs in the development board (I believe that was in the problem statement).

This effort is already passed that point in which I am attempting to get the same example running on the custom board configured in the same manner as the development kit.

The initial estimation was that there is something essentially different in HW that caused the Hard fault, however, the nature of the fault that being a timer interrupt which is not connected to any external input and by removing all other executing code to isolate BIOS_start() is the reason for my reaching to you (I have already done the A and B comparison and have already tested my computer, cables, development kit, compiler environment, code and others)

At this point I would like to figure out the reason for that Hard Fault specially if it is an internal process (internal resource).

I mentioned before that one difference is the use of the JTAG interface and perhaps there is a timing issue with the HW or there is a configuration difference. Other colleagues using the same processor with custom boards different than mine also see the same issue (they too use the JTAG interface.)

Thank you for your help,

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Thank you for confirming that the problem is only observed on your customer board. Honestly, I can't connect the dots yet as to why the same code will produce different results in two different boards.

1. Can you tell me which ti-rtos version you are running? I'm using tirtos_tivac_2_16_00_08. Although your problem seems to be hardware related, I still wanted to make sure the software doesn't play any role in your problem.

2. Can you increase the stack size? Again, most likely it won't make a difference to the result, I just wanted to try different knobs.

3. Have you compared your board schematic with the launchPad schematic? Is there any difference?

4. Can you try the non TI-RTOS ethernet example? The TivaWare library has some Ethernet examples such as enet_io and enet_lwip. What happen if you run these examples on your custom board? Run them on both your launchPad and custom board. Will you again see fault only on the custom board but not the launchPad?

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

I have tirtos_tivac_2_16_00_08.

I will follow your recommendation and change the stack size to test.

I have compared the schematics for this section in specific. They are the same including components.

I will also try other examples for the tiva sources.

Thank you for your support

0 Carlos Alva over 6 years ago in reply to Carlos Alva

Prodigy 170 points

Hello Charles,

Would the report below be related?

In case here is my config file:

/* ================ Clock configuration ================ */
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
/*
* Default value is family dependent. For example, Linux systems often only
* support a minimum period of 10000 us and multiples of 10000 us.
* TI platforms have a default of 1000 us.
*/
Clock.tickPeriod = 1000;

/* ================ Defaults (module) configuration ================ */
var Defaults = xdc.useModule('xdc.runtime.Defaults');
/*
* A flag to allow module names to be loaded on the target. Module name
* strings are placed in the .const section for debugging purposes.
*
* Pick one:
* - true (default)
*      Setting this parameter to true will include name strings in the .const
*      section so that Errors and Asserts are easier to debug.
* - false
*      Setting this parameter to false will reduce footprint in the .const
*      section. As a result, Error and Assert messages will contain an
*      "unknown module" prefix instead of the actual module name.
*/
Defaults.common$.namedModule = true;
//Defaults.common$.namedModule = false;

/* ================ Error configuration ================ */
var Error = xdc.useModule('xdc.runtime.Error');
/*
* This function is called to handle all raised errors, but unlike
* Error.raiseHook, this function is responsible for completely handling the
* error with an appropriately initialized Error_Block.
*
* Pick one:
* - Error.policyDefault (default)
*      Calls Error.raiseHook with an initialized Error_Block structure and logs
*      the error using the module's logger.
* - Error.policySpin
*      Simple alternative that traps on a while(1) loop for minimized target
*      footprint.
*      Using Error.policySpin, the Error.raiseHook will NOT called.
*/
Error.policyFxn = Error.policyDefault;
//Error.policyFxn = Error.policySpin;

/*
* If Error.policyFxn is set to Error.policyDefault, this function is called
* whenever an error is raised by the Error module.
*
* Pick one:
* - Error.print (default)
*      Errors are formatted and output via System_printf() for easier
*      debugging.
* - null
*      Errors are not formatted or logged. This option reduces code footprint.
* - non-null function
*      Errors invoke custom user function. See the Error module documentation
*      for more details.
*/
Error.raiseHook = Error.print;
//Error.raiseHook = null;
//Error.raiseHook = "&myErrorFxn";

/*
* If Error.policyFxn is set to Error.policyDefault, this option applies to the
* maximum number of times the Error.raiseHook function can be recursively
* invoked. This option limits the possibility of an infinite recursion that
* could lead to a stack overflow.
* The default value is 16.
*/
Error.maxDepth = 2;

/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
* Checks for Hwi (system) stack overruns while in the Idle loop.
*
* Pick one:
* - true (default)
*      Checks the top word for system stack overflows during the idle loop and
*      raises an Error if one is detected.
* - false
*      Disabling the runtime check improves runtime performance and yields a
*      reduced flash footprint.
*/
halHwi.checkStackFlag = true;
//halHwi.checkStackFlag = false;

/*
* The following options alter the system's behavior when a hardware exception
* is detected.
*
* Pick one:
* - Hwi.enableException = true
*      This option causes the default m3Hwi.excHandlerFunc function to fully
*      decode an exception and dump the registers to the system console.
*      This option raises errors in the Error module and displays the
*      exception in ROV.
* - Hwi.enableException = false
*      This option reduces code footprint by not decoding or printing the
*      exception to the system console.
*      It however still raises errors in the Error module and displays the
*      exception in ROV.
* - Hwi.excHandlerFunc = null
*      This is the most aggressive option for code footprint savings; but it
*      can difficult to debug exceptions. It reduces flash footprint by
*      plugging in a default while(1) trap when exception occur. This option
*      does not raise an error with the Error module.
*/
m3Hwi.enableException = true;
//m3Hwi.enableException = false;
//m3Hwi.excHandlerFunc = null;

/*
* Enable hardware exception generation when dividing by zero.
*
* Pick one:
* - 0 (default)
* Disables hardware exceptions when dividing by zero
* - 1
* Enables hardware exceptions when dividing by zero
*/
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;

/*
* Enable hardware exception generation for invalid data alignment.
*
* Pick one:
* - 0 (default)
* Disables hardware exceptions for data alignment
* - 1
* Enables hardware exceptions for data alignment
*/
m3Hwi.nvicCCR.UNALIGN_TRP = 0;
//m3Hwi.nvicCCR.UNALIGN_TRP = 1;

/* ================ Idle configuration ================ */
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
/*
* The Idle module is used to specify a list of functions to be called when no
* other tasks are running in the system.
*
* Functions added here will be run continuously within the idle task.
*
* Function signature:
* Void func(Void);
*/
//Idle.addFunc("&myIdleFunc");

/* ================ Kernel (SYS/BIOS) configuration ================ */
var BIOS = xdc.useModule('ti.sysbios.BIOS');
/*
* Enable asserts in the BIOS library.
*
* Pick one:
* - true (default)
* Enables asserts for debugging purposes.
* - false
* Disables asserts for a reduced code footprint and better performance.
*/
//BIOS.assertsEnabled = true;
BIOS.assertsEnabled = false;

/*
* Specify default heap size for BIOS.
*/
BIOS.heapSize = 20480;

/*
* A flag to determine if xdc.runtime sources are to be included in a custom
* built BIOS library.
*
* Pick one:
* - false (default)
*      The pre-built xdc.runtime library is provided by the respective target
*      used to build the application.
* - true
*      xdc.runtime library souces are to be included in the custom BIOS
*      library. This option yields the most efficient library in both code
*      footprint and runtime performance.
*/
BIOS.includeXdcRuntime = false;
//BIOS.includeXdcRuntime = true;

/*
* The SYS/BIOS runtime is provided in the form of a library that is linked
* with the application. Several forms of this library are provided with the
* SYS/BIOS product.
*
* Pick one:
*   - BIOS.LibType_Custom
*      Custom built library that is highly optimized for code footprint and
*      runtime performance.
*   - BIOS.LibType_Debug
*      Custom built library that is non-optimized that can be used to
*      single-step through APIs with a debugger.
*
*/
BIOS.libType = BIOS.LibType_Custom;
//BIOS.libType = BIOS.LibType_Debug;

/*
* Runtime instance creation enable flag.
*
* Pick one:
*   - true (default)
*      Allows Mod_create() and Mod_delete() to be called at runtime which
*      requires a default heap for dynamic memory allocation.
*   - false
*      Reduces code footprint by disallowing Mod_create() and Mod_delete() to
*      be called at runtime. Object instances are constructed via
*      Mod_construct() and destructed via Mod_destruct().
*/
BIOS.runtimeCreatesEnabled = true;
//BIOS.runtimeCreatesEnabled = false;

/*
* Enable logs in the BIOS library.
*
* Pick one:
* - true (default)
*      Enables logs for debugging purposes.
* - false
*      Disables logging for reduced code footprint and improved runtime
*      performance.
*/
//BIOS.logsEnabled = true;
BIOS.logsEnabled = false;

/* ================ Memory configuration ================ */
var Memory = xdc.useModule('xdc.runtime.Memory');
/*
* The Memory module itself simply provides a common interface for any
* variety of system and application specific memory management policies
* implemented by the IHeap modules(Ex. HeapMem, HeapBuf).
*/

/* ================ Program configuration ================ */
/*
* Program.stack is ignored with IAR. Use the project options in
* IAR Embedded Workbench to alter the system stack size.
*/
if (!Program.build.target.$name.match(/iar/)) {
    /*
     * Reducing the system stack size (used by ISRs and Swis) to reduce
     * RAM usage.
     */
Program.stack = 4096;
}

/*
* Enable Semihosting for GNU targets to print to CCS console
*/
if (Program.build.target.$name.match(/gnu/)) {
    var SemiHost = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');
}
/* ================ Semaphore configuration ================ */
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');
/*
* Enables global support for Task priority pend queuing.
*
* Pick one:
* - true (default)
*      This allows pending tasks to be serviced based on their task priority.
* - false
*      Pending tasks are services based on first in, first out basis.
*
* When using BIOS in ROM:
*      This option must be set to false.
*/
//Semaphore.supportsPriority = true;
Semaphore.supportsPriority = false;

/*
* Allows for the implicit posting of events through the semaphore,
* disable for additional code saving.
*
* Pick one:
* - true
*      This allows the Semaphore module to post semaphores and events
*      simultaneously.
* - false (default)
*      Events must be explicitly posted to unblock tasks.
*
*/
//Semaphore.supportsEvents = true;
Semaphore.supportsEvents = false;

/* ================ Swi configuration ================ */
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
/*
* A software interrupt is an object that encapsulates a function to be
* executed and a priority. Software interrupts are prioritized, preempt tasks
* and are preempted by hardware interrupt service routines.
*
* This module is included to allow Swi's in a users' application.
*/

/* ================ System configuration ================ */
var System = xdc.useModule('xdc.runtime.System');
/*
* The Abort handler is called when the system exits abnormally.
*
* Pick one:
* - System.abortStd (default)
*      Call the ANSI C Standard 'abort()' to terminate the application.
* - System.abortSpin
*      A lightweight abort function that loops indefinitely in a while(1) trap
*      function.
* - A custom abort handler
*      A user-defined function. See the System module documentation for
*      details.
*/
System.abortFxn = System.abortStd;
//System.abortFxn = System.abortSpin;
//System.abortFxn = "&myAbortSystem";

/*
* The Exit handler is called when the system exits normally.
*
* Pick one:
* - System.exitStd (default)
*      Call the ANSI C Standard 'exit()' to terminate the application.
* - System.exitSpin
*      A lightweight exit function that loops indefinitely in a while(1) trap
*      function.
* - A custom exit function
*      A user-defined function. See the System module documentation for
*      details.
*/
System.exitFxn = System.exitStd;
//System.exitFxn = System.exitSpin;
//System.exitFxn = "&myExitSystem";

/*
* Minimize exit handler array in the System module. The System module includes
* an array of functions that are registered with System_atexit() which is
* called by System_exit(). The default value is 8.
*/
System.maxAtexitHandlers = 2;

/*
* The System.SupportProxy defines a low-level implementation of System
* functions such as System_printf(), System_flush(), etc.
*
* Pick one pair:
* - SysMin
*      This module maintains an internal configurable circular buffer that
*      stores the output until System_flush() is called.
*      The size of the circular buffer is set via SysMin.bufSize.
* - SysCallback
*      SysCallback allows for user-defined implementations for System APIs.
*      The SysCallback support proxy has a smaller code footprint and can be
*      used to supply custom System_printf services.
*      The default SysCallback functions point to stub functions. See the
*      SysCallback module's documentation.
*/
var SysMin = xdc.useModule('xdc.runtime.SysMin');
SysMin.bufSize = 128;
System.SupportProxy = SysMin;
//var SysCallback = xdc.useModule('xdc.runtime.SysCallback');
//System.SupportProxy = SysCallback;
//SysCallback.abortFxn = "&myUserAbort";
//SysCallback.exitFxn = "&myUserExit";
//SysCallback.flushFxn = "&myUserFlush";
//SysCallback.putchFxn = "&myUserPutch";
//SysCallback.readyFxn = "&myUserReady";

/* ================ Task configuration ================ */
var Task = xdc.useModule('ti.sysbios.knl.Task');
/*
* Check task stacks for overflow conditions.
*
* Pick one:
* - true (default)
*      Enables runtime checks for task stack overflow conditions during
*      context switching ("from" and "to")
* - false
*      Disables runtime checks for task stack overflow conditions.
*/
Task.checkStackFlag = true;
//Task.checkStackFlag = false;

/*
* Set the default task stack size when creating tasks.
*
* The default is dependent on the device being used. Reducing the default stack
* size yields greater memory savings.
*/
Task.defaultStackSize = 512;

/*
* Enables the idle task.
*
* Pick one:
* - true (default)
*      Creates a task with priority of 0 which calls idle hook functions. This
*      option must be set to true to gain power savings provided by the Power
*      module.
* - false
*      No idle task is created. This option consumes less memory as no
*      additional default task stack is needed.
*      To gain power savings by the Power module without having the idle task,
*      add Idle.run as the Task.allBlockedFunc.
*/
Task.enableIdleTask = true;
//Task.enableIdleTask = false;
//Task.allBlockedFunc = Idle.run;

/*
* If Task.enableIdleTask is set to true, this option sets the idle task's
* stack size.
*
* Reducing the idle stack size yields greater memory savings.
*/
Task.idleTaskStackSize = 512;

/*
* Reduce the number of task priorities.
* The default is 16.
* Decreasing the number of task priorities yield memory savings.
*/
Task.numPriorities = 16;

/* ================ Text configuration ================ */
var Text = xdc.useModule('xdc.runtime.Text');
/*
* These strings are placed in the .const section. Setting this parameter to
* false will save space in the .const section. Error, Assert and Log messages
* will print raw ids and args instead of a formatted message.
*
* Pick one:
* - true (default)
* This option loads test string into the .const for easier debugging.
* - false
* This option reduces the .const footprint.
*/
Text.isLoaded = true;
//Text.isLoaded = false;

/* ================ Types configuration ================ */
var Types = xdc.useModule('xdc.runtime.Types');
/*
* This module defines basic constants and types used throughout the
* xdc.runtime package.
*/

/* ================ TI-RTOS middleware configuration ================ */
var mwConfig = xdc.useModule('ti.mw.Config');
/*
* Include TI-RTOS middleware libraries
*/

/* ================ TI-RTOS drivers' configuration ================ */
var driversConfig = xdc.useModule('ti.drivers.Config');
/*
* Include TI-RTOS drivers
*
* Pick one:
* - driversConfig.LibType_NonInstrumented (default)
*      Use TI-RTOS drivers library optimized for footprint and performance
*      without asserts or logs.
* - driversConfig.LibType_Instrumented
*      Use TI-RTOS drivers library for debugging with asserts and logs enabled.
*/
driversConfig.libType = driversConfig.LibType_NonInstrumented;
//driversConfig.libType = driversConfig.LibType_Instrumented;

/* ================ Application Specific Instances ================ */
/* ================ NDK configuration ================ */
var Ndk       = xdc.loadPackage('ti.ndk.config');
var Global    = xdc.useModule('ti.ndk.config.Global');
var Ip        = xdc.useModule('ti.ndk.config.Ip');
var Udp       = xdc.useModule('ti.ndk.config.Udp');
var Tcp       = xdc.useModule('ti.ndk.config.Tcp');

Global.IPv6 = false;
Global.stackLibType = Global.MIN;
Global.networkOpenHook = "&netOpenHook";

/* automatically call fdOpen/CloseSession for our sockets Task */
Global.autoOpenCloseFD = true;

Global.pktNumFrameBufs = 10;
Global.memRawPageCount = 6;
Global.ndkThreadStackSize = 1536;
Global.lowTaskStackSize = 1024;
Global.normTaskStackSize = 1024;
Global.highTaskStackSize = 1024;
Tcp.transmitBufSize = 1024;
Tcp.receiveBufSize = 1024;

Ip.autoIp = false;
Ip.address = "192.168.1.12";
Ip.mask = "255.255.255.0";
Ip.domainName = "stryker.com";
Ip.socketMaxConnections = 4;
Ip.socketTimeToLive = 64;

e2e.ti.com/.../606722

Thank you for your support

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Is this the .cfg file directly from the TcpEcho example? Did you modify the cfg file?

In additional to the suggestions in my last post, can you also try running some non Ethernet related TI-RTOS examples? The reason I'm asking is because you said with most of the lines commented out and only the BIOS_start() remain, you are getting hard fault in the TcpEcho example. What about non Ethernet examples?

Also what about UDPEcho example?

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

More information on the issue below, Basically using ROV to get the Sp, lr and PC to get back to the point of failure, it takes me to the HWi assembly module that handles stack initialization ( Hwi_asm_switch.sv7M )

I just cannot get out of this!

I have read the comments in the file which suggest that the CPU needs to reset before running. I perform the reset and have the same result.

Indeed I have everything else commented out and only BIOS_start() is called.

I will try udp_echo next

Thank you for your support,

0 Carlos Alva over 6 years ago in reply to Carlos Alva

Prodigy 170 points

Hello Charles,

udpEcho does the same thing.

0 Carlos Alva over 6 years ago in reply to Carlos Alva

Prodigy 170 points

The code:

/*
* ======== main ========
*/
int main(void)
{
    /* Call board init functions */
    //Board_initGeneral();
    //Board_initGPIO();
    //Board_initEMAC();

/* Turn on user LED */
//GPIO_write(Board_LED0, Board_LED_ON);

    //System_printf("Starting the UDP Echo example\nSystem provider is set to "
    //              "SysMin. Halt the target to view any SysMin contents in"
    //              " ROV.\n");
    /* SysMin will only print to the console when you call flush or exit */
    //System_flush();

/* Start BIOS */
BIOS_start();

return (0);
}

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

I assume this udpEcho example will just run fine in your LaunchPad. Is that correct? If this is the case, I really don't have a clue what is causing the problem. Did you have a chance to run the non TI-RTOS Ethernet example? You can pick the enet_io example from the TivaWare library.

I have a few more questions and suggestions.

1. As I just asked above, does the TI-RTOS udpEcho example run fine on your launchPad?

2. As I just asked above, did you run the enet_io example? What is the result?

3. You have the custom board. This mean the device that was shipped to you is fresh without the MAC address. Did you program your own MAC address that was assigned to your company?

4. How many custom boards do you have? Can you repeat the same problem in all your custom boards?

5. What TIRTOS version are you using?

6. In your subject heading, you specify the part number as TM4C1294NCPDT. Can you please confirm the part number again?

7. This suggestion may be more time consuming but I'm still going to suggest to you. Can you do a ABBA test? This is to swap the MCU on your lauchPad to your customer board and also to swap the MCU on your custom board to the LaunchPad. What will be the results?

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

Thank you for your reply. Below are my answers:

1. As I just asked above, does the TI-RTOS udpEcho example run fine on your launchPad?

A: Correct. I tested the application in the lauchpad before attempting to run the same in my board

2. As I just asked above, did you run the enet_io example? What is the result?

A: Not yet, it is next. I need a fix IP address (figuring out how to disable DHCP and set my IP)

3. You have the custom board. This mean the device that was shipped to you is fresh without the MAC address. Did you program your own MAC address that was assigned to your company?

A: Correct, however I am programming my company's MAC in EK_TM4C1294XL.c line 221

/*
* EMAC configuration structure
* Set user/company specific MAC octates. The following sets the address
* to ff-ff-ff-ff-ff-ff. Users need to change this to make the label on
* their boards.
*/
unsigned char macAddress[6] = {my company MAC here};

4. How many custom boards do you have? Can you repeat the same problem in all your custom boards?

A; we have few, tried on 3 same result

5. What TIRTOS version are you using?

A: tirtos_tivac_2_16_00_08

6. In your subject heading, you specify the part number as TM4C1294NCPDT. Can you please confirm the part number again?

A: Yes TM4C1294NCPDT (same as the EK-TM4C1294XL board)

A:Test my understanding: The suggestion is to remove the CPU from my board and the one from the launchpad and solder them back-on on the other board? I am afraid that would be destructive for both and may lose my development HW.

Could you share how to program the MAC on the device? ( a long shot but worth trying )

Thank you for your time,

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Thank you for answering my questions.

Carlos Alva said:
A:Test my understanding: The suggestion is to remove the CPU from my board and the one from the launchpad and solder them back-on on the other board? I am afraid that would be destructive for both and may lose my development HW.

Honestly, I think this is the best way to diagnose what happen to your problem. If the MCU from the launchPad is swapped to your custom board and if it works then it confirms that your custom board is good. If it doesn't then it is a board problem to investigate. If you swap the MCU from your custom board to the launchPad and if it works, then we can confirm your MCU is good. If it does work, then then we need to investigate the MCU.

I think this step is really worth your trying as I don't have any clues now as to why an identical program works on the launchPad but not your custom board. I can understand if there is a board problem then the Ethernet may not work. But your problem is a hard fault, that doesn't look like an Ethernet problem. At least I haven't been able to connect the dots between hard fault and Ethernet. Perhaps I need to ask you one more time. Did you run any non Ethernet TI-RTOS examples. There are many TI-RTOS examples which are non Ethernet related. Can you repeat the same problem. If these examples are working fine, at least we can narrow down only to the Ethernet examples. Please also confirm if the enet_io works or now. If the enet_io does not work on your custom board then we will know it is only Ethernet related.

Carlos Alva said:
Could you share how to program the MAC on the device? ( a long shot but worth trying

What debug probe do you have? I believe you have the Jlink, correct? You can use the Uniflash to program the MAC address in the User0/User1 register. It will be permanently stored in the non-volatile memory.

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

For your last question regarding running another application that is not Ethernet related, the answer is yes (it is in one of my earlier posts) I was able to run Blinky without any issues in my board. I was able to modify the PIO configurations to actuate other outputs without issues.

I have also been able to run uart_Echo without issues.

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Thanks. From all the information I have from you so far is that the problem is Ethernet related. It could be a software issue or a hardware issue. But I just don't know which one is the root cause. I'm still waiting the result from:

1. enet_io example test.

2. ABBA test.

3. Program the MAC address to USER0/USER1 register using the Uniflash and see if it makes a difference. I know you already configured the MAC address in the EK_TM4C1294XL.c file. I also try it myself with an empty MAC address in the USER0/USER1 registers but program the MAC address in the EK_TM4C1294XL.c file and it also works for me on the launchPad. I will suggest for the time being, program the TI MAC address to your custom board. Your company's assigned MAC address should be fine. Is it possible that there are multiple same MAC address boards hooked up to your LAN. Unlikely scenarios but just wanted to make sure.

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Thank you for your reply,

I am keeping the board isolated from our network (against policy to attach a non approved device to the network)

At the moment I am working with a fixed IP (which in the case of tcpEcho I program in the *.cfg file, tested in the lauchpad)

Given that the issue is the HWi initialization as a result of BIOS_start, it suggests that the stack is not initialized or that somehow the PC or SP are changing and sending execution to an uninitialized area. The ASM code does a push and pop, the comments in the code suggest a CPU reset required to start and unwind interrupts. I perform the reset before attempting to run (same result)

I am starting to suspect the J-Tag interface (Segger J-Link) perhaps memory addressing and or register read/write may have an issue (only theorizing at the moment)

Thank you for your time

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Were you saying that the pop instruction was popping to an un-initialized area? Can you compare the lauchPad and custom board while you are tracing the code?

I still like to know the result of enet_io. It shouldn't take you much time to run the as-is example.

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles,

I have since been able to run. It may be a workaround of sorts but I am able to run code. For some reason, I need to reset and restart the processor after loading even if I get the exception (11) and the abnormal termination and register dump. The board runs with no issues on subsequent power ups.

I'll take this and continue development.

Thank you for your support.

Incidentally, I have downloaded the flash programmer to program the MAC address on urs0 and usr1 locations, could you provide detailed steps please (address process etc) thank you so much

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

Glad you are able to move on with your development.

In my reply on Thu, Feb 6 2020 9:24 AM, I have shown how to program the MAC addresses using Uniflash programmer. Please refer to that post. If you have new questions such as programming the USR0/USR1 registers please open a new thread instead of continuing on this thread. Thanks.

0 Carlos Alva over 6 years ago in reply to Charles Tsai

Prodigy 170 points

Hello Charles

Thank you for your reply. I did see your reply and downloaded Uniflash and follow the steps however no item appears on the uniflash screen (picture attached)

0 Charles Tsai over 6 years ago in reply to Carlos Alva

TI__Guru**** 191886 points

Hi Carlos,

I just tried it and noticed the same. I don't support the Uniflash tool. Can you please open a new thread to the CCS forum. I don't want to forward this thread to the CCS team as this thread has too many back and forth posts on not related to the Uniflash and it is too long for the CCS team to go through. So please open a new thread to the CCS forum and they will assist you.

Code Composer Studio™︎

Code Composer Studio forum

CCS/TM4C1294NCPDT: Build and load results in abnormal termination and register dump