CLOSED, FOCUS GOES TO HAL BASED CORES - Improving F4 core (libmaple based)

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Sun Apr 23, 2017 10:56 am

Can somebody check whether the Serial (not the SerialUSB) works above 115k2?
Tried with 460k and 920k speeds with no luck.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1599
Joined: Mon Apr 27, 2015 12:12 pm

Re: Improving F4 core (libmaple based)

Post by victor_pv » Mon Apr 24, 2017 4:46 am

I have uploaded my core to github and updated the 1st post in the thread with the link and some more information.
If someone has a board with a valid USB, please test and let me know if USB works.

User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Mon Apr 24, 2017 8:55 am

My first test: w/ ag123's Whetstone with Serial (no USBSerial), Black 407ZET board
1. downloaded victor's Updated_STM32F4_master
2. used Generic STM32F407V Series
3. used HardFPU w/ hard calls
4. compiled and flashed - no go - nothing in terminal..
The version with old Discovery works.

PS:I removed the pin manipulation with LEDs in ag123's Whetstone
While debugging it crashes into reservedexception9 at:

Code: Select all

*  @param buf  Buffer to store items into
 */
static inline void rb_init(ring_buffer *rb, uint16 size, uint8 *buf) {
    rb->head = 0;
    rb->tail = 0;
    rb->size = size - 1;
    rb->buf = buf;
}
Do you use a different linker script for serial buffer in CCM??
Last edited by Pito on Mon Apr 24, 2017 9:42 am, edited 3 times in total.
Pukao Hats Cleaning Services Ltd.

ag123
Posts: 711
Joined: Thu Jul 21, 2016 4:24 pm

Re: Improving F4 core (libmaple based)

Post by ag123 » Mon Apr 24, 2017 8:58 am

try SerialUSB instead? :D

User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Mon Apr 24, 2017 9:15 am

With SerialUSB:
-Os, -g, eabi-4.8.3-2014q1, HardFPU w/ hard, Generic STM32F4V Series, 168MHz clock

Code: Select all

Beginning Whetstone benchmark at 168 MHz ...

Loops:1000, Iterations:10, Duration:8592.81 millisec
C Converted Single Precision Whetstones:116.38 mflops
Based on the result the CCM is in action, but Serial crashes.
Serial no go yet..
PS: enabling the blinking pins costs 1 mflops :)
Last edited by Pito on Mon Apr 24, 2017 11:37 am, edited 3 times in total.
Pukao Hats Cleaning Services Ltd.

User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Mon Apr 24, 2017 9:48 am

Tried with my Blink407 test: get compile errors as the PF9 and PF10 are not defined. The old Discovery variant worked.
It is ok, as the new Generic 407V does not posses such pins. We need the Z variant for that then..
Pukao Hats Cleaning Services Ltd.

User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Mon Apr 24, 2017 10:45 am

With the following Overclock settings in generic_f407v.h and the other settings as above:

Code: Select all

#define CYCLES_PER_MICROSECOND  240    // F_CPU in MHz
// Note: Xtal frequency 8MHz
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 4      // Xtal divider
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 240    // PLL_Freq multiplier, PLL_Freq = Xtal / PLL_M * PLL_N
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2      // PLL_Freq post divider, F_CPU = PLL_Freq / PLL_P
#endif
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 10     // USB divider = PLL_Freq / 48
#endif
..

Code: Select all

Beginning Whetstone benchmark at 240 MHz ...

Loops:1000, Iterations:10, Duration:6010.35 millisec
C Converted Single Precision Whetstones:166.38 mflops
To see ".. at 240 MHz" you have to change the f_cpu setting in boards.txt as well..

PS: I would recommend to change the order of PLL coefs to the natural clock settings chart order from left to right - M, N, P, Q . You may also add the above explanation for easier handling.

Code: Select all

#define CYCLES_PER_MICROSECOND  168    // F_CPU in MHz
// Note: Xtal frequency 8MHz
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 8      // Xtal divider
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 336    // PLL_Freq multiplier, PLL_Freq = Xtal / PLL_M * PLL_N
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2      // PLL_Freq post divider, F_CPU = PLL_Freq / PLL_P
#endif
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 7      // USB divider = PLL_Freq / 48
#endif
..
PPS: Also you may remove the weird

Code: Select all

// PLL config for 25 MHz external crystal --> 120 MHz SYSCLK, with
// 48 MHz PLL48CK.
#ifndef BOARD_PLL_Q
#define BOARD_PLL_Q 5
#endif
#ifndef BOARD_PLL_P
#define BOARD_PLL_P 2
#endif
#ifndef BOARD_PLL_N
#define BOARD_PLL_N 240
#endif
#ifndef BOARD_PLL_M
#define BOARD_PLL_M 25
#endif
from boards_setup.cpp
Last edited by Pito on Mon Apr 24, 2017 11:42 am, edited 13 times in total.
Pukao Hats Cleaning Services Ltd.

ag123
Posts: 711
Joined: Thu Jul 21, 2016 4:24 pm

Re: Improving F4 core (libmaple based)

Post by ag123 » Mon Apr 24, 2017 10:56 am

a little surprising as the blinking pins is outside the timing loop :lol:
overclock did give a nice boost of some 50% it seemed, but the mflops seem a little lower than is possible
http://www.stm32duino.com/viewtopic.php ... 150#p26867
perhaps it is due to the SerialUSB interrupts

User avatar
Pito
Posts: 1497
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Improving F4 core (libmaple based)

Post by Pito » Mon Apr 24, 2017 11:07 am

The overclock with Serial and old Discovery was 143, now it is 166 with new victor's one core and USBSerial..
With Serial it could be higher, but Serial does not work here yet..
Pukao Hats Cleaning Services Ltd.

stevestrong
Posts: 1502
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Improving F4 core (libmaple based)

Post by stevestrong » Mon Apr 24, 2017 11:55 am

My current / future plans:

- I will test USB serial with Victor's new core.
- I will test Hardware serial (Serialx, x>=1) with speeds 115kbps and above - as Pito reported that it did not work.
- I am currently evaluating the GPIOs by driving a 16 bit parallel display - already detected some bugs.
- Next step will be the FSMC as it is the next logical step for driving parallel data bus displays - will do it instead of Pito, if it is OK.

EDIT
A question:
- what is the reason behind naming some core/system files to *_f4.*? The whole directory is anyway relevant only for F4, so it seems superfluous.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests