Another interesting Discovery kit from ST

[Giovanni]

Adding an option to *not* save FPU registers is definitely a good idea.

I am discovering more and more thing I like on the F4, for example there is a CCM (Core Coupled Memory) 64KB RAM unaffected by DMA activity, I will move the RTOS structures there in order to have optimal performance even when several DMAs are hammering the normal RAM.

About that board, we could do that but better not rush it because the pipeline is already filled right now (finish F4 and F2, then 1769 and NiosII support). I think you can do it and then send the board files for inclusion (basically any pin connected to the FPGA has to be input with pull-up after reset, probably most of them are connected this way).

Giovanni

[Jacon]

He,he - Giovanni leaves nothing serious for users to do...

Just started check of new trunk for application of CCM, to ask Author for use that exceptional idea
- and voila, mentioned in post above

[Jacon]

The STM32F4-Discovery demo just reached the led-blinking capability level

Mine board seems to be in the same condition right now
(Must prepare baseboard with proper interfaces this Tuesday...)

Excellent final of the weekend, Giovanni

[Giovanni]

I hope you are enjoying as much as me, divided between my nephews, my poor attempts at learning guitar and programming this thing

Giovanni

[Jacon]

Definitely - especially I share only last 1/3 of your a.m. duties now

Jacek

[zuh]

First off, being new here, thanks for ChibiOS, it's a pleasure to work with

I have a F4 Discovery board here as well, and am looking forward to tinker with it. So far so good, the obligatory LED blinking works as expected and after getting the wiring right on the 4th attempt also printing over serial.

GPIO input, I2C and PWM would be my next steps to get working so you'll for sure get some testing for those as soon as the support lands in case they are not there already (hint hint )

One nitpick to mention, I noticed the demo is in a directory named "ARMCM3-STM32F407-DISCOVERY" which labels the F4xx as Cortex-M3 rather than M4. Something you might want to fix to avoid confusion...

Also a question about the PAL_MODE_ALTERNATE(n) macro, I'm uncertain about how to get that 'n' mapped wrt the alternate functions of the pins. Is there somewhere a clear table of that, I could not find a logic between the API and the MCU pin description table in the F4 User Manual?

[Giovanni]

Hi,

The various device drivers will be tested and validated for the F4 soon, I think the PWM is one of those requiring no changes so you could just give it a try (add it to the platform.mk file). Barthess should test the I2C on the F4 soon, he is waiting for the chip.

PAL_MODE_ALTERNATE(n) just sets the pin "n" as alternate in the MODER register, the macro PIN_AFIO_AF(n, v) selects the function "v" for the pin "n" in the AFRx registers. For the alternate parameter you should look at the Datasheet (not the Reference Manual). Look at table 6, the column number is the number that PIN_AFIO_AF(n, v) expects as "v" for the pin "n". Each pin can have up to 16 alternate functions, that number selects one function.

Fixed the name problem on the repository, thanks.

Giovanni

[mabl]

texane/stlink now includes fixes for the STM32F4 discovery board. Got the current ChibiOS blink LED demo up and running under Linux - and it was so easy, just 5 minutes tops

[Giovanni]

Good to know, I hope he will make a Windows version too.

Giovanni

[Giovanni]

Few notes,

PAL, Serial, GPT and SPI drivers have been validated. The IRQ_STORM test also ran without problems except... it is unable to saturate this beastly thing, I can't believe it, it is a test designed to saturate a system until a total lock.

Code: Select all

*** ChibiOS/RT IRQ-STORM long duration test
***
*** Kernel:       2.3.4unstable
*** Compiled:     Nov 15 2011 - 20:19:32
*** Compiler:     GCC 4.6.0
*** Architecture: ARMv7-ME
*** Core Variant: Cortex-M4
*** Port Info:    Advanced kernel mode
*** Platform:     STM32F4 High Performance & DSP
*** Test Board:   ST STM32F4-Discovery
***
*** System Clock: 168000000
*** Iterations:   100
*** Randomize:    0
*** Threads:      4
*** Mailbox size: 4

Iteration 1
...............................................
Saturated at 0 uS


The damn thing simply refuses to die, I'll have to make the test even more severe.

Another note, I've been able to debug using the ST-Link under Eclipse using the GDB Server taken from the Atollic toolchain, useful for those of us who hate pre-built environments. I'll write a guide about this.

Edit:

After changing the test to measure rates down to 10uS (which means an interrupt every 5uS average in that test) this is the result:

Code: Select all

*** ChibiOS/RT IRQ-STORM long duration test
***
*** Kernel:       2.3.4unstable
*** Compiled:     Nov 15 2011 - 20:44:57
*** Compiler:     GCC 4.6.0
*** Architecture: ARMv7-ME
*** Core Variant: Cortex-M4
*** Port Info:    Advanced kernel mode
*** Platform:     STM32F4 High Performance & DSP
*** Test Board:   ST STM32F4-Discovery
***
*** System Clock: 168000000
*** Iterations:   100
*** Randomize:    0
*** Threads:      4
*** Mailbox size: 4

Iteration 1
.....................................................###
Saturated at 12 uS


Giovanni