STM32F303CBT6 ChibiOS support

[johnisenglish]

Hello!

I'm working on a ChibiOS application for the STM32F303CBT6, but thus far I haven't been able to get a binary to run on the microcontroller. The CBT6 is a 48-pin variant of the F303, with 32K of RAM, rather than 40K.

I've begun by using the demo under /ARMCM4-STM32F303-DISCOVERY/, testing on a normal discovery board with the STM32F303VCT6, compiling with Launchpad GCC in Linux. The demo works fine on the discovery board, so I believe that my build environment and programming tools are working properly.

To adapt the program for the CBT6, I've changed the STM32F303xC.ld file under ChibiOS-RT/os/ports/GCC/ARMCMx/STM32F3xx/ld/ to reflect the smaller memory size than the VCT6. The relavent line was changed to:

Code: Select all

ram : org = 0x20000000, len = 32k

I've tried this on the CBT6, but I get no signs of life. Next, I went into main.c of the demo, and removed all the references to GPIOE pins, since there is no Port E on the CBT6. Still, no signs of life.

Does anyone have suggestions for where else I should look to modify the code? I imagine it must be something simple, as the STM32F303CBT6 and 303VCT6 are very similar.

Thank you!

[Giovanni]

Hi,

Things to check:
1) board files, you need to create them for your board (I/O settings, clock values).
2) if the crystal clock is different from the original demo you need also to adjust the clock three settings in mcuconf.h in order to obtain correct frequencies.

Giovanni

[johnisenglish]

Thank you for your response.

I've created new board directory with modified versions of board.c, board.h, and board.mk. I've also verified that the clock settings match. So far my changes will still run on the F3-discovery board, but not the F303CBT6.

Perhaps there is a problem in the HAL configuration? There are no UART/USART4 and 5 peripherals in the F303CB, so I wonder if that difference might be an issue. The file /os/hal/platforms/STM32F30x/stm32f30x.h has a number of definitions regarding UART4/5, including interrupt numbers.

There are also definitions in /os/hal/platforms/STM32F30x/stm32_registry.h that seem like they could potentially be problematic for the F303CB:

Code: Select all

#define STM32_HAS_GPIOD         TRUE
#define STM32_HAS_GPIOE         TRUE

This is my first experience with ChibiOS, so I'm trying to get a better understanding of what kind of changes need to take place to port to this sub-variant of the F303. Should I attempt to make a new directory under /platforms/ and remove all references to UART4/5, Ports D and E, and most of Ports C and F?

[Giovanni]

You should not need to do that assuming the devices are similar except for missing units, just make sure to disable the non-existing units in mcuconf.h.

If would be useful to know where exactly the program stops using the debugger.

Giovanni

[johnisenglish]

It's taken me a while to get an STLink V2 debugger setup with GDB - I've had final exams with grad school to contend with. Fortunately, I've had some time today to revisit this (I also switched to the STM32F303CCT6, for more flash memory)

I've found that I can get example programs for the F3 discovery board to run on the STM32F303CCT6 on my board, if I program it using arm-none-eabi-gdb, but not via qstlink2 or dfu-util. The terminal output from successfully running a program with gdb is:

$ arm-none-eabi-gdb build/ch.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140228-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
---Type <return> to continue, or q <return> to quit---
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/john/git/WS2812B-LED-Driver-ChibiOS/build/ch.elf...done.
(gdb) tar extended-remote :4242
Remote debugging using :4242
ResetHandler () at ChibiOS-RT/os/ports/GCC/ARMCMx/crt0.c:267
267 asm volatile ("cpsid i");
(gdb) load
Loading section startup, size 0x188 lma 0x8000000
Loading section .text, size 0x1f14 lma 0x8000190
Loading section .data, size 0x494 lma 0x80020a8
Start address 0x8000240, load size 9520
Transfer rate: 8 KB/sec, 3173 bytes/write.
(gdb) continue
Continuing.

My understanding is that this process is programming the microcontroller's RAM, and I have yet to successfully get code running from flash. The abridged terminal output from programming with qstlinkv2 is:

$ sudo qstlink2
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Verbose level: 3
116 - Info: setGuid Dummy
116 - Info: Devices list loaded.
2145 - Info: libusb_bulk_transfer Error reading: -7
2145 - Info: LIBUSB_ERROR_TIMEOUT
2249 - Info: CoreID: "2ba01477"
2251 - Info: CM3/4 Searching at "e0042000"
2251 - Info: ChipID: "422"
2251 - Info: Device type: "STM32F30*"
2253 - Info: Flash size: 256 KB
9431 - Info: Using loader
9438 - Info: Writing from "0x8000000" to "0x800253c"
9741 - Info: libusb_bulk_transfer Error reading: -7
9741 - Info: LIBUSB_ERROR_TIMEOUT
9741 - Info: Loader ":/bin/loader_f30.bin"
10158 - Info: libusb_bulk_transfer Error reading: -7
10158 - Info: LIBUSB_ERROR_TIMEOUT
10503 - Info: Progress: "11%"
10796 - Info: Progress: "99%"
10817 - Info: Page(s) deleted
10817 - Info: Transfer done

I'm glad to have made this progress, but I'm not sure how best to proceed. Is there further debug information I should attempt to get with GDB and the stlinkv2 programmer?

[Giovanni]

Hi,

I think you have a problem with tools, could you give ChibiStudio a try? it includes Eclipse, compiler, debugger, ChibiOS and all demos ready to be compiled and loaded in flash.

https://sourceforge.net/projects/chibio ... ibiStudio/

About the F3, the datasheet states all models have 3 USARTs and 2 UARTs.

Giovanni

[johnisenglish]

It appears that you are correct! I tested the same code, using my work computer, and qstlink2 doesn't have the same "LIBUSB_ERROR_TIMEOUT" that I was experiencing last night. It successfully programs on my work computer, using the syntax: "qstlink2 -cli --write --verify ./build/ch.bin."

Regarding the UART ports - page 10 of the STM32F303 datasheet shows the 303Cx devices only having 3 USARTS, and no UARTS. Perhaps I have misinterpreted this, though. Whatever the case, leaving in defines related to USART4/5 does not seem to cause any problems - it was probably by toolchain that lead to trouble.

Now that I can comfortably program, I've encountered a different issue. My board uses an 8Mhz external crystal, whereas the F3 discovery boards receives an external clock from the on-board F0. I need to enable the crystal oscillator for my board, so I've commented out "#define STM32_HSE_BYPASS" from the board.h file. However, it does not appear that the crystal oscillator is active in hardware. What else might need to done to enable this feature?

Thank you for your help. My background is in hardware and PCB layout, so I have a lot to learn about RTOS software development.

[Giovanni]

Hi,

All the clock related settings are in mcuconf.h, look at the mcuconf.h of the STM32F373 demos, if I remember well those uses a crystal and is very similar.

Giovanni

[johnisenglish]

It looks like the STM32F373 eval board does use an external clock. The mcuconf.h files for that demo, and the stm32f303 discovery board demo look very similar. I believe the relevant defines for clock configuration are:

Code: Select all

#define STM32_NO_INIT                       FALSE
#define STM32_PVD_ENABLE                    FALSE
#define STM32_PLS                           STM32_PLS_LEV0
#define STM32_HSI_ENABLED                   TRUE
#define STM32_LSI_ENABLED                   TRUE
#define STM32_HSE_ENABLED                   TRUE
#define STM32_LSE_ENABLED                   FALSE
#define STM32_SW                            STM32_SW_PLL
#define STM32_PLLSRC                        STM32_PLLSRC_HSE
#define STM32_PREDIV_VALUE                  1
#define STM32_PLLMUL_VALUE                  9
#define STM32_HPRE                          STM32_HPRE_DIV1
#define STM32_PPRE1                         STM32_PPRE1_DIV2
#define STM32_PPRE2                         STM32_PPRE2_DIV2

All of that is identical for both demos. The only differences I can find between that looks relevant is in their respective board.h files, where the F303 has "#define STM32_HSE_BYPASS," but the F373 does not. Commenting out that line for my code does not appear to enable the oscillator in hardware.

I'm wondering if there is a missing step, or if the initialization has the wrong order. I was able to get the external oscillator working on a different F303 board with LibopenCM3, using the following steps:

Code: Select all

  /* Enable internal high-speed oscillator. */
  rcc_osc_on(HSI);
  rcc_wait_for_osc_ready(HSI);
 
  /* Select HSI as SYSCLK source. */
  rcc_set_sysclk_source(RCC_CFGR_SWS_HSI);
 
  /* Enable external high-speed oscillator 8MHz. */
  rcc_osc_on(HSE);
  rcc_wait_for_osc_ready(HSE);
  rcc_set_sysclk_source(RCC_CFGR_SWS_HSE);
 
  /*
   * Set prescalers for AHB, ADC, ABP1, ABP2.
   * Do this before touching the PLL (TODO: why?).
   */
  rcc_set_hpre(RCC_CFGR_HPRE_SYSCLK_NODIV);    /* Set. 72MHz Max. 72MHz */
 //rcc_set_adcpre(RCC_CFGR_ADCPRE_PCLK2_DIV8);  /* Set.  9MHz Max. 14MHz */ //TODO: Determine if this step is needed for the F303
  rcc_set_ppre1(RCC_CFGR_PPRE1_DIV_2);     /* Set. 36MHz Max. 36MHz */
  rcc_set_ppre2(RCC_CFGR_PPRE2_DIV_NONE);    /* Set. 72MHz Max. 72MHz */
 
  /*
   * Sysclk runs with 72MHz -> 2 waitstates.
   * 0WS from 0-24MHz
   * 1WS from 24-48MHz
   * 2WS from 48-72MHz
   */
  flash_set_ws(FLASH_ACR_LATENCY_2WS);
 
  /*
   * Set the PLL multiplication factor to 9.
   * 8MHz (external) * 9 (multiplier) = 72MHz
   */
  rcc_set_pll_multiplication_factor(RCC_CFGR_PLLMUL_PLL_IN_CLK_X9);
 
  /* Select HSE as PLL source. */
  rcc_set_pll_source(RCC_CFGR_PLLSRC_HSE_PREDIV);
 
  /*
   * External frequency undivided before entering PLL
   * (only valid/needed for HSE).
   */
  rcc_set_pllxtpre(RCC_CFGR_PLLXTPRE_HSE_CLK);
 
  /* Enable PLL oscillator and wait for it to stabilize. */
  rcc_osc_on(PLL);
  rcc_wait_for_osc_ready(PLL);
 
  /* Select PLL as SYSCLK source. */
  rcc_set_sysclk_source(RCC_CFGR_SWS_PLL);
 
  /* Set the peripheral clock frequencies used */
  rcc_ppre1_frequency = 36000000;
  rcc_ppre2_frequency = 72000000;

Perhaps I should investigate the function "stm32_clock_init" in /os/hal/platforms/STM32F30x/hal_lld.c? I see that it has provision for both HSE bypass and No HSE bypass modes

[Giovanni]

That function is very similar between the F303 and the F373. Disabling the bypass should be sufficient to start the oscillator.

Giovanni