Why systick timer interruption is occurring correctly on a nucleoboard debug session but it is never ocurring when the same fw is on a same mcu based custom board?

[genisuvi]

I am stucked 4 days at HAL_systickInit part of a code that was generated by Cube MX. I'm using:

• CubeIDE 1.6.1
• HAL drivers firmware layer
• FreeRTOS Middleware
• Nucleo-F207zg
• Custom pcb (very simple circuit board --> write and read GPIO from 32pin connector and 8 x Gpio inputs from a mechanical switch ( x8 vias). MCU=F207zg.
• ST-Link debug probe (Nucleo)
• SEGGER debug probe (for custom board debug sessions with SWD interface)

I have done a firm version using cubeMx for clock and system base timer configurations. I used the generated code for initialitation, etc... I added some writes and reads pins threads and my app works fine on the Nucleo board. I get a previous demo-example in order to start from a working and reliable firmware.

My test app is very simple, one task toggle 5 digital ouptuts (3 of them are the 3 leds on nucleo board) and the other one gets 5 pull up digiltal inputs. It was ok.

After this, I added a very little modifications to this code -such as some pin mapping- in order of getting a custom pcb compliant app.

When I started the execution, I was able to see that HAL_Init calls HAL_InitTick that:

1. /*Configure the TIM6 IRQ priority */
2. /* Enable the TIM6 global Interrupt */
3. /* Enable TIM6 clock */
4. /* Get clock configuration */
5. /* Get APB1 prescaler */
6. /* Initialize TIM6 */
7. calls HAL_TIM_Base_Init and this returns HAL_OK
8. calls HAL_TIM_Base_Start_IT which is starting the timer and set the flag that enables interruptions --> after pass the __HAL_TIM_ENABLE_IT(timer, 1) statement DIER = 1
9. Finally /* Enable the Peripheral*/ and returns HAL_OK

It seems interrupt enable is set and then, every milisecond thread should jump to its ISR --> HAL_TIM_IRQHandler() that calls its callback --> HAL_IncTick.

But unfortunately thread has never jumped there. I put breakpoints and anytihing happens. After going out from HAL_Init function application thread is also unable of configure the clock system. I think that the main point to solve is the tick count, that is not dependent from clock config since HAL_init is the first action to to before anything else.

My very nonunderstanding issue from this problem is how the same first instructions (only HAL dependent) can work propperly on the nucleo board mcu, but not on the same microcontroler out of Nucleo board.

• Is it due the SEGGER + FreeRTOS influence?
• If not, any suggestions on the steps path for achieving the answer why is not working this timer interruptions?
• Damage on mcu peripherals? how Can I discard microcontroler damage issues?

Run IDE option show me that downloading is verified and no error ocurres during exe download.

I will add pictures and code if someone needs it, after this post loading, to bring me some light. Now I'm not sure what part of code could be useful to show. The most are HAL library and Cube MX generated code.

I hope readers can understand this explanation. Sorry about my English grammar.

[Tesla DeLorean]

Custom board.

Pay particular attention to BOOT0 being pulled LOW, the VCAP capacitors/voltages, the analogue supplies.

Watch the clocking source, perhaps use HSI+PLL as HSE on NUCLEO provided by a constant 8 MHz clock.

Share portion of schematic.

[genisuvi]

Dear @Community member​ 

thank you a lot for taking some time for reading my post and answer these tips.

I was reading and thinking about the first one.

Since this mcu datasheet says:

I noticed that Nucleo board has the first configuration values by default (it is possible to see looking at the Nucleo board schematics). So when it is programmed with ST-Link GDB series, binary file is downloaded and writen on the main flash memory - before PC counter starts to increment its count -.

The custom board is an heritance from external designer. I took a look to the scheme and I could see that BOOT0 is being pulled up to 3.3V.

Obviously the start system seems not to be the same. But the fact that I don't know if this configuration was thought (even needed) to program the memory of the mcu using SEGGER J-Link.

Could it be reasonable that BOOT0 must to be tied to high?

I think not, because this board is using BOOT1 pin (B2) as a digital input, but... who knows.

 

I will make some fixtures on the board in order to get GND on BOOT pin instead VCC and I will try to debug once again.

Regarding clock I'm using HSI when I debug on custom board. But as I said tick timer interruptions for HAL layer drivers are not being produced after they are enabled, so clock is unable to be configured. Because I'm using HAL layer libs.

I can also see how no capacitors are connected to VCAP1 and VCAP2. According to datasheet reading this could cause internal circuitry missfunction. I hope this 1.2V internal regulator not to be damaged when SEGGER was connected and used for debugging.

I've just added some measures from VCAP1 and VCAP2 pins:

• 1.18V
• 1.18V

They should be 1.2V between two pins, is it?

Anyways, I will modify the printed circuit in order to discard this issue as the source of the non setup problem. I will comment here the results after completing this new step.