LeafLabs Garden » Topic: Inofficial libmaple F3-port

LeafLabs Garden » Topic: Inofficial libmaple F3-port http://forums.leaflabs.com/topic.php?id=11883 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:04:56 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105496 Sun, 24 Aug 2014 05:34:26 +0000 gbulmer 105496@http://forums.leaflabs.com/ @ala42 and @ventosus- Thank you for posting that. Separating a MB1136 C-02 nucleo into two pieces isn't as easy and benign as it might appear! I assume, for parts with on-chip USB, that separation would cause them to fall outside the USB timing spec if the user programs to use the internal oscillator. The STM32F042 and STM32F072 subfamilies has an internal precision oscillator to provide 'crystal-less' USB, but the vast majority of STM32 do not. ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105495 Fri, 22 Aug 2014 03:01:14 +0000 ventosus 105495@http://forums.leaflabs.com/ @ala42 thanks, I have seen that in the meantime, too. I have never used a Discovery, so could't know... Apparently the Nucleo boards are shipped in at least two versions, one configured with no external crystal (MB1136 C-01: the one I got), the other prewired to the ST-Link clock (MB1136 C-02). ala42 on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105494 Tue, 19 Aug 2014 17:29:46 +0000 ala42 105494@http://forums.leaflabs.com/ 5.7 OSC clock 5.7.1 OSC clock supply There are four ways to configure the pins corresponding to external high-speed clock external high-speed clock (HSE): • MCO from ST-LINK: MCO output of ST-LINK MCU is used as input clock. This frequency cannot be changed, it is fixed at 8 MHz and connected to PF0/PD0/PH0- OSC_IN of STM32 microcontroller. The following configuration is needed: – SB54, SB55 OFF – R35,R37 removed – SB16, SB50 ON In case you forgot, the Discovery F3 also has no oscillator in the F3 part of the board, you also use the 8Mhz clock from the ST-Link part. ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105493 Tue, 19 Aug 2014 02:31:21 +0000 ventosus 105493@http://forums.leaflabs.com/ >> Well done for debugging the lack of crystal. That must have been hard to spot. Not at all. When I saw that my blinky sketch did not blink, I just fired up the ST-LINK/V2-1 via OpenOCD+GDB and looked where the sketch was hanging and immediately saw that it was stuck in an indefinite loop trying to bring up the external crystal. After a shy look at the board I saw that there was none... OpenOCD does not yet ship with a board config file for the nucleo F302R8, this did the trick for me though (OpenOCD 0.8.0): <code> st_nucleo_f302r8.cfg -------------------- source [find interface/stlink-v2-1.cfg] source [find target/stm32f3x_stlink.cfg] reset_config srst_only srst_nogate gdb_memory_map disable </code> gbulmer on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105492 Mon, 18 Aug 2014 05:11:15 +0000 gbulmer 105492@http://forums.leaflabs.com/ @ventosus - Thank you for sharing this. Your timing is excellent. I was looking at Farnell over the weekend, and they have the STM32F302 nicleo in stock, so I was wondering about getting some to experiment with. Well done for debugging the lack of crystal. That must have been hard to spot. Cheers! ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-105491 Mon, 18 Aug 2014 02:40:57 +0000 ventosus 105491@http://forums.leaflabs.com/ I have updated the F3-port to support more chips. Theoretically all the currently available STM32F301/302/303 chips should be supported: STM32F301xx: -STM32F301K6 -STM32F301K8 -STM32F301C6 -STM32F301C8 -STM32F301R6 -STM32F301R8 STM32F302xx: -STM32F302K6 -STM32F302K8 -STM32F302C6 -STM32F302C8 -STM32F302CB -STM32F302CC -STM32F302R6 -STM32F302R8 -STM32F302RB -STM32F302RC -STM32F302VB -STM32F302VC STM32F303xx: -STM32F303K6 -STM32F303K8 -STM32F303C6 -STM32F303C8 -STM32F303CB -STM32F303CC -STM32F303R6 -STM32F303R8 -STM32F303RB -STM32F303RC -STM32F303VB -STM32F303VC <a href="https://github.com/ventosus/libmaple/tree/F3" rel="nofollow">https://github.com/ventosus/libmaple/tree/F3</a> Apart from the STM32F303CB and STM32F303CC that I have thoroughly tested so far, I have a ST NUCLEO-F302R8 since some days. <a href="http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259999" rel="nofollow">http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259999</a> To use the nucleo with the F3-port, just compile for [code] BOARD=F302R8 MEMORY_TARGET=jtag [/code] mount the nucleo as USB mass storage, copy the bin/F302R8.bin to the mass storage, unmount it and the sketch should be running. The included ST/Link works out of the box with OpenOCD and GDB. My nucleo was shipped without an oscillator, as libmaple by default assumes that there is an external oscillator and will block until it's up and running, the following patch needs to be applied, though: [code] diff --git a/wirish/boards.cpp b/wirish/boards.cpp index a693fa6..e97259d 100644 --- a/wirish/boards.cpp +++ b/wirish/boards.cpp @@ -122,8 +122,8 @@ static void setup_clocks(void) { RCC_BASE->CIR = 0x00000000; // Enable HSE, and wait until it's ready. - rcc_turn_on_clk(RCC_CLK_HSE); - while (!rcc_is_clk_ready(RCC_CLK_HSE)) + rcc_turn_on_clk(RCC_CLK_HSI); + while (!rcc_is_clk_ready(RCC_CLK_HSI)) ; // Configure AHBx, APBx, etc. prescalers and the main PLL. diff --git a/wirish/stm32f3/boards_setup.cpp b/wirish/stm32f3/boards_setup.cpp index 6984419..b1a4991 100644 --- a/wirish/stm32f3/boards_setup.cpp +++ b/wirish/stm32f3/boards_setup.cpp @@ -59,7 +59,7 @@ namespace wirish { namespace priv { static stm32f3_rcc_pll_data pll_data = {.pll_mul=BOARD_RCC_PLLMUL, .pcl - __weak rcc_pll_cfg w_board_pll_cfg = {RCC_PLLSRC_HSE, &pll_data}; + __weak rcc_pll_cfg w_board_pll_cfg = {RCC_PLLSRC_HSI_DIV_2, &pll_data}; __weak adc_prescaler w_adc_pre = ADC_PRE_PCLK_DIV_1; __weak adc_smp_rate w_adc_smp = ADC_SMPR_181_5; [/code] gbulmer on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-104963 Fri, 22 Nov 2013 11:24:32 +0000 gbulmer 104963@http://forums.leaflabs.com/ ventosus - Thank you for the links. My changes are based on ST's annotationAN4296: <a href="http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00083249.pdf" rel="nofollow">http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00083249.pdf</a> I had missed that, so thank you very much. "Have you done any experiments to measure the effect?" No real benchmarking, but I've put interrupts and critical routines into CCM in one of my projects for testing and got an immediate speed-up in the range of 10% to 20%. 10%-20% is pretty impressive for a chip which is already pretty quick . "Is there a slow-down if both code and data reside in core coupled memory (CCM)?" This I don't know. Would you expect this? Well, I have looked through the STM32F303 datasheet, and all it says about the CCM is "2.3 Embedded SRAM The STM32F30xx features up to 48 Kbytes of static SRAM. It can be accessed as bytes, halfwords (16 bits) or full words (32 bits): ● ... ● 8 Kbytes of CCM RAM. ... This memory can be addressed at maximum system clock frequency without wait state." So it looks fine. However there isn't anything more concrete. Also, I vaguely remember there being a buffer between the CPU and SRAM, which 'pipelined' the 2nd and subsequent write, but was complex enough that it might slow the first write, or interact with reads. I haven't found this mentioned any where for Cortex-M4 so I may be thinking Cortex-M3. Summary: I am happy to believe it does everything perfectly, no matter what mix of instructions and data are used, but I am also willing to believe that there are interactions between reading instructions and writing data. However, 10-20% is enough to convince me it's worth it anyway :-) ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-104962 Fri, 22 Nov 2013 08:28:27 +0000 ventosus 104962@http://forums.leaflabs.com/ My changes are basen on ST's annotationAN4296: <a href="http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00083249.pdf" rel="nofollow">http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00083249.pdf</a> linker script with its section definitions is at: support/ld/common.inc initialization code, where code from FLASH is copied to CCM is at: wirish/start_c.c Here is the git commit with the changes: <a href="https://github.com/ventosus/libmaple/commit/3a745ec937647f48bc94a58b938ab26f882e752c" rel="nofollow">https://github.com/ventosus/libmaple/commit/3a745ec937647f48bc94a58b938ab26f882e752c</a> Have you done any experiments to measure the effect? No real benchmarking, but I've put interrupts and critical routines into CCM in one of my projects for testing and got an immediate speed-up in the range of 10% to 20%. Is there a slow-down if both code and data reside in core coupled memory (CCM)? This I don't know. Would you expect this? gbulmer on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-104961 Fri, 22 Nov 2013 06:36:38 +0000 gbulmer 104961@http://forums.leaflabs.com/ ventosus - That's very interesting! It might be helpful if you would post a link to the ld (load) script? Have you done any experiments to measure the effect? Is there a slow-down if both code and data reside in core coupled memory (CCM)? ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-104957 Thu, 21 Nov 2013 14:26:05 +0000 ventosus 104957@http://forums.leaflabs.com/ I've worked some of my poor ld-script-fu to make the 8kB core coupled memory (CCM) usable. One can now put code in there which will be run at maximum speed (zero wait state compared to 2 wait states when loading code from FLASH). It can also be used as extended SRAM of course. The right place to put interrupts and other critical code to get a considerable performance increase... There is a convenience macro __CCM__ which sets the corresponding section attributes. <code> #define __CCM__ __attribute__((section(".CCM"))) </code> Just append it to your data or function prototypes to be put into core coupled memory. <code> int mydata __CCM__ = 23; </code> <code> void myfunc(void) __CCM__; void myfunc(void) { ... } </code> gbulmer on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-31743 Mon, 23 Sep 2013 14:28:10 +0000 gbulmer 31743@http://forums.leaflabs.com/ mlundinse - You're right. I allowed my enthusiasm to overcome good sense. Thinking about it, I'm not sure the R Pi gcc toolchain will generate barebones arm-none-eabi program files either. I am slightly less worried about the startup and libraries than I am calling conventions (ABI), linker scripts, static linking, ... I vaguely remember reading through an enormous number of options in the documentation for gcc for generating ARM code, and almost anything looking 'possible'. I also very vaguely (more than 5 years) remember a mechanism where the name used to execute the compiler was used by the compiler itself to figure out what it was supposed to do. However, I am willing to believe that configuring the right set of options is less likely than winning the National Lottery. I am also willing to believe that it can't be done by any normal gcc for ARM and Linux. Thanks for keeping my feet on the ground :-) (PS - I am getting into Golang, and maybe Beagle Bone Black, so I'm unlikely to try) mlundinse on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-30956 Thu, 19 Sep 2013 15:57:49 +0000 mlundinse 30956@http://forums.leaflabs.com/ gbulmer - I am not sure that the R Pi gcc toolchain will generate barebones arm-none-eabi program files that is needed by the maple. It is configured to generate code to run under a Linux OS. The same assembler instructions but the default startup and library stuff are different. I have no idea how hard, or easy, it is to convince this toolchain to generate ode for barebones arm. Adam on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-30955 Thu, 19 Sep 2013 15:57:11 +0000 Adam 30955@http://forums.leaflabs.com/ ventosus, <blockquote> Error during download get_status Up-stream reports that this has been fixed already some months ago in dfu-util git. </blockquote> And so it is. I got the latest source and tried out it - no error message. ventosus on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-30824 Thu, 19 Sep 2013 01:33:55 +0000 ventosus 30824@http://forums.leaflabs.com/ Error during download get_status Up-stream reports that this has been fixed already some months ago in dfu-util git. Adam on "Inofficial libmaple F3-port" http://forums.leaflabs.com/topic.php?id=11883#post-30740 Wed, 18 Sep 2013 13:18:33 +0000 Adam 30740@http://forums.leaflabs.com/ ventosus, Thank you! I rebuilt using the orone_mini_F3 target and it works! gbulmer, Thank you for the Orone-mini - great board design! I'm going to try some performance tests today and tomorrow. I'll report back.