Problem on a F407VG board

[guig73]

Hello everybody.

I already have been successful to use ChibiOS with the STM32F103 and STMF411 pills.

But I currently struggle a bit with this board :
https://stm32-base.org/boards/STM32F407VET6-STM32F4XX-M

My board version uses a STM32F407VGT6.
I’ve copied the RT-STMF4-discovery example project, which has the same MCU, and started to setup the board with the board configuration tool, as I did for my other projects.

I’ve simplified it as the simplest possible, just starting the OS and blink the LED.

The HAL and MCU config also the simplest, with only PAL activated.

The sleep in the main function is 1000ms, and the blinker is 500ms ON and 500ms OFF.
When I debug the program, I see the first sleep in the main is executed correctly, but when it comes to the first sleep of the blinker thread, the board reboots as I can see it executes again the init function where I set a breakpoint.
It seems to fail when the context switch happens as I can enter the context switch function.

Code: Select all

/*
 ChibiOS - Copyright (C) 2006..2018 Giovanni Di Sirio

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
 */

#include "ch.h"
#include "hal.h"

/*
 * This is a periodic thread that does absolutely nothing except flashing
 * a LED.
 */
static THD_WORKING_AREA(waThread1, 128);
static THD_FUNCTION(Thread1, arg) {

  (void)arg;
  chRegSetThreadName("HeartBeat");
  while (true) {
    palSetPad(GPIOA, GPIOA_ONBOARD_LED_D2); /* green. */
    chThdSleepMilliseconds(500);
    palClearPad(GPIOA, GPIOA_ONBOARD_LED_D2); /* green.  */
    chThdSleepMilliseconds(500);
  }
}

/*
 * Application entry point.
 */
int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  /*
   * Creates the example thread.
   */
  chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO - 1, Thread1, NULL);

  /*
   * Normal main() thread activity, in this demo it does nothing except
   * sleeping in a loop and check the button state.
   */
  while (true) {
    /*palWaitLineTimeout(PAL_LINE(GPIOA, GPIOA_ONBOARD_BUTTON_K1), TIME_INFINITE);*/
    chThdSleepMilliseconds(1000);
  }
}



If I set the sleep in the main function is 100ms and the blinker to both 50ms, the program runs fine.

According to the website above, the HSE osc is 16Mhz.
Whereas the F4 discovery has a 8Mhz osc.
It would be better if I read correctly the specs....

Could it come from this difference ?
Could the PLL setup is totally to rethink in this case ?
I have just dumbly copied the mcuconf.h from the F4 disco.

Or would it have another reason ?

The option bytes show a HW or SW watchdog option.
I’ve modified it, but seems to have no effect here.

Any suggestion to debug it would be very welcome.

Thank you very much.

[Giovanni]

If the external oscillator has the same frequecy then mcuconf.h should not change, if it has a different frequency you just need to adjust the PLL input divider "M" (if I remember well).

Other differences are all in board files, you need to create board files for that board.

Giovanni

[guig73]

Thank you for your help Giovanni.

Code: Select all

/*
 * HAL driver system settings.
 */
#define STM32_NO_INIT                       FALSE
#define STM32_PVD_ENABLE                    FALSE
#define STM32_PLS                           STM32_PLS_LEV0
#define STM32_BKPRAM_ENABLE                 FALSE
#define STM32_HSI_ENABLED                   FALSE
#define STM32_LSI_ENABLED                   FALSE
#define STM32_HSE_ENABLED                   TRUE
#define STM32_LSE_ENABLED                   TRUE
#define STM32_CLOCK48_REQUIRED              TRUE
#define STM32_SW                            STM32_SW_PLL
#define STM32_PLLSRC                        STM32_PLLSRC_HSE
/*
 * Clock input for the PLL
 * PLLCLK_IN = HSE / PLLM_VALUE
 * => 1Mhz
 */
#define STM32_PLLM_VALUE                    8
/*
 * VCO clock
 * VCO_CLK = PLLCLK_IN * PLLN_VALUE
 * => 336Mhz
 */
#define STM32_PLLN_VALUE                    336
/*
 * The SYSCLK from the PLL
 * PLLCLK_OUT = VCO_CLK / STM32_PLLP_VALUE
 */
#define STM32_PLLP_VALUE                    2
/*
 * The 48MHz clock
 * PLL48CLK = VCO_CLK / STM32_PLLQ_VALUE
 */
#define STM32_PLLQ_VALUE                    7
#define STM32_HPRE                          STM32_HPRE_DIV1
#define STM32_PPRE1                         STM32_PPRE1_DIV4
#define STM32_PPRE2                         STM32_PPRE2_DIV2
#define STM32_RTCSEL                        STM32_RTCSEL_LSE
#define STM32_RTCPRE_VALUE                  8
#define STM32_MCO1SEL                       STM32_MCO1SEL_HSE
#define STM32_MCO1PRE                       STM32_MCO1PRE_DIV1
#define STM32_MCO2SEL                       STM32_MCO2SEL_SYSCLK
#define STM32_MCO2PRE                       STM32_MCO2PRE_DIV5
#define STM32_I2SSRC                        STM32_I2SSRC_CKIN
#define STM32_PLLI2SN_VALUE                 192
#define STM32_PLLI2SR_VALUE                 5

I've checked with the doc each values and enabled the setting for using the HSE clock (8MHz)

It does exactly the result.

It looks like there is a kind of watchdog that prevent longer sleep intevals...

[guig73]

Ah ! Eureka !
I've found the problem !

It was indeed due to a WDT.
The WDT_SW switch in option bytes was not checked, probably due to the initial application inside the MCU.
Since I checked it, it runs fine !

If my trouble could help someone else...

Thank you for your help anyway.