TM4C129ENCPDT: Project was working, and now I keep jumping to abort when BIOS starts

Hi Noah,

Noah Madinger said:

This project is based off of the tcpEcho project, and all other tasks except for those related to this initial example have been commented out.

Are you saying that you have stripped off everything that only the initial example which is the tcpecho code remains?

Or you still have the UART RX and UART TX tasks running?

What is actually running?

If you download the tcpecho example again, I don't think you will see any abort issue right? 

Noah Madinger said:

I suspect that this is related to memory allocation, but I am not sure how to address this. Any help is appreciated. Thank you!

In ROV, can you look under task and find out if there is a stack overflow?

Can you use these two posts to debug the exception?

• How do I trace backward to the code that caused an exception in my TI-RTOS app?
• Debugging Common Application Issues with TI-RTOS

Charels,

Thank you for suggesting these posts, and I will review these. 

No, the project is not exactly like the tcpEcho function. Let me provide you with more details.

First, here is main:

int32_t main(void)
{
//static const uint8_t macArray[6] = {0xAC,0xDE,0x48,0x00,0x00,0x80};
/* Call board init functions */
Board_initGeneral();
Board_initGPIO();
Board_initEMAC();
Board_initUART();

/* Initialize Over-arching Task System */
//InitTaskSys();

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);
}

Both the EMAC and the UART peripherals are initialized. The commented-out function InitTaskSys creates the mailboxes for inter-task communications, constructs the UART_Tx and UART_Rx tasks, and constructs a system-management task call SysComm. So, with this function commented out, none of these tasks are constructed.

Now, in the .cfg file, mailboxes have been enabled through the XGCONF.

The tcp-related functionality is tied into the program through the tcpEchoHooks.c, but I have set a break point here, and the abort occurs before this function is called. 

In closing, I'll keep digging and will update this thread.

Thank you!

Charels,

Been digging into this issue using the ROV and the Hwi. Still having the issue. 

Removed mailboxes from the .cfg.

Here is a copy/paste of the Exception tab:

When I enter the PC, SP, and LR registers, it takes me to a place in the disassembly where the Hwi_HwiProxy_switchFromBootStack() function is called:

When I go to the Detailed tab, fxn is set to: ti_sysbios_family_arm_lm4Timer_isrStub_E.

On a side note, I loaded the empty project on to my Mikroe development board for Tiva and it loads and works, with PN.1 LED blinking. I was worried that my hardware may have been damaged, but this does not appear to be the case. 

For another data point, I reloaded the tcpEcho project. I made two modifications to the code in order for the software to work with the Mikroe development kit: I changed the Ethernet LEDs, and I implemented a default MAC address, since the MCU on the Mikroe development kit does not have the MAC address in flash.

This causes the same exception with the same PC location.

Interestingly, there is now another function listed in the Detailed tab: GPIO_hwintFxn. This listing was not present in my custom project.

Noah Madinger said:

or another data point, I reloaded the tcpEcho project. I made two modifications to the code in order for the software to work with the Mikroe development kit: I changed the Ethernet LEDs, and I implemented a default MAC address, since the MCU on the Mikroe development kit does not have the MAC address in flash.

This causes the same exception with the same PC location.

I don't know what is wrong. Can you do some experiments

 - I want to make sure when you reload the tcpEcho example, it is not the original example that you might have already modified somewhere in some settings but you forgot about it. Can you simply just download the tcpEcho example fresh again as a starting point and make your LED and MAC ID changes.

 - Run your modified code (tcpecho and change of Ethernet LED and MAC address) on a LaunchPad. Can you get it to exception?

 - Run the stock tcpecho example on the LaunchPad?

Charles,

I believe this is a hardware issue.

Here are the steps I took.

1) Erased the previous tcpEcho project from my workspace.

2) Using the Lauchpad development kit, I reloaded the tcpEcho project.

3) Interestingly, the build succeeded, but the debugging failed saying that it could not find a target configuration file.

4) Added a target configuration file, and set it to the Stellaris in-circuit debugger, and assigned the MCU to Tiva TM4C129ENCPDT.

5)  Modified the .cfg file to use a static Ip address.

6) Used the tcpSendReceive executable and this worked.

7) Using the same Lauchpad, the MIKROE-specific modifications were made: the LED pins were changed, and a software programmable MAC address was used.

8) This also worked! Although, the LEDs on the Lauchpad did not function, but this was expected.

9) I then used this same CCS project and configuration and loaded this on the MIKROE development kit.

10) This worked the first time, and tcpSendreceive functioned; however, this only worked the first time.

11) After several attempts, this continued to jump to the aboort function and in the ROV I saw the same errors that I had previously mentioned.

12) I replaced the MCU module on the MIKROE development board (there is a development board, and the MCU is on a daughter card).

13) The same thing happened: it worked the first time, and then never again.

Using an oscilloscope, I looked at the 3.3 V and 5V rails, but do not see any drooping or noise. 

Then, I loaded my custom project onto the Launchpad, and saw thsi message in the Console: NC_NetStart: WARNING: Boot thread has not completed!

Now, I've made a lot of modifications to cut various things out of this project.

Last of all, I reverted my code to a previous commit that had been working, modified the target configuration file to use the in-circuit debugger for the Lauchpad, and now things appear to be running stably on the Lauchpad.

I do not know what happened, but the issues seem to be localized ot the MIKROE development kit.

Noah Madinger said:

7) Using the same Lauchpad, the MIKROE-specific modifications were made: the LED pins were changed, and a software programmable MAC address was used.

8) This also worked! Although, the LEDs on the Lauchpad did not function, but this was expected.

This means your software is fine. 

Noah Madinger said:

I do not know what happened, but the issues seem to be localized ot the MIKROE development kit.

Not sure how much I can help here if the problem is on the MIKROE. Can you run your last commit on the MIKROE? Does it only work the first time and abort for the sequent times? I will suggest you start from your last commit and only add a small increment of code at a time when running on your MIKROE. Hopefully, you will be able to narrow down the offending code that might have caused the abort if you believe it's a software issue. If this is indeed a hardware issue, you might want to try another MIKROE board if you have one to see if you can replicate the problem. If more than one board has the same problem, then it is not likely a hardware issue in my opinion. Make sure you have good CAT5E cable. 

Hi Noah,

 I have not heard back from you. Do you have any update? If you have resolved the issue, can I close this ticket?