I'm working with Microchip's free TCP/IP (version 4.55) stack on an 8-bit micro-controller.
I'm trying to reset the stack without doing a full board reset with asm("RESET").
Any ideas on how to restart this Stack.
UPDATE
I reset the stack with the following steps
Toggle the reset pin to on the Microchip Ethernet chip
Call StackInit();
Manually reset the UDP announce state machine
This seems to recover from the fatal SPI errors I encountered.
Call StackInit(). That function reinitializes all the sub-modules (TCP, UDP, SMTP, etc.). It will also clobber all of the TCP and UDP socket you have open, so you will have to re-open the sockets you want to use.
As a side note: I followed the thread on the Microchip forum. I was also getting strange resets in my TCP stack. It ended up being a stack overflow. Put some variables at the top of your stack.
#pragma udata stackoverflow = 0xE00
UInt32 StackUpperBound[8];
#pragma udata
Initialize these variables at the beginning of main() and put a breakpoint at the beginning. See if these variables are being overwritten.
I am totally not familiar with the Microchip stack, but unless the stack is designed to be restarted, I doubt you will be successful.
If all the buffers and structures are statically allocated, then in theory, you could call the initialization routines to "restart" the stack (assuming it does a re-initialization of the structures).
If it uses dynamic buffers (malloc), then I believe you would be out of luck.
Related
Thanks to everyone who gives an answer. But the problem is related to the compiler. I used Cosmos and STVD, it does not bind the interrupt function. When I immigrate the project to IAR, The problem is solved.
I am dealing with STM8S103F3P6 IC. I try to send a message using TX interrupt but I have never succeeded.
I have checked the example of the UART interrupt. Also, I tried to develop the same code. However, I got still zero. I took the interrupt vector function from STM8 examples. Where is my mistake? How can I figure out?
Here my init, main, and interrupt vector function;
void init_handler(void){
CLK_HSIPrescalerConfig(CLK_PRESCALER_HSIDIV1);
UART1_DeInit();
UART1_Init((uint32_t)9600, UART1_WORDLENGTH_8D, UART1_STOPBITS_1, UART1_PARITY_NO, UART1_SYNCMODE_CLOCK_DISABLE, UART1_MODE_TXRX_ENABLE);
UART1_ITConfig(UART1_IT_TXE,ENABLE);
enableInterrupts();
UART1_Cmd(ENABLE);
}
main(){
init_handler();
while(1);
}
INTERRUPT_HANDLER(UART1_TX_IRQHandler, 17){
/* In order to detect unexpected events during development,
it is recommended to set a breakpoint on the following instruction.
*/
UART1_SendData8('a');
while (UART1_GetFlagStatus(UART1_FLAG_TXE) == RESET);
}
It sends nothing. I do not have any logic analyzer, I have only checked using terminal applications.
You asked where your mistake is: that's hard to tell if you use library functions that mask the usage of peripheral configuration registers and flags by making them "readable". If you don't have a logic analyzer, pin debugging helps most of the time (e.g. toggle a GPIO when entering the ISR).
My advise is to look at the actual register manipulations and to compare those with the descriptions in the STM8S Reference Manual (even if it doesn't provide concise guidance on how to initialize, start, spin down and end a transmission).
In order to make that a little easier, I'd like to share what I learned about using a UART ISR:
Sending the contents of a buffer with UART TXE and TC interrupt events turns out not to work like in e.g. MCS51: most of it has to be done with the interrupt enable flags TIEN and TCIEN in UART_CR2.
This is what worked for me:
both TIEN and TCIEN should be normally disabled
after setting up buffers and pointers, enable TIEN to start a transmission
in the ISR, during the transmission, writing to UART_DR clears the interrupt event
in the ISR, when the buffer is empty, disable TIEN and enable TCIEN to spin down the ISR chain
in the ISR, read UART_SR to check if TC is set. If that's the case, clear TCIEN
The advantage of this procedure is that media access control, e.g. for RS485, can be done in the last step of the chain.
An example in STM8 eForth is here.
SPL and opinions about that have nothing to do with the problem. As the SPL code is open sourced you can have a look and even copy it.
UART1_IT_TXE occurs after the UART has transmitted something.
Since you don't send anything (yet) the IRQ is not triggered.
You can send a series of characters using the UART1_IT_TXE IRQ by sending the first character using the UART1_SendData and then let the IRQ handle the remaining ones.
How can I be aware of register spilling by looking at an objdump file?
My thought is that it can be done by tracking the stack pointer: moving sp beyond function prologue and epilogue, indicates register spilling.
I want to know which lines of codes are doing register spilling. Also, where are the registers restored pointed to global variable, also stack?
Register spilling doesn't require moving the stack pointer, a local variable may be spilled to the stack and constantly used directly from there while still in the current frame, and the compiler would just use the stack frame with its offset instead of a register.
Your best bet is just looking for memory addresses being read and/or written to constantly. This may even happen where there are available registers around because of compiler deficiencies, or inability to prove that no other thread/code unit are accessing some local variable by addr (for example if the variable address is copied somewhere out of scope). In such cases maintaining that variable in memory is necessary.
I am trying to write an FIQ handler for arm64(AArch64) in assembly. I already have written an IRQ handler which works well so far. I was just wondering if my FIQ handler should be different from what my IRQ looks like.
My FIQ handler does the following:
Push Registers onto stack
Read GIC Interrupt Ack Register to identify the interrupt no.
Check if it is not spurious interrupt. If it is spurious branch to end of irq handler.
branch to corresponding high level C ISR for interrupt servicing.
write GIC EOIR to mark the completion of interrupt
pop registers from stack.
return to the main code.
In AArh32 FIQ used to have banked registers R8-R12,LR,SP; which were not required to push onto stack. So this was one difference from IRQ in AArch32 where all registers(except LR,SP) were required to push onto stack.
But I couldn't find what registers are banked in arm64 (except LR & SP).
Could someone please tell me what should go into my FIQ for arm64. Better if someone could direct me towards an example FIQ handler for arm64.
Theoretically, you only need to save those registers clobbered in your interrupt handler. But from the perspective of generality, you should save all the general purpose registers (X0 to X30).
LR (Link Register) is the alias of X30 in arm64. You don't need to save SP, but you must make sure SP is unchanged while returning from FIQ handler, especially when you are programming the FIQ handler in assembly language. C compiler will take care of the stack pointer so you don't worry about that in C ISR.
So I am reading from MicroC/OS-II book, but in the section for task stacks I couldn't find exactly what the stack is and most importantly - what is it used for. I know it is not something long and difficult, but I kinda' have to understand it. The book only says how to set the stack size and some other things like this.
So, can somebody explain me in short and simple words what is the task stack and what is it used for, in uC/OS-II ?
In general in the context of a procedural programming language, the stack is where a function/procedure/sub-routine's local variables and return address are stored (in a "stack frame") - the greater the call depth, the more stack frames are stored - one for each function that has not yet returned. That part is true regardless of whether you are using an RTOS such as MicroC/OS-II or not.
In a single threaded environment, only one stack is required, and this is normally provided for you as part of the C runtime environment set-up for example. In a multi-threaded environment, you need a stack for each separate thread of execution, and it is typically up to you to allocate stack space for each thread, or at least to specify its length.
I don't know MicroC/OS-II, but the stack of a task is nearly always the same:
During the execution of a task, it stores data that are required in the current context. This means when a subroutine (method, etc.) is called, a "stack frame" is stored on top of the stack. This stack frame stores local variables of the called subroutine, the return address used when the subroutine is finished, and some other info. When the subroutine returns, the stack frame is deleted. If the subroutine calls another one (or itself recursively), another stack frame is stored on top of the current one.
In contrast to a stack where stored data are deleted in reverse order as the have been stored, a heap stores data a long as their memory is not freed, which can be done in an arbitrary order.
Many processors have a stack pointer, and most of those have instructions that specifically use that stack pointer. The stack pointer is a register that holds an address, not unlike the program counter. The stack is simply memory pointed to by the stack pointer, at a higher level you or the operating system or someone divides the available memory space up for different uses, a little for data a little for program a little for heap (mallocs and frees) and some for the stack. The stack pointer and associated instructions allow code to temporarily allocate some memory. A global variable for example is at least for the life of your program stuck at one memory location. A local variable though only needs a memory location while the function is being executed, when the function returns you dont need that local variable memory (statically defined locals are allocated like globals but only available during that function, so not temporary). You could do a malloc and free in the function to allocate this local memory, or you could simply use the stack. And many/most compilers simply use the stack. In addition to local variables you might need to store the return address, if function a() calls function b() to get from b back to where you were in a you need to return to the next instruction after the call to b(). if B calls c then within the context of b() you need to save the return to a() and now within c() you need to know how to return to b(). And so on. This is architecture and calling convention dependent, some architectures always use the stack for returns, some lean toward using a specific register. When nesting calls though all architectures are going to need to eventually use the stack for the return address, so the stack is used here as well. If function a() calls itself 10 times and has one local integer and the return address lets say it needs 8 bytes of stack per call, so first call moves the stack pointer 8 bytes allocating 8 bytes, the second call another 8 and so on. when you start to hit returns, the the stack pointer moves back 8 bytes, another return another 8 bytes back on the stack pointer.
Now translate that from a single application to multiple applications with the illusion if executing simultaneously (an operating system) for each application/task/procedure/thread/whatever you probably want each of them to have their own stack. This is often quite easy as you just need to save the stack pointer from the prior task and set the stack pointer to the last value from the next task when it was switched out. You can of course get much more complicated and have protection mechanisms so each application can only live within its memory space including stack and heap. and mmus can make it even more complicated by having physical memory chopped up into many pieces and the mmu makes it look like separate pieces are linear within the applications virtual address space. etc.
as nurd_droid pointed out some processors have different stack pointers depending on the mode of the processor. you might have one for user/application mode, then when a system call happens a system/superuser stack pointer, and an interrupt happens an interrupt stack pointer. Some architectures simply have one stack pointer...Some architectures the stack is not in the main memory space the stack and stack pointer are buried in the logic and you dont really see it (often in this case the stack size is quite limited and can roll around on itself or other bad things if you dont manage your stack usage).
Stack is a data structure of type last in first out (LIFO) which is used by procedural languages to do push/pop local variable, CPU registers, return addresses before making a function call or when an interrupt occurs or for preparation of context switches.
Variables, registers are popped out in exactly reverse order when compared to order they are pushed on stack.
Stack can grow upwards or downwards in memory. This is something that will depend upon the micro-controller.
Also, many micro-controllers have multiple stacks.
1) User stack
2) Exception stack or Interrupt stack
If RTOS is used then each process/thread/task will have its own stack. In this case user SP micro-controller register will be reassigned by context switch routine to point to stack for currently active process/thread/task.
Exception stack or Interrupt stack is shared across the system.
I'm doing some development in C with a STM32F107 chip and, at some point, the device began to reset when I call a specific function. I don't have a debugger and my debugging is just plain text over a serial port.
I've used some other microcontrollers in which I was able to access a register to see the cause of the reset, but I can't seem to find an equivalent for this device. I'm aware of the hardware exceptions of the Cortex-M3, but I don't know if one of them is being triggered since I can't seem to send text over usart when I'm inside those handlers (maybe because my TX functions use interruptions?).
So, I decided to ask people with more experience than I in this device: what is usually done to debug situations like these?
EDIT
One of the developers activated the WWDG watchdog and it was reseting the hardware before I could get my info from the fault handlers. It was a Hard Fault due to calling a function by a pointer that was pointing to the wrong place. However, I will keep this question in the hope that someone will give more details (or material about it) for pointing back to C code from the registers saved in, lets say, a Hard Fault (#dwelch idea).
The Cortex M3 has excellent fault handling features that will make your life easier. On hitting a fault, it automatically stacks several registers like PC and LR, and fault status registers will tell you things like address of bus fault, etc.
You should implement a good fault handler (for example, the hard fault handler here: http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/) to print out the stacked registers and debug fault status registers.
You should use the UART for printing, just write your own simple custom version of printf for use from your fault handler that doesn't depend on interrupts. Just write bytes directly to uart Tx data register and poll for byte completion.
Aside from what has been mentioned about the interrupt handlers for debugging, some ST micros also have a reset source register that you can read on power-up (that is after a reset). For the cortex M family (m0/m3/m4) the register is RCC_CSR. http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
Unfortunately you wouldn't be able to know whether the specifics, such as hard fault but it would tell you if the watchdog (window or independent) had tripped.
Given that you don't have a debugger, I would suggest that you find some peripheral on the microcontroller to help you. Perhaps you have an LED you can toggle or a simple GPIO pin that isn't being used that you can hook up to an oscilloscope. If you toggle a GPIO pin slowly enough (no faster than 1 Hz and maybe more slowly depending on the meter) you can use a volt meter instead of a scope. Put the code to toggle the LED or GPIO pin in each of the exception handlers one at a time until you track it down. If you have more than one GPIO pin available you can speed up the process. You can also write a wrapper for the specific function that is causing the reset. The wrapper function would send a list of interrupts that are enabled just before the breaking function is executed. This way you don't have to waste time testing the ones that are not enabled.
One advantage of GPIO pins in this case is they don't require an interrupt. It is best to stay away from anything that requires an interrupt (like your USART in this case). If the reset is being caused by a higher priority exception your debugging code will never execute.
It is also common that the reset is caused by an uninitialized pointer. A function pointer set to zero would cause execution to look a lot like a reset. If this is the case, the USART initialization code is probably being executed before a byte can be fully transmitted by the USART which would render the USART useless as a debugging tool in this instance.
When you say reset I think in terms of you hit the reset vector, not one of the interrupts or handlers. Are you saying that it does indeed reset the chip and start your software over again or are you saying that it is hanging somewhere? or do you have the vector table all point at the reset vector?
How to proceed depends on what you are really seeing, you need to be more clear or specific, or maybe you want help figuring that out.
Normally I map the unused vectors to a simple hang line of code which branches to itself. Later I may remap some of them to real code.
the cortex-m is very nice in that you can point at C code. If you think you are getting an exception have it point at a routine that grabs something that helps you figure out what mode you are in, the link register might have that info, or a csr somewhere, print that out and go into an infinite loop. Fill up the unused portions of the vector table with the address to this generic debug function.
From there you need to figure out why you are hitting that exception, it could be something like an unaligned access for example. It could be that you have generated an interrupt when trying to initalize a device before completely setting up the handler, who knows.
edit your question with more answers or information as you work through this.
You can use below code for debugging.
void HardFault_Handler(void)
{
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
/* Go to infinite loop when Hard Fault exception occurs */
while (1)
{
}
}
Also add this as well.
void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used. If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; /* Link register. */
volatile uint32_t pc; /* Program counter. */
volatile uint32_t psr;/* Program status register. */
r0 = pulFaultStackAddress[ 0 ];
r1 = pulFaultStackAddress[ 1 ];
r2 = pulFaultStackAddress[ 2 ];
r3 = pulFaultStackAddress[ 3 ];
r12 = pulFaultStackAddress[ 4 ];
lr = pulFaultStackAddress[ 5 ];
pc = pulFaultStackAddress[ 6 ];
psr = pulFaultStackAddress[ 7 ];
/* When the following line is hit, the variables contain the register values. */
for( ;; );
}
I am using this to get any value of the register before going into hardfault. You can also add more registers if you like.
The "right" thing to do, is, unfortunately not practical with an STM32. That would be to put in a big exception handler that has knowledge of the source code, and can unwind the stack and give you the full call stack and line number that cause the fault. This would require adding all the debug information from your application into the flash memory of the STM32, and that's not practical.
There are ways of tricking your IDE to sometimes give you the call stack. I'd give details but I forgot to write them down, so I've forgotten. I think it has to manually changing the stack pointer from one shadow register to another.
What I usually do is to put a breakpoint at the hard fault exception vector, and then look at all the registers when the break point hits. Consider them forensic evidence from a murder, done with plastic explosives. The values of the registers will give you ideas. Register values that start with 0x20000000 are RAM addresses. Register values that start with 0x08000000 are Flash addresses. Open up the disassembler and type in those addresses. It will probably go straight to the variable or function at those memory locations. If that doesn't help, then look at the stack pointer. Look at the memory locations at the stack pointer, and do the same trick. I have always found enough shrapnel to location the function where the exception was happening.