How to De-init the SysTick clock?

[Aatif Shaikh1]

Hello,

Currently, I'm working on a project in which the boat-loader is already present. Now, in the boat-loader, there are several things which I'm not using i.e Systick clock, DMA etc. So, I want to De-init all the unnecessary peripherals to run the CPU more efficiently. Unfortunately, I couldn't find anything related to how can I Dinit the Systick.

I'm using STM32F103CBT6 and Standard peripheral Library ( STSW-STM32054 ).

[Mike_ST]

Try  SysTick->CTRL = 0;

[Piranha]

Or even better - do not initialize anything! Here is a much better and simpler approach to bootloader design:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

[Aatif Shaikh1]

I'm having a bit peculiar problem, after the code jump to the main from boot loader, the moment I'm initializing the timer 3, my system getting hanged.

Although, I'm not able to resolve this issue so far.

[Aatif Shaikh1]

I'm not designing the bootloader, as it's already designed and present in the ~20k devices on the field. Hence, we can't modify every device's bootloader.

Previously, the bootloader and main code project files were written in IAR-ID, setting the main clock source to 24Mhz and the timer functionality was implemented using Systick at 25ms-interrupt.

Now, keeping the bootloader same, we've improvised the main code, moved the project on KIEL uVision, setting the main clock source to 64Mhz and the timer functionality was implemented using Timer-3 at 1ms-interrupt.

Unfortunately, whenever I'm initializing the Timer-3 in the main code, it's getting hanged and due to watchdog-timer, the code keeps getting reset.

[turboscrew]

And you can't find out the reason of hanging?

Do you use JTAG/SWD debugger?

You might want to put a breakpoint in the code and see if HAL is busy or something.

You can (usually) stop watchdog during debug halt if you set the DBG_WWDG_STOP- or DBG_IWDG_STOP-bit (dependin on the used watchdog) in DBGMCU_CR-register.

A dirty temporary way is:

*(uint32_t *)0xE004 2004 |= 0x00000300;

[Tesla DeLorean]

Yeah, so lets unpack that a bit

Get a proper Hard Fault handler running so you can get some actionable diagnostics before the thing watch-dogs.

Check the interrupt handler for the TIM3 binds correctly, and you've got SCB->VTOR pointing the vector table to the right location.

Have the SysTick kick the watchdog for the time being, and set the preempt/priority of the SysTick so it cuts through everything

[Aatif Shaikh1]

Finally, I found the problem, it all because of wrongly managing and improper definition in the boot loader code. Previous developer made a huge mistake, he selected STM32f100xB and STM32F10X_MD instead of STM32f103xB and STM32F10X_MD_VL. I guess, the Interrupt Number Definition might be different in these controller. That's why whenever I'm initializing the Systick or Timer 3 in my main code (which is a complete proper code with right controller and library selection), code is getting hanged!

[Aatif Shaikh1]

is there anything I can do? to overcome this situation?

[berendi]

The application should set SCB->VTOR pointing to its own interrupt vector table. Check it and correct it if necessary before activating any interrupt in the application.

Setting a wrong MCU part number in the bootloader is harmless, as long as the actual MCU is of the same series, and has all the resources the software is actually using. Interrupt request numbers should be compatible.