BLACK_F407ZET6 support

[uzi18]

Hi @fpistm
I want to add this board as PR, do You think it is enough to copy BLACK_F407VE and modify a little?
I think big difference is number of IOs.
On the market it is possible also to buy BLACK_F407ZG module (1MB of flash).

[fpistm]

Hi @uzi18
yes this could be enough.
making a diff btw PeripheralPins.c only some pins added:
https://github.com/stm32duino/Arduino_Tools/blob/master/src/genpinmap/Arduino/STM32F407V(E-G)Tx/PeripheralPins.c
https://github.com/stm32duino/Arduino_Tools/blob/master/src/genpinmap/Arduino/STM32F407Z(E-G)Tx/PeripheralPins.c

If the pin mapping is nearly the same, the variant could be updated using board define as differentiator.
I've made it for L496 and L496-P. Same for ldscript.

Arduino_Core_STM32/variants/NUCLEO_L496ZG/PeripheralPins.c

Line 111 in 7b48eff

#ifdef ARDUINO_NUCLEO_L496ZG

[uzi18]

thx, will check this out

[uzi18]

@fpistm ok looks like difference is very small but for STM32F407V(E-G)Tx/PeripherialPins.c vs variant Black_V407VG some lines are commented out, do you know why?

[fpistm]

Yes, this is commented in the header:

• Note: Commented lines are alternative possibilities which are not used per default.

•   If you change them, you will have to know what you do
  

To sum up, only one pin config is available. If you do not comment duplicated pins only the first occurence is used so second is never used and consume some space for nothing.

[BennehBoy]

@fpistm I have 2 of these boards on order so started to look at building a variant.

Although PeripheralPins.c could easily be done with defines, the actual pin layout on the board is very different to the BLACK407VET6.

The Variant.cpp file for BLACK407VET6 is laid out to represent the physical pin layout, accommodating the ZET6 here would necessitate either a) removing the physical layout altogether, or b) have a large ifdef section for each board.

Do you think it best to do one of the above, or break the ZET6 out into it's own unique variant folder?

[uzi18]

docs are here: https://github.com/mcauser/BLACK_F407ZE
BLACK_F407ZG is also available
in facts cpu is simmilar, but hardware onboard is different

[BennehBoy]

@uzi18 thanks - I think I have the hardware covered, my question is more about what is best practice for variants in STM core. The ZGT board looks identical other than the MCU used (with double the flash), so it ought to be pretty easy to include a variant.

[fpistm]

Do you think it best to do one of the above, or break the ZET6 out into it's own unique variant folder?

There is no specific rules. If thanks a switch it's simple to support it then update the current variant.
Else if too much diff a new variant can be created.

[uzi18]

@fpistm do you think it is possible to work with integrated sdcard slot, is sdio supported?

[fpistm]

Yes SDIO is supported thanks STM32SD and FatFs library. Works on Black F407VE.

[uzi18]

wow did not find any reference to STM32SD library, if also SPI will work, I will try W5500 ethernet ;)

[BennehBoy]

Yes SDIO is supported thanks STM32SD and FatFs library. Works on Black F407VE.

I've tested this.

SPI works just fine on the 407VET6, so no reason to think it won't on this.

I think for the sake of simplicity I'll remove the 'physical layout of the 407VET6, that way one variant should suffice for VET6/ZET6/ZGT6.

[uzi18]

It could be nice solution.
For fatfs did not find where to put files for STM32SD lib, it should be git submodule or something like that.

[fpistm]

@uzi18 those are libraries avalable thanks arduino library manager.
https://github.com/stm32duino/FatFs
https://github.com/stm32duino/STM32SD

@BennehBoy we talk about SD via SDIO not SPI ;)

[uzi18]

Have used to git clone libs, not manager itself ;)
I need also SPI for cheap W5500 ethernet module or maybe there is better alternative?

[BennehBoy]

@BennehBoy we talk about SD via SDIO not SPI ;)

Yes, I've had both working. SDIO using STM32SD, & SD via SPI using SdFat.

[BennehBoy]

@uzi18 I've created a PR to add support if you are able to test.

[uzi18]

Arduino_Core_STM32/system/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h:183:81: fatal error: core_cm4.h: No such file or directory
 #include "core_cm4.h"             /* Cortex-M4 processor and core peripherals */

can't find core_cm4.h

[BennehBoy]

What sketch are you using for the test?

[fpistm]

@BennehBoy
I've done a PR on your fork about Flash size management. Let me know what you think.

@uzi18 I guess you have a misalignment in your install. core_cm4.h is provided by the CMSIS package.

[BennehBoy]

@fpistm seen and commented.

[uzi18]

@fpistm You are right, it is impossible to build directly from git repo, so need to prepare fake core deploy dir, is there another way for test?

[BennehBoy]

See here -> https://github.com/stm32duino/wiki/wiki/Using-git-repository

It explains how to use the git repo instead of the boards manager version (you must first have the boards manager version installed though). I copy my old 1.4.0 folder off first so I can swap it back in if I want to just test against 1.4.0 release... essentially when you clone this repo you will rename the folder to 1.4.0

Once you've done that, and have git tools installed, you can do the following:

git config --global --add alias.pr '!f() { git fetch -fu ${2:-origin} refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f'

Which means you can issue a command:
git pr 393

git might complain though because you have to modify boards.txt and it will say those changes would be lost, in which case do 'git stash' then retry the above.

Which will download this pr, create a branch called 393, and switch to it.

You can also add this to remove any pr's when done:

git config --global --add alias.pr-clean '!git checkout master ; git for-each-ref refs/heads/pr/* --format="%(refname)" | while read ref ; do branch=${ref#refs/heads/} ; git branch -D $branch ; done'

[uzi18]

have checked out pr 393 but didn't know that some other dirs are also needed
will just symlink other stuff from original

I think git submodules shoud do the job here

[BennehBoy]

Better to just clone the entire repo and follow the instructions imho.

[BennehBoy]

My board is on the slow boat from China so it would be good to see some test results :)

[fpistm]

No gitsubmodule is not the right approach. The simpliest way is to clone the repo as described in the wiki then get the PR.

[uzi18]

@fpistm my idea is to have STM32 repo with core,cmsis tools etc. as submodules inside, so you can fetch everything related with one command line
OK I'm trying to prepare now

[fpistm]

Oh ok up to you ;)
There are several way to use git :)

[uzi18]

building process works fine, now question, Serial object is mapped to Serial1 or SerialUSB?

[fpistm]

By default Serial is mapped on Serial1 for this PR.
I will provide a way to map Serial on SerialUSB soon.
Anyway, it is possible to define it.
For example select no Serial in the menu then on top of your sketch #define Serial SerialUSB would work.
or define it in the variant.h thne HardwareSerail will not define it as already define or using build_opt.h.

[uzi18]

ok I see, it is not possible to choose any options for USB cdc, when you plan to merge #388 ?

[BennehBoy]

Simplest way would be to....

copy the relevant section from boards.txt in this pr

# Black F407Z(E-G)
# Support: Serial1 (USART1 on PA10, PA9)
# Default SPI: SPI (SPI1 on PB3,PB4,PB5 - NRF24 connector and W25Q16 (on board flash))
GenF4.menu.pnum.BLACK_F407ZE=Black F407Z(E-G)
GenF4.menu.pnum.BLACK_F407ZE.upload.maximum_data_size=131072
GenF4.menu.pnum.BLACK_F407ZE.build.mcu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
GenF4.menu.pnum.BLACK_F407ZE.build.board=BLACK_F407ZE_G
GenF4.menu.pnum.BLACK_F407ZE.build.series=STM32F4xx
GenF4.menu.pnum.BLACK_F407ZE.build.product_line=STM32F407xx
GenF4.menu.pnum.BLACK_F407ZE.build.variant=BLACK_F407VE
GenF4.menu.pnum.BLACK_F407ZE.build.cmsis_lib_gcc=arm_cortexM4l_math

GenF4.menu.flash.ZE=ZE 512k (default)
GenF4.menu.flash.ZE.upload.maximum_size=524288
GenF4.menu.flash.ZE.build.ldscript=ldscript.ld
GenF4.menu.flash.ZG=ZG 1024k
GenF4.menu.flash.ZG.upload.maximum_size=1048576
GenF4.menu.flash.ZG.build.ldscript=ldscript_zg.ld

Make a copy of the black407VE variant folder

git pr-clean

git pr 388

copy the above saved black407VE folder over the top of the one that pr388 just updated

add the saved boards.txt items in (see the code snippet above).

This will manually merge my PR into #388 on your local working dir.

[uzi18]

Can wait for usb support, just asking.
Need now to connect TTL converter to J5 onboard to see if test program work ok.

[uzi18]

@fpistm @BennehBoy ok for now simple blink on LED_BUILTIN does not work for me.
... Serial.begin/print also
what to check now? startup configuration?

[BennehBoy]

Hmm, I would try referencing the LED pins directly rather than LED_BUILTIN

They should be on: PF_10 & PF_9

Could be that the arduino numeric pin mappings for the pins are not correct - I couldn't find a schematic with them marked (such as this for VET6 -> http://wiki.stm32duino.com/images/3/3e/Black_STM32f4VET6_Pinouts_Left.pdf)

I actually used the Ver2 of those schematics which simply had the numeric numbering running consecutively as the pins progressed downwards - clearly incorrectly.

I'll do some digging - if you have a similar schematic for ZE then please share.

[uzi18]

here you are: https://github.com/mcauser/BLACK_F407ZE/blob/master/docs/STM32F407ZET6_schematics.pdf

for me pin numbering looks ok (except D1/D2/D3 - D3 - is directly 3v3 powered), will check this one more time

[uzi18]

@BennehBoy no change, now will check clock configuration etc...

clocks looks ok

[BennehBoy]

D1 should start at PB12, ignore the top 4 pins which are power and ground.

[BennehBoy]

OK I've found an error in Variant.h

I'll fix and commit.

[BennehBoy]

Done, if you grab the PR again and restest that would be great.

[uzi18]

@BennehBoy now is wrong with number of analogs ...
_Static_assert(NUM_ANALOG_INPUTS <= MAX_ANALOG_INPUTS,
_Static_assert(NUM_ANALOG_FIRST >= NUM_ANALOG_INPUTS,
_Static_assert(NUM_ANALOG_FIRST >= NUM_ANALOG_INPUTS,

[BennehBoy]

It compiles fine for me.... where are you seeing that?
EDIT - and passed the Travis build test.

[BennehBoy]

From Variant.h

// This must be a literal
#define NUM_DIGITAL_PINS        129
// This must be a literal with a value less than or equal to MAX_ANALOG_INPUTS
#define NUM_ANALOG_INPUTS       19
#define NUM_ANALOG_FIRST        110

[uzi18]

ok after make clean, all build, but D2/D1 still does not blink checked with PF9 and PF_9 and PF10 and PF_10

[fpistm]

When you told D2/D1 you talk about LED not pin numbers? Correct syntax is PF9 or PF10.

[uzi18]

@fpistm yes, but it does not work either

[BennehBoy]

I've double checked and it all looks correct according to the schematic - maybe needs another set of eyes to spot if there's a glaring mistake.

[BennehBoy]

I've looked at the STM32GENERIC definition and it has the LED's on the same pins.

The MicroPython config that you linked is contradictory, it has the LEDS on PA6 & PA7 in the pins.csv file, but PF9 & PF10 in the mpconfigboard.h

My board arrival eta is ~ 2 weeks away :/

[uzi18]

@BennehBoy stm32generic works for me with these leds, tested months before.
Also checked sources with schematics and for me it is ok.

[BennehBoy]

Just an update to note that @uzi18 has confirmed that PR #402 does indeed work, the issue encountered was a local toolchain one.

[fpistm]

Close this one as #402 merged

[uzi18]

I still need to test I2C and timers.

[uzi18]

@fpistm so can now test new USB CDC implementation?

[fpistm]

yes

[BennehBoy]

I'd be very surprised if i2c does not work, but please do test