We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all, I am using STR912FAW44 core. I am trying to get an external interrupt from GPIO6.2 pin. There is a problem with my configuration, but I do not know where I am wrong. Could you tell me where I am wrong. My external initialization function as follows.
void externalInt_init(void) { GPIO_InitTypeDef GPIO_InitStructure; WIU_InitTypeDef WIU_InitStructure; SCU_AHBPeriphClockConfig(__VIC,ENABLE); VIC_DeInit(); SCU_APBPeriphClockConfig(__WIU, ENABLE); WIU_DeInit(); SCU_APBPeriphClockConfig(__GPIO6, ENABLE); GPIO_DeInit(GPIO6); /* GPIO6 pin configuration */ GPIO_DeInit(GPIO6); GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Direction = GPIO_PinInput; GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;//|GPIO_Pin_1|GPIO_Pin_0; //GPIO_InitStructure.GPIO_Type = GPIO_Type_PushPull;//GPIO_Type_OpenCollector ; GPIO_Init (GPIO6, &GPIO_InitStructure); // Enable the WIU & Clear the WIU line 18 pending bit WIU_Cmd(ENABLE ); WIU_ClearITPendingBit(WIU_Line18); //WIU_DeInit(); WIU_InitStructure.WIU_Line = WIU_Line18 ; WIU_InitStructure.WIU_TriggerEdge = /*WIU_RisingEdge;*/WIU_FallingEdge ; WIU_Init(&WIU_InitStructure); // Select WIU line 18 as VIC1.12 interrupt source SCU_WakeUpLineConfig(18); //Configure and enable the interrupt controller // VIC_DeInit(); //VIC_InitDefaultVectors(); // Configure the External interrupt group 2 priority VIC_Config(EXTIT2_ITLine, VIC_IRQ, 1); // Enable the External interrupt group 2 VIC_ITCmd(EXTIT2_ITLine, ENABLE); }
ISR as follows
void EXTIT2_IRQHandler(void) { WIU_ClearITPendingBit(WIU_Line18); printf("ext18\n"); }
Actually, since your code seems correct - I am quite sure that the above guesses represent your problem! Ho that was risky...Keep us apprised!
I controlled the SCU_PRR1 and SCU_PCGR1. the clock for GPIO6 is active and it is not held in reset. I noticed that previously I did not give enough details of the problem. When the external chip sends an interrupt, CPU goes into ISR, prints the "ext18", after that point it resets the whole system, or jumps an absurd address then it is hung on. Rougly my code as follows:
.... run() { COMMAND cmd; while(TRUE) { getCommandFromSerialPort(&cmd); switch(cmd.type) { case DO_CMD_A: sendCommandToExternalChip(cmd.data);/*it writes the data to the command register of the external chip. When the chip finishes the command it informs the cpu through the GPIO6.2 pin*/ break; ..... } } } int main() { setupSerialPort(); setupExternalChip(); externalInt_init(); run(); } ....
Always provide all relevant data! Now you forget to mention whether this happens all the time etc. How about your stack size for IRQ mode? Do you support nested interrupts? Did you check the value of LR just before leaving the ISR?
Does it still crash if you remove the "printf"?
Did you initialize the serial port...? if not, your "printf" will generate a data abort... You see - you do it again. HOW does your processor hang?!
I increased the stack sizes, but the problem goes on. However, I just increased the stack sizes, I did not change any thing . It is enough or not to increase stack sizes?
if not, your "printf" will generate a data abort...
Oops, not necessarily.
It is enough or not to increase stack sizes? what do you think? it depends - if stack sizes are indeed related to your problem! if you bother to answer some of the outstanding questions, maybe somebody would be able to help you...
Ok you are right. I really increased the stack sizes and I observed while debugging. So I can say that the cause of my problem is not enogh stack sizes.
If I go back your previous questions. Yes I initialized the serial port. And I removed the printf and tried, but again it crashed.
Thank you.
I'm confused. So the problem is solved or not? on the one hand you say that your stack size was insufficient, then you say that the program still crashes? what about LR...?
Hi Tamir Michael,
The problem is not solved, but I will give some debug time information:
main() { ... line_1 call f1: ... } f1() { .... line_2 call f2: .... } f2() { ... line_3 call f3: line_collapse: ... } f3() { .... line_before_exception line_at_exception(it jumps to the ISR routine) line_after_exception ... } isr_routine() { WIU_ClearITPendingBit(WIU_Line18); line_4_isr: }
When the PC is on line_1 SP: 0x04001280 (CPU mode is user mode) then it goes into f1 then at line_2 SP: 0x04001260 then it goes into f2 then at line_3 SP: 0x04001250 then it goes into f3 then at line_before_exception SP:0x04001240 then excepiton occurs and it goes into ISR routine then at line line_4_isr SP: 0x04001C80(CPU mode is IRQ mode) then it returns from ISR then PC is at line_after_exception, however the SP:0x04001C88 (I expect that it would be 0x04001240) and CPU mode still IRQ mode. In other words, when the exception occurred the SP is updated according to the IRQ stack, however when it goes from ISR, goes back to the function which exception occured(f3()) SP is not updated according to user stack. Moreower, the CPU mode still is in IRQ mode.
The strange things occurred when the CPU returns from f3 because it tryies to pop LR(next PC value which would be line_collapse) from IRQ stach aldough it saved before in user stack.
I am waiting your advices to solve this problem. It seems that I am asking some mandatory questions, but I am new in embedded programming and microcontroller world, so I hope that you will forgive me. Thank you, Tamir
Please post your entire ISR using the proper flags (pre...).
wait.
isr_routine() { WIU_ClearITPendingBit(WIU_Line18); line_4_isr: }
I would expect to see
__irq void isr_routine(void)
?
Hi Tamir,
You are genious. From now on, you are my hero. Thank you very much. I solved the problem. When you said me "I would expect to see __irq void isr_routine(void)", I added and '__irq' key word before my ISR routine like "__irq void myisr()". Then the problem is over. Again thank you very much.
Best regards
You're welcome.