STM32F7 Systick question

[megahercas6]

Posted on July 20, 2015 at 10:20

Hello,

Right now i am try to remake my project for STM32F7 from STM32F4. HAL is just paint to work, i was unable to figure out what i have to write to functions to make it hal compatable, so instead i have to go with basic Cortex_m7 functions. Right now i am facing strange problem. For some reason i need to enable systic timer, and if it not enabled, i just get into hard fault handler, with no explanation

RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
__PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 12;
RCC_OscInitStruct.PLL.PLLN = 400;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 2;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
HAL_PWREx_ActivateOverDrive();
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV2;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3);
HAL_RCC_EnableCSS();
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

But i don't need systic timer that counts in miliseconds, and i remouved this delay funtion from hal init library, i don't want for cortex_m7 get interrupts, even then servicing this interupt takes very little time. Now the fun part.

//SCB_EnableICache();
//SCB_EnableDCache();

If i disable I and D cache, my interrupt works with no systick functions, I have no idea why And interrupt code looks like this:

uint32_t counter = 0;
void EXTI0_IRQHandler(void)
if((EXTI->PR&0x0001)==0x0001)
{
HAL_GPIO_TogglePin(GPIOG,GPIO_PIN_6|GPIO_PIN_7);
counter++;
EXTI->PR = 0x0001;
}
}

Any one has any idea just what a hell i going on ? I am using new IAR arm version, and i done everything in my knowledge to make good configuration for clocks and so on.

[Amel NASRI]

Posted on July 22, 2015 at 15:19

Hi karpavicius.linas,

Could you please precise how are you doing in order to disable the systick? What are you removing from the code exactly?Do you have same issue if you comment:- the call of ''HAL_InitTick in ''HAL_Init'' (stm32f7xx_hal.c)and- the SysTick Handler (stm32f7xx_it.c)-Mayla-

[megahercas6]

Posted on July 24, 2015 at 09:11

At this point in time, i don't even bother to supply what was wrong in this example. it does not matter what i do, or what example i am trying to implement on my board, it just crashing, crashing, and again, crashing to HardFault_Handler

same pcb, same everything, and STM32F429 LQFP144 is running very very very happy with my code implemented on SPL So i don't know what to do at this point, i think i should develop same hardware on NXP parts or something, because as i stated in other thread, for me, it just does not work. So, what do i am missing, if code generated by cubeMx will crash with no reason at random places ? i would blame fault on my hardware, but same pcb with same exact parts will run STM32F429 that is 1:1 replacement for STM32F746 in LQFP144    

[Amel NASRI]

Posted on July 24, 2015 at 13:51

So, what do i am missing, if code generated by cubeMx will crash with no reason at random places ?

For sure, there is a reason for the crash. Did you tested some examples provided in the Cube package? Do you face same issue?Please review the 

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00164538.pdf

 to check if you missed some points when migrating from F4 to F7.-Mayla-

[Tesla DeLorean]

Posted on July 24, 2015 at 15:13

Of all things, something that generates Hard Faults all the time should be one of the easier things to decipher. The processor provides a whole bunch of state information to allow you to understand the fault.

I'd expect it's either going to fault as a result of touching the same memory (illegal address), the fault address (the code touching the memory) would be fairly consistent, Or there's some other interrupt or servicing issue, where the fault address would appear to be inconsistent/random.

[megahercas6]

Posted on July 24, 2015 at 17:20

i found very interesting behavior. When i recompile code. I get into hard fault loop. disconnecting power and reconnecting, it start to work ( to processor)

And after that power up, it did not crash at all, maybe it's debugging that causing problems ? So i did switch to ''reset pin'' programming mode, thinking it can help.in the end, no This type of behavior usually was due to wrong flash latency, pll speed, and stuff like that, but i triple-checked this, and having same problems even at very slow speeds.

[Tesla DeLorean]

Posted on July 24, 2015 at 17:38

Well it's going to be interesting. The F7 HAL is likely still a bit immature, and who knows if there aren't some errata hidden in the M7 core, caches, or peripherals. ST has been quite diligent in prior designs, and given the time lag from announcement to delivery, the chip's been spun a couple of times in my estimation.

The best thing you can do is analyze and document failures/issues you observe, with enough detail, that any patterns in the failure can be seen and duplicated.I haven't used the HAL, but I've used the F7 without SysTick running.

[megahercas6]

Posted on July 27, 2015 at 10:02

Ok, so, little by little i am moving forward with porting code.

So more in detail about strange behavior: So lets say, i change PLL multiplication to reach 205MHz ( that is legal ). After recompile and debugging season starts, it just crash to hard-fault. In the same code i have working spi example, so i know does mcu goes to that part of code. So i could see any spi clock event, but when it crashes, where is not a single clock cycle in serial clock line. That is to be expected, no problems. Now, when i disconnect end reconnect power to MCU, SPI just start to work, and when i attach debugger again, everything is working as it should ! So same code after flashing is not working, and after power cycling, it is working. This just does not make any sense. And i don't get correlation that i need to do something with PLL, it happens at randoms function calls, one time with when i change SPI init, second when i change GPIO config, So i can't to this day found any correlation, why it's stops working, but after power cycle is as good as it can. Any ideas ? Regarding systick, i simply stop systick timer after i done all init functions. And i am using low level spi functions with 0 overhead ( or smallest amount of code for PSI to work in proper fashion)