STM32F429 low voltage application Topic is solved

[Skadi]

Hi,

I have designed a PCB including the STM32F429. I already used this controller for several PCB designes, so the layout should be fine.

The only thing I have changed, compared to my other designes is the supply voltage. My current design is supplied with 1.8 V. According to the datasheet [1] the controller can handle a voltage down to 1.7 V. I'm able to flash the controller, and according to the STM32 ST-LINK Utility, everything is OK.

I have created an appropiate board.h file. I'm able to set a certain pin initially HIGH or LOW. I started with an ordinary "LED blinker thread" to check the controllers operation. But it it seems the main-program isn't excecuted/ got stucked.

I thougth the clock configuration may cause problems. I havn't found the maximal possible sytsem clock for a 1.8 V powered controller. According to table 18 on page 97 in the datasheet [1], the maximum HCKL can be 168 MHz (1.7 V to 2.1 V). Thus with a minimum AHB prescaler of 1, the system clock should be equal (168 MHz). I tried to operate my controller with a system clock of 84 MHz, but without any success. Although, I noticed a current consumption reduction. I'm using an external oscillator with 8 MHz.

That's my clock configuration:

Code: Select all

#define STM32_NO_INIT                       FALSE
#define STM32_HSI_ENABLED                   FALSE       
#define STM32_LSI_ENABLED                   TRUE       
#define STM32_HSE_ENABLED                   TRUE       /* High speed external clock. */
#define STM32_LSE_ENABLED                   FALSE
#define STM32_CLOCK48_REQUIRED              TRUE
#define STM32_SW                            STM32_SW_PLL
#define STM32_PLLSRC                        STM32_PLLSRC_HSE
#define STM32_PLLM_VALUE                    8           /* PLLM divider value       */
#define STM32_PLLN_VALUE                    336         /* PLLN multiplier value    */
#define STM32_PLLP_VALUE                    4           /* PLLP divider value       */
#define STM32_PLLQ_VALUE                    7           
#define STM32_HPRE                          STM32_HPRE_DIV2 /* AHB Prescaler */
#define STM32_PPRE1                         STM32_PPRE1_DIV1
#define STM32_PPRE2                         STM32_PPRE2_DIV1
#define STM32_RTCSEL                        STM32_RTCSEL_LSI
#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_DIV1
#define STM32_I2SSRC                        STM32_I2SSRC_CKIN
#define STM32_PLLI2SN_VALUE                 192
#define STM32_PLLI2SR_VALUE                 5
#define STM32_PVD_ENABLE                    FALSE
#define STM32_PLS                           STM32_PLS_LEV0
#define STM32_BKPRAM_ENABLE                 FALSE

Maybe someone had already similar problems!?! I'm thankful for any hint, solving my problem .

BR
Skadi

[1] Datasheet

[Giovanni]

I never tried, according to the RM the maximum frequency is 160MHz and there are other limitations, see chapter 3.5 and the table there.

Is the voltage specified correctly in board.h?

Giovanni

[Skadi]

Hi Giovanni,

yes, the board voltage is specified corret.

Code: Select all

#define STM32_VDD                   180U

The latency is a good hint. Do you know in which file I can modify the latency?

BR
Skadi

[Giovanni]

It is calculated by HAL in hal_lld.h based on frequency and voltage.

Giovanni

[Skadi]

In the meanwhile I had a closer look on the flash process. The STM32 ST-LINK Utility shows the following result:

18:43:11 : Memory programmed in 1s and 797ms.
18:43:11 : Verification...OK
18:43:11 : Programmed memory Checksum: 0x0016F2EC
18:43:13 : Flash memory [0x08000000:0x08200000] Checksum: 0x1F61F52E

I havn't checked the checksum until now. If the Programmed memory Checksum should be equal to the Flash memory [0x08000000:0x08200000] Checksum, I get a "corrupted" value. I don't know who is responsible for the "read out" of the checksum, by means of the used clock (STM32F429 system clock or ST-Link clock).

If the the controller clock is responsible for the checksum data output, the wrong set latency may cause the problem.

BR

[Skadi]

The two checksums are two DIFFERENT sums. By clicking on Target -> Memory Checksum and Compare Device Memory with [...], (in STM32 ST-LINK Utility), I get following result:

19:15:05 : Memory programmed in 1s and 766ms.
19:15:05 : Verification...OK
19:15:05 : Programmed memory Checksum: 0x0016F2EC
19:15:07 : Flash memory [0x08000000:0x08200000] Checksum: 0x1F61F52E
19:15:16 : [0x08000000:0x08003BDD] Memory Checksum: 0x0016F2EC
19:15:22 : No difference found.
This file is already downloaded.

So the flashing process should be correct.

I also set the board voltage to 1.7 V, for test purpose, and it results in an error (as expected). So the board file is included correct.

BR

[Skadi]

Hi,

I'm still struggling to get the controller working .

Here is the minimal main.c file I have uploaded.

Code: Select all

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

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

  halInit();
  chSysInit();

  palSetPadMode(GPIOB, 10, PAL_STM32_MODE_OUTPUT | PAL_STM32_OTYPE_PUSHPULL | PAL_STM32_OSPEED_HIGHEST | PAL_STM32_ALTERNATE(0) );

  while (true) {
    palClearPad(GPIOB, 10);
    chThdSleepMilliseconds(1000);
    palSetPad(GPIOB, 10);
    chThdSleepMilliseconds(1000);
  }
}


GPIOB 10 is attached to an LED. As I already mentioned, by changing its initail state (HIGH or LOW) in the board.h file, I can switch the LED on or OFF. But the LED doesn't start to blink.

I also set GPIOC 9 in the board.h file to its alternate operation mode 0. Which enables the microcontroller clock output MCO2. I checked the system clock at this PIN (as definde in the code in my initial post). I measure the expected 84 MHz clock signal, I also tried it with 42 MHz by reducing the system clock (increasing PLL_P to 8), and I measured the correct signal.

So it seems the controller is operating, by means of initializing the Hardware Abstraction Layer. But the ordinary blinker loop doesn't run .

[Giovanni]

Have you tried to single step to the problem?

Giovanni

[Skadi]

Hi Giovanni,

yes, I just tryied to debug the controller. I'm not a really experienced debugger, I usually using a LED . So I explain what I have done in more detail.

I'm using Chibi Studio and a ST-Link V2. I'm running OpenOCD with the stm32f429discovery.cfg file. And I get following massages in the Consol tab.

Code: Select all

Open On-Chip Debugger 0.10.0-dev-00107-ge4848fe (2015-11-13-11:49)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.761685
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

According to the last line, OCD should work.

When I start the debugging process, by choosing the correct debug configuration (which is a copy of an old project), a new tab opens with the hal_lld.c file. The program stops in line 127...

Code: Select all

  /* Initializes the backup domain.*/
  hal_lld_backup_domain_init();

After resuming the debug process, with a following suspension, a tab with the chsys.c file appers, and stops in line number 175 at ch.dbg.panic_msg = reason;

Code: Select all

void chSysHalt(const char *reason) {

  port_disable();

#if defined(CH_CFG_SYSTEM_HALT_HOOK) || defined(__DOXYGEN__)
  CH_CFG_SYSTEM_HALT_HOOK(reason);
#endif

  /* Pointing to the passed message.*/
  ch.dbg.panic_msg = reason;

  /* Harmless infinite loop.*/
  while (true) {
  }
}

By resuming the debugging process, nothing happens. I stay at line numbe 175 in chsys.c.

I have no clue what's going wrong .

UPDATE: I'm able to set a GPIO pin HIGH or LOW, so I'm able to switch of my LED ON and OFF in debugging mode.

[Giovanni]

Hi,

You are hitting an assertion there, the variable "reason" points to an error message in memory. That is your problem.

Giovanni