TM4C1290NCPDT: DHCP timer fault with branch to FaultISR

Hi,

  I have not seen a problem like this. While I do not know the root cause of your problem, I will suggest you try increasing the stack and heap size. Perhaps for experiment, first double the stack/heap size and see if the problem goes away. If the problem goes away then it is related to memory management. You can then adjust the stack and heap accordingly for your application. Can you also repeat the same issue with different compiler optimization levels? Just wanted to know if it has anything to do with the compiler optimization level. 

  This app note is also useful for diagnosing faults. https://www.ti.com/lit/pdf/spma043

Thanks

the stack size was the first thing to check - it is 8K in size. I can see it as it changes it needs much less - so that isnt the problem.

The optimization is off - I am not using it.

My puzzle is where does the branch FaultISR line come from.

Maccabi

Hi Maccabi,

  Can you show your source code for the dhcp_fine_tmr function and its calling function? I'm also not understanding where the bl FaultISR is coming from. Please also show the map file. and provide the version of the compiler you use. I think these information will be helpful to our codegen team as I'm going to move your post to our experts for comments. 

the dhcp_fine_tmr() code:

the code calling it is:

I presume you build with the TI Arm proprietary compiler, which has the executable name armcl.

Please disassemble the final executable file created by the linker.  A disassembler is located in the same \bin directory as the compiler.  The command is similar to ...

armdis final_executable.out > disassembly.txt

Inspect the disassembly at the address of the problem branch 0x0000cf24.  What does that show?

Thanks and regards,

-George

Hi

As I made changes in code (not todo with this issue) the line numbers changed.

Under debugger in c we get the right part and the disassembly on the left:

from the armdis output I got:

taking into account the code is the same in all boards and the board that gets to the exception has had many of those timer interrupts in a good way until it got thrown to the exception has me suprized to see this "bl FaultISR" command.

Maccabi

I don't see where the compiler has made any error.  Whatever causes that instruction to branch to FaultISR must occur after the code is built and loaded.  Do you agree?

Thanks and regards,

-George

Maccabi Luz said:

My puzzle is where does the branch FaultISR line come from.

The app note https://www.ti.com/lit/pdf/spma043 which Charles's linked above contains:

Are you able to try following the diagnostic steps in the above app note?

Also, in CCS/TM4C1294KCPDT: How do I get the stack unwound in exception handlers? there is some information about how to get the CCS debugger to unwind the stack to find the instruction which caused FaultISR to be called.

I found the exact place of where the exception happened using that document.

I don’t know why it happens it is code part of the TCP stack.

It happens here

#if LWIP_DHCP
if((g_ui32LocalTimer - g_ui32DHCPFineTimer) >= DHCP_FINE_TIMER_MSECS)
{
g_ui32DHCPFineTimer = g_ui32LocalTimer;
dhcp_fine_tmr(); <===============
}
#endif

As shown in the previous email.

I am using a permanent IP but need the dhcp at the beginning.

Maybe if I give a very high value to DHCP_FINE_TIMER_MSECS  and LINK_TMR_INTERVALthat do the IP checking, the once a week or two, problem will not happen.

TIA

maccabi

I totally agree.

As I wrote I do not understand the code I saw in the debugger disassembly containing the command – bl  FaultISR seen in the picture bellow and the code we have in the c file.

I still dont understand where the command in the disassembly of "bl FaultISR" came from.

time Hi,

  Did you have a chance to try the GEL script to unwind the stack to find the instruction which caused FaultISR to be called in this post CCS/TM4C1294KCPDT: How do I get the stack unwound in exception handlers provided by Chester?

  Earlier I wondered if it will resolve the issue if you increase both the stack and heap sizes (try to double both of them for experiment), can you confirm that you already tried both and the result is the same?

  Per my understanding for lwIP, it is probably not straight forward if not impossible to support both DHCP and static IP at the same time from one NIC. For DHCP, you would need to have #define LWIP_DHCP and LWIP_AUTOIP set to 1 in lwipopts.h. However, for static IP, normally you would need to set both macros to 0. To support both, I'm not sure what is the right way from lwIP stand point. I would suppose you still set both LWIP_DHCP and LWIP_AUTOIP set to 1 in lwipopts.h. Perhaps, you can ask lwIP forum for some guidance for best approach. With that said, I find this post that seems to work for the poster with some hack to the code.  

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1171439/tm4c1294ncpdt-dual-static-dhcp-configuration-clears-static-ip-data-on-ethernet-link-up-lwiplib-c-in-tivaware