2009-11-23 08:24 AM
HiTop, debugging EXTI
2011-05-17 04:30 AM
Hello Guys,
I'm trying to get external interrupts working. Since I don't have any hardware yet, I debug my code using HiTop 5.31. The ISR isn't called and the pending bit for the interrupt, generated by software, isn't set. Even setting the pending bit in SFR doesn't call the ISR. The PC isn't changed to 0x0000_0058, which is the vector for EXTI0, when stepping through the code, too. When calling SystemInit hitop gets stuck waiting for the PLL. According to this I'm not using SystemInit, to be able to test my code. Does not calling SystemInit affect the AFIO clock and because of that the interrupt? I searched the Forum but didn't find anything similar. Also I checked my code using examples on the forum. The project is adapted for STM32f103ZE. I'm using the Std Lib. Code attached. I hope anyone can help me... Cheers }Quote:
/*********************** Interrupt Handler ********************************/ void EXTI0_IRQHandler(void) { GPIO_Write(GPIOD, 0x0001); //set Pin1 PortD } /*********************** Main ********************************/ int main (void) { uint16_t test = 0; //SystemInit(); //disabled cause HiTop stucks when waiting for the PLL GPIO_InitTypeDef GPIO_InitStructure; //create GPIO structure EXTI_InitTypeDef EXTI_InitStructure; //create EXTI structure NVIC_InitTypeDef NVIC_InitStructure; //create NVIC structure GPIO_DeInit(GPIOA); //Deinitialisation of PortA GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All; //select all pins of PortA GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPD; //set input mode pull down GPIO_Init(GPIOA, &GPIO_InitStructure); //Write Settings to PortA GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0); //use PortA for EXTILine0 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); //enable AFIO Clock EXTI_InitStructure.EXTI_Line = EXTI_Line0; //select EXTILine0 EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt; //select Interrupt-Mode EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising; //select Trigger on Rising Edge EXTI_InitStructure.EXTI_LineCmd = ENABLE; //enable Interrupt on EXTILine0 EXTI_Init(&EXTI_InitStructure); //write Settings to EXTILine0 NVIC_InitStructure.NVIC_IRQChannel = EXTI0_IRQn; //select EXTI0 IRQ NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1; //set priority NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; //set subpriority NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; //enable EXTI0 interrup channel NVIC_Init(&NVIC_InitStructure); //write settings to NVIC while (1) { test++; //increment test variable if(test==3) { EXTI_GenerateSWInterrupt(EXTI_Line0); //generate software interrupt on EXTI_Line0 } }2011-05-17 04:30 AM
>Since I don't have any hardware yet, I debug my code using HiTop 5.31
Assume you have the Hitop Simulator Version without using Tantino cable. Obviously the simulator only simulates the instruction set and cannot simulate physical behaviour of peripherals like PLL lock point or HW counters. Did you try to stimulate exti using System-TargetSystem-PortInput?2011-05-17 04:30 AM
First of all you are right, I'm using HiSim. I tried the SFR Window to set the port to trigger the interrupt (referring to the output window it does the same) but it didn't work.
Finally the STM3210 EVAL board and a hitex tantino arrived yesterday. The code doesn't work on the eval board, too. I have problems using reset_appl and reset_go_main. Only directly after flashing I can debug my code. Otherwise it gets stuck in the Default_Handler.2011-05-17 04:30 AM
the reset-go-main macro works well with my tantino. Make shure, you have the correct startup in use. The GCC low density version from CMSIS has severe bugs ...
If the ''default handler'' is a hard fault, you probably have the reset+1 or .thumb_func bug problem with your startup code. To check this, make a hex-dump to the vector table. Hitop shows a red entry if reset address is even. Entry should be black and odd address. [ This message was edited by: Janvi on 23-11-2009 09:20 ]2011-05-17 04:30 AM
I'm using startup_stm32f10x_hd.s as startup file.
The description of the default_handler says:Quote:
@brief This is the code that gets called when the processor receives an
* unexpected interrupt. This simply enters an infinite loop, preserving * the system state for examination by a debugger. I'm not sure if it is a hard fault or not? When using the macros or flashing the µC the PC has always the same value (0x80004DC). But only after flashing it doens't go the the default handler. I don't really know what you mean by making a hex-dump to the vector table. Upload the hex-table from the board to my hdd and than download it again? I ported my code to the eval board. Now I'm using the button to generate an interrupt. Via polling I can get the button status. I have also configured the interrupt and the interrupt pending bit is set correctly, but the PC doesn't change and the ISR isn't called. When the pending bit is set, then everything should be configured right? I have already checked the vector table in the startup file. It equals the one in the reference document.2011-05-17 04:30 AM
awesome!
Quote:
probably this file depends from which directory you took. Assume you have the GCC setup (and not tasking) at line 64 you see:
.section .text.Reset_Handler .weak Reset_Handler .type Reset_Handler, %function Reset_Handler: add a .thumb_func before the line Reset_Handler: and try the Reset and single step again. Be carefull, the STM Periph_lib files are probably write protected (but contain bugs to remove before use) solved the whole problem, interrupt is working now too thanks a lot :)2011-05-17 04:30 AM
> I'm using startup_stm32f10x_hd.s as startup file.
probably this file depends from which directory you took. Assume you have the GCC setup (and not tasking) at line 64 you see: .section .text.Reset_Handler .weak Reset_Handler .type Reset_Handler, %function Reset_Handler: add a .thumb_func before the line Reset_Handler: and try the Reset and single step again. Be carefull, the STM Periph_lib files are probably write protected (but contain bugs to remove before use) Attached is a typical screendump. The Mem0 debugger window shows the vector table g_pfnVectors typically located at 0x08000000. First entry is stackpointer at 20002800 and second the Reset_Handler start address. The example shows 0x08001691 what is a odd address. Also see the ''.thumb_func'' inside the source window of my Hitop debugger. [ This message was edited by: Janvi on 23-11-2009 21:39 ]