[libmaple] Black F407VET6

in the early thread about Black F407{V,Z}ET6
http://www.stm32duino.com/viewtopic.php?f=3&t=1941

it is noted that the on board SPI flash may possibly be wired to a SPI1 port, the spi flash is suspected to be patched to PB3 SPI1_SCK, PB4 SPI1_MISO, PB5 SPI1_MOSI. however, SPI1 and SPI3 shares this port, hence, we could possibly configure SPI3 on PB3-PB5 if indeed the spi flash is hardwired to this port. the spi flash cs is pulled up to 3.3v, making it not possible to ‘switch off’ this in software

as noted in the early thread the schematics:
for VET6 the leds are on PA6 and PA7
http://wiki.stm32duino.com/images/5/5c/ … EMATIC.PDF
while on ZET6 the leds are on PF9 and PF10
http://wiki.stm32duino.com/images/4/4f/ … _sch-1.pdf

we’d then need to find another place to configure SPI1 on

i think F4 has hardware support for SDIO, but we could leave that as an ‘enhancement’ as we could literally try to use the hardware sdio for this, then transfers may reach those >10MBps speeds, i think SDIO needs more pins than just 4 for SPI

First step is to compile the SPIx.. It does not compile yet. Then we may play with wirings..
On ZET6 the flash /CS is pulled via 10k to Vcc and driven by PB14. Mind the /CS is usually active low with memory devices. Wiring /CS high will disable the chip.
You can wire many devices to an SPI provided their /CSelects are different.

ag123 wrote:
we’d then need to find another place to configure SPI1 on

Pito wrote:First step is to compile the SPIx.. It does not compile yet. Then we may play with wirings..
On ZET6 the flash /CS is pulled via 10k to Vcc and driven by PB14. Mind the /CS is usually active low with memory devices. Wiring /CS high will disable the chip.
You can wire many devices to an SPI provided their /CSelects are different.

Here is the VET6 schematics – PB0 drives the /CS (F_CS signal) of the flash while it is pulled by 10k high.
http://www.stm32duino.com/viewtopic.php … 391#p17878

now this board would make a nice clock and it can change the background image every hour if u’d like

flash /cs – they renamed the signal, F_CS and its on ZET PB14, VET PB0

stephen

Meanwhile I did a comprehensive clean-up of the F4 project.

As I think the scope of this thread has been reached (blinky works :mrgreen: ), further software developments can be continued in this other thread from victor.

Intermediate results can be still posted here, if necessary.

no doubt in the wrong place replacement thread is lib_maple specific?

this is the exported files and reports of my srp4.ioc for the Black STM407VE

i believe it is fairly complete and matches the schematic, only issue is i don’t know how to handle PB3.
it’s TDO and also what they label as SPI1_SCK (actually spi3 alternate)
I2C2 is available.

stephen

stephen, thanks but honestly, I don’t know what to do with this ioc file.
it is a nice pdf doc as well, but I still cannot see how this should easy our life in this libmaple-based F4 structure.
As I said, I already re-worked some files, the pin mapping is also a bit clarified.
Maybe at a later point I will realize why this will be usable.

hi stephen,

thanks for posting that, the pdf is in effect a pin mapping?
there is a little discussion in the st core http://www.stm32duino.com/viewtopic.php … 256#p26256
about the pin conflicts for PB3-PB5
and danieleff has posted his point of view
http://www.stm32duino.com/viewtopic.php … =10#p26147

in the schematic
http://wiki.stm32duino.com/images/5/5c/ … EMATIC.PDF
PB3-PB5 SPI1_SCK, SPI1_MISO, SPI1_MOSI is shared by the onboard spi flash and the NRF24 connector (hence the SPI1 header is in the NRF24 connector)
PB6, PB7 I2C1_CLK and I2C1_SDA is also routed to the NRF24 connector to NRF_CE or NRF_CS (hence I2C1 can be found in the NRF24 connector as well)

if we take a look at the NRF24 specs NRF_CS is SPI chip select and NRF_CE is chip enable activates RX or TX mode
https://www.nordicsemi.com/chi/content/ … n_v2_0.pdf
hence PB6, PB7 would need to be GPIO pins if a NRF24 is actually used

we could select another sets of pins for I2C (e.g. PB10 i2C2_SCL, BP11 i2C2_SDA) and yet another for UART (e.g. PA8 USART1_CK / PA9 USART1_TX, PA10_USART_RX) as there are a large number of pins that’s broken out on the STM32F407{V,Z}E_black boards

and for the analog pins we could possibly simply select PA1-PA6 as their arduino counterparts

@:ag123
you need to use/view the CubeMX ioc file.

there is not a problem sharing the clock and data lines on SPI, interfaces. I am pretty sure if you took/read the SPI1 labels as SPI3, then it makes sense. Even the cpu pin label lists SPI3 Actually if they labelled I2C2 as I2C1, it would still be just an I2C interface.

i’m confused with PB3 as it’s TDO & also the SCK, it’s also a JTAG socket pin. it maybe that the start up sets the debug as SWD releasing all debug pins bar SWD_CLK & SWD_DAT.

Additionally I’ve got the FSMC and SDIO peripherals mapped without conflicts. I had to play with CubeMX and do quite a lot getting the FSMC mapped, mainly configuring alternates. To me that suggests the layout is pretty much as it was originally designed.
i
Those alternates will need to be seto uo as a board variant, either in the sketch or in the core, i’ve seen use of alternates in a post using lib maple.

stephen

New Black F407VET6 variant added to F4 boards in my repo Black F4 variant branch.
Also sent a PR for Roger.

thanks stephen,
as for PB3
while i’m not too familar with Jtag, PB3 is JTDO/ TRACESWO/SPI3_SCK / I2S3_CK /TIM2_CH2 / SPI1_SCK/EVENTOUT
if i understand it correctly SWO is mainly used with SWD for the board to send messages to the host pretty much like a serial console (i.e. print statements)
while SWD debug mainly uses 3 pins PA13 SWDIO, PA14 SWCLK and a ground pin

if we could make do with SWD debug with just 3 pins, it means we’d not have conflict with PB3
and if need be for various circumstances we could probably use usb-serial or a uart to send console messages (print statements) back to the host

agreed with the SPI3 assignments in PB3-PB5 (i.e. the default SPI port for arduino) as well as it seemed it may help to reduce some conflicts, otherwise the alternative to map SPI is to use PA5-PA7 as SPI1 and we could use that as a default spi port for arduino, just that it’d overlap some of the analog pins (if we define PA1-PA6 as arduino analog pins)

Hi all,

I’ve been doing some work to see if we can harmonize the Black F4VET6 boards across all the code streams. We’ve got the new STM32duino F4 branch happening, DanielEff has his GenericSTM32 code, and Avik’s Koduino is going strong.

I’ve just updated my repo with a bunch of updated info for the Black F4VET6 (STM32duino) – including a pin allocation rationale (discussed with Daniel and others) and some AF mappings that seem to make sense. The rationale is in the excel spreadsheet in the /documents folder.

The only change on the schematic is that it seems better to map the NRF/flash SPI to SPI3 instead of SPI1, to allow SPI1 to be available with a full set of NSS pinse for SPI-DMA.

The repo’s at https://github.com/palmerr23/Black-F407VET6-cube and is built against the STM32duino “cube” F4 code base.

Happy to hear if there is a better layout / AF mapping available, but also keen for us to tie something down ASAP for this board.

Richard

I have made the following pin defines for black F4:
// Pins reserved for the on-board hardware
#define FLASH_CS_PIN PB0
#define FLASH_CLK_PIN BOARD_SPI3_SCK_PIN // PB3
#define FLASH_DO_PIN BOARD_SPI3_MISO_PIN // PB4
#define FLASH_DI_PIN BOARD_SPI3_MOSI_PIN // PB5

#define NRF24_CLK_PIN BOARD_SPI3_SCK_PIN // PB3
#define NRF24_DO_PIN BOARD_SPI3_MISO_PIN // PB4
#define NRF24_DI_PIN BOARD_SPI3_MOSI_PIN // PB5
#define NRF24_CE_PIN PB6
#define NRF24_CS_PIN PB7
#define NRF24_IRQ_PIN PB8

// SD card, SDIO mode
#define SD_DAT0 BOARD_SDIO_D0 // PC8
#define SD_DAT1 BOARD_SDIO_D1 // PC9
#define SD_DAT2 BOARD_SDIO_D2 // PC10
#define SD_DAT3 BOARD_SDIO_D3 // PC11
#define SD_CLK BOARD_SDIO_CK // PC12
#define SD_CMD BOARD_SDIO_CMD // PD2
// SD card, SPI mode, only usable with software SPI
#define SD_DI BOARD_SDIO_CMD // PD2
#define SD_DO BOARD_SDIO_D0 // PC8
#define SD_CS BOARD_SDIO_D3 // PC11
#define SD_SCLK BOARD_SDIO_CK // PC12

Steve,

That matches with my reading of the correct pinouts.

I’ll have to trust your judgement on the SPI-SDIO allocations as it’s outside my experience!

I’m working on a pinout diagram today as requested in earlier the thread.

Richard

That board don’t need any bootloader? I didn’t found any consistent answer.

What repo should I use for this board? I just got it.

steve,
the hardware is not mapped as you would perhaps expect, the CubeMX allows each interface to be re-mapped and to where / wanted as long as the actually pin is capable of performing the function e.g. miso or i2c sda.
you can modify the ‘spi1 interface’ to actually use the spi3 pins, i2c1 is moved as well, CubeMX generates code as it is told to.
you need to see the distinction made between the cpu datasheet pins names/description and ‘how and where’ they map to the actual hardware.
the easiest way to see the mapping is to use CubeMX and the ioc file for the variant. actually that’s how learnt CubeMX albeit lightly.
i’m working towards bare metal using hal and compiling for myself, a long if i take it slow curve, so not as steep as it could be if i wasn’t retired
sorry it’s badly explained.

stephen

>That board don’t need any bootloader? I didn’t found any consistent answer.
My Board had no boot loader. I used it with a ST-Link-V2

>What repo should I use for this board? I just got it.
I use the STM32GENERIC and I’ve made examples for it.