F4 hardware driver – can’t make hardware talk to pins!

I’m working up an F4 Board (Black STM32F4VET6 on the Wiki).

I’ve got software I2c working fine on both F1 and F4.
I’ve got HWire working fine on the F1, but it breaks on the F4.

There is the SDA/SCL pins remain high, on the logic analyser, when the code runs for the hardware /F4.

HWire times out (I’ve changed the default setting, 0 [never time out] to 10000 [10 seconds] on the first EndTransmission() call.
It hangs on the second call to EndTransmission() – lost somewhere in the middle of i2c_master_xfer().

The only thing that changes in the registers after the first EndTransmission call is CR1 becomes 101 (i.e. the Start bit is set).

Any clues?

—————————————-
12C1 is mapped to PortB6 and 7
I’m using my standard I2C test module: a MAG3110 with pullups to VCC.

Board and library reference code is on my github https://github.com/palmerr23/STM32F407

The core code is simple:
#include <HardWire.h>
HardWire HWire(1, 0); // I2C1, normal speed

void setup() {
HWire.begin();
}

loop() {
for (address = 1; address < 127; address++) {
<sample PortB and I2C1 registers>
HWire.beginTransmission(address);
status = HWire.endTransmission();

}
}


while i’m pretty much a novice in this as well, i found a web which i’m not too sure if it helps
http://www.emcu.it/STM32/STM32VLDiscove … brary.html

some of the pointers are like
Initialize the peripheral structure . e.g. enable spi, gpio etc

Don’t forget to clock the peripherals.
i think F4 has quite a few more peripheral buses than do the F1, could it be the particular bus is not clocked?

hope it helps

if i recall, you’re using HAL.
i too have those black 407’s, both of them, also displays advertised as ‘compatible’

is there an example of ‘just??’ I2C F4 code, if so what does that do in terms of clocks, alternate bit controls, registers etc
those that are probably not named as per STM32F1 ?
is one not quite what you’re thinking it is compared to STM32F1 ?
no doubt sillies, a bit flag not in the same place and mask maybe wrong ?
SCL and SDA work in pure gpio mode ?

stephen

Stephen,

Limited “HAL” – Maple code as core, with HardWire on WireBase on I2C libs.

I’m slowly checking through all the things you mentioned. Currently reviewing Martin’s RCC settings to see if the clock tree is right for I2C.

I’m going to try the new STM32F4 core published on Saturday and will contribute to that if it is practical, rather than persevering on the much-modified Maple core.

Thanks for your advice.

RIchard

i’ve a rather odd suggestion, if you happen to have an alternate development environment setup, e.g. eclipse (for myself i’m using eclipse + CDT itself + add on gnu arm eclipse http://gnuarmeclipse.github.io/) you may like to build a ‘sketch’ using ST’s standard peripheral library etc.if the ‘sketch’ works with ST’s standard peripheral library it probably suggest the problem is in the software rather than hardware, not sure if that helps. gnu arm eclipse actually include blinky project templates linking with the standard peripherals library, it may ease things a bit if you have that environment already setup

in a similar vein, could i add unicore-mx-examples and libopencm3-examples as they are wrappers to the SPI
each of them if you ‘git clone –recursive’ pull a particular instance of the unicore-mx and libopencm3 libraries.

the examples when built with those instances yield a bunch of mainly usb errors (usb is a wip)
removing those instances and pulling unicore-mx and libopencm3 into the examples directory structure alleviates most if not all.
i use a softlink to my home directory ‘master’

clone.sh is a wrapper so i can copy the github link, paste into terminal and pull it direct or into a directory

clone.sh & fetch_unicore-mx.sh are attached, libopencm3 is a straight edit, also rename to .sh and chmod it
target is my home directory.
clone.sh uses only the link with an optional directory – exits if git sees an existing directory

the fetch script executes ‘rm -rf ~/unicore-mx*

i further use a unicore-core template for my work, it has a much flattened directory structure as opposed to the original
there a number to be found on github
again in my f1 and f4 working directories i use a soft link to the library

stephen

Thanks guys,

I’m taking a slightly different approach that parallels the ones you suggest.

Instead of varying the development environment, initially, I’m looking at:

a) testing alternate libraries, to find one one that works and then trace the differences to find a fix. I’ve mostly borrowed other F1 peripheral libraries, which should be identical for the I2C component after all the GPIO mapping, clock and other matters are sorted out.

b) increasing insight into what’s going on in the MCU.

Sadly, b) is woefully inadequate in the base Arduino configs and using one of the IDEs that has more extensive debugging tools may well help. I may invest in a Black Magic Probe if I don’t get things sorted out soon. Logic analyser and Serial Monitor can only tell you so much about what’s going on!

If I don’t make progress quickly, I’ll drag down the STM32 plugins for Eclipse and try that. The attractiveness of Arduino is, of course, all the lovely, relatively portable and simple device libraries available!

Again, thanks for the ideas, it can get lonely and frustrating at the keyboard, faced with a piece of hardware that just won’t talk!

Richard

@palmerr
i just powered up my black_f407VET6, fresh.
i noted that the vendor installed a default sketch on the board basically blinking the 2 leds in the corner
(in the photo http://wiki.stm32duino.com/index.php?title=STM32F407 it is the 2 leds at the bottom left )
do you notice that initially? if it is chances are that it sort of say the board is ‘alive’

accordingly stm32f407vet6 actually has 2 usb ports, http://www.st.com/en/microcontrollers/stm32f407ve.html
one of them being a high speed / otg. it seemed the board only has this on the connector.
the other which is a full speed /otg port is not present with a connector. i remembered that for dfu-util installs, dfu enumerates/is present on this second port (on a different board) which is somewhat unfortunate. probably need to go with swd/jtag to work with the board
otherwise it would be possible to install a sketch or backup the flash simply using dfu-util

mine is connected via jtag, white/blue egg shaped st-link.
so i use
st-flash read out.bin 0x8000000 4096


i noted something that turns out to be a *surprise* for my STM32VET6 black board, the vendor installed blinky sketch/app *disable the jtag port*

i’m unable to program via the jtag port initially, and i thought i’ve got a bricked board. when i did openocd i got

GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-19:18)
Licensed under GNU GPL v2
For bug reports, read http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <tr
ansport>’.
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : clock speed 2000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Error: stm32f4x.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
…
Error: Could not initialize the debug port

i’ve had to resort to this “connect under reset” brute force approach to connect via jtag to the board
i found a link to the procedure described here
https://github.com/spark/firmware/issues/31

after i erased the first dozen sectors using “connect under reset” method am i able to restore normal openocd jtag connection

GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-19:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : clock speed 2000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020 (STMicroelectronics), part: 0x6413, ver: 0x0)

thereafter i flashed a blinky sketch / app that’s based on st hal – non-arduino

i found out in addition that STM32VET6-black vs STM32ZET6-black are wired differently on the board even though the photos looked similar in ebay etc

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

i’m attaching my binaries for vet6 and zet6 blnky just in case it helps (note: the zet6 blinky is not tested and simply compiled based on the schematics)

i was browsing the schematic, am i correct in thinking a few of the interface are actually mapped to alternates ?
also explains my posting about alternatives and how to
i.e. native i2c1 is on pb6/pb7 so

• nrf4 connector module i use v black vet6
  1 ce pb6 nrf_ce
  2 csn pb7 nrf_cs
  3 sck pb3 spi1_sck
  4 mosi pb5 spi1_mosi
  5 miso pb4 spi1_miso
  6 irq pb8 nrf_irq

  flash
  flash_cs f_cs pb0
  flash_do spi1_miso
  flash_di spi1_mosi pb5
  flash_ck spi1_sck pb3

  touch
  t_cs pb12
  t_sck pb13
  t_miso pb14
  t_mosi pb15

  leds vet v zet
  pa6 v pf9
  pa7 v pf10

  sdio seems the same
  sdio_d0 pc8
  sdio_d1 pc9
  sdio_d2 pc10
  sdio_d3 pc11
  sdio_sck pc12
  sdio_cmd pd2

the vet/zet schematics have some of the cpu connections in red as well, i’m wondering if its of significance.

connecting via my blue/white egg st link, i can read back using st-info and the leds stops, suggests a halted cpu,
so connect under reset?

stephen

it seemed to me the red highlighted pins are routed to the headers? nope, not just that, need further study

onboard spi flash seemed hard wired to spi1, cs on flash is pulled up to 3.3v
it seemed the same connectors that goes to spi flash and sdio are also routed to the headers (do you mean that to be ‘alternates’ ?) you might be right about it as those same pins likely have alternate functions

i’m not sure why in my case the jtag appear to be blocked, but those are the outputs i observed, perhaps st-link’s app did that “connect under reset”

on st link, i’m not arguing, just reporting / speculating
also speculating FLASH_CS i also name F_CS ? i thought the straight pullup strange as well

re altenatives, i2c1 is notionally taken by default as pb6 and pb7, these are used on the nrf24 connections CE & CS, also pb3, pb4 and pb5 are not notionally SPI1. i’d expect it as pa4.. pa7.
looking at the label on cpu pin 89, from the ds page 54 Table 6. STM32F40x pin and ball definitions (continued)
it’s described as NJRST/SPI3_MISO/TIM3_CH1/SPI1_MOSI/I2S3ext_SD/EVENTOUT
if its used as SPI1, that has to be an alternative if i understand correctly. off to p58 Table 8

remember those 103 boards with both nrf24 and esp8266 sockets, istr someone posting that i2c1 didn’t use the usually pb6/pb7, but had one mapped elsewhere, so it does happen. also when i started having interest in alternatives as i didn’t know how to use them.

could we dump the GPIO_AFxx control registers for alternatives using st-flash or openocd ? from the connect under reset ‘frozen’ device memory

rm0090 p287 8.4.9 onwards ?
table 39?
gpio_reg base is ? offset is given as 0x24 from where ??
p269 on

with
~/.arduino182r0$ grep -R -i base *|grep -i gpio|grep -i AFR


Folks,

You’ve been busy! A few contributions to the discussion, in no particular order, on the VET6 board.

Winbond flash being tied to PB3,4,5 suggests SPI1 OR SPI3 – as either can use these pins as long as hardware CS (NSS) isn’t used. PB14 is F_CS and the pullup is just a pullup! (It’s possibly in place so that the flash chip doesn’t respond to nRF commands if the driver (i.e PB14, PULLUP) is not initialised.)

I’d tend to go for SPI3, so that SPI1 is left for other libraries/user use (some libraries assume SPI1), particularly as the SDIO uses PC8-12 & PD2 killing the alternate SPI3_SCK mapping, and SPI1_SCK can still go to PA5.

Stephen’s noted that the nRF is wired to the same SPI pins as the Winbond (other than CS and IRQ) – this still allows either SPI1 or SPI3 to be used for these peripherals, as they share the interface.

Any thoughts about the SPI1 / SPI3 mapping? I think we should tie down a preferred assignment to save confusion for those that follow.

BTW, thanks for the VET6 Schematic, It has a few routings that I hadn’t yet traced. I’ll put it up on the Wiki.

re USB – I believe the OTG_FS is routed to the USB socket, rather than the HS, via PA11 & 12.

As to the Red vs Brown markings on the schematic, I can’t see any logic to them. I initially thought that they were dedicated system pins, but T_CS is red, so I’m inclined to think that they’re simply later edits in the “wrong” colour.

I’ll update my MX Cube config with all this and create a new branch on my repo for the updates.

Richard

thanks zmemw16, palmerr, i’m rather new to these things and thanks for sharing about the alternatives. e.g. i didn’t actually realise that SPI1 and SPI3 can be configured on the same pins e.g. to the on board spi flash. that may free up say spi1 which might be rather popular with libraries
the i2c (pb6, pb7) being routed to nrf is rather interesting as well as that nrf header may be used to plug nrf as well as things like accelerometers etc, i think i2c can have a chain of devices so long as the bus is properly done.

as to usb it is indicated on the schematic PA11/USB_DM and PA12/USB_DP, as you have noted this is probably routed the onboard usb connector
in the test described here, think it is confirmed for the vet6:
http://www.st.com/content/ccc/resource/ … 167594.pdf
page 19 (section 3.1) – set boot0 – pattern 1
then page 95 (section 25.1.1 STM32F40xxx/41xxx devices bootloader:
“DFU bootloader PA11: USB DM line, PA12: USB DP line – this is for the USB FS port”
i re-tested this by connecting the board after setting boot0 and in linux i’m seeing:
8002.450234] usb 3-4: new full-speed USB device number 59 using xhci_hcd
[58002.614936] usb 3-4: New USB device found, idVendor=0483, idProduct=df11
[58002.614939] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[58002.614941] usb 3-4: Product: STM32 BOOTLOADER
[58002.614943] usb 3-4: Manufacturer: STMicroelectronics
[58002.614944] usb 3-4: SerialNumber: 338334803335


@ag123
the i2c (pb6, pb7) being routed to nrf is rather interesting as well as that nrf header may be used to plug nrf
here comes the rain
pb6 & pb7 are used as gpio outputs to the nrf_cs and nrf_ce, addition the alternative set has pb8 used as nrf_irq input

slight sunshine
i2c2 on pb10 & pb11 is free

i’m working on a cubemx ioc that should as used for the Black VET, with labels (wip)
i’ll post it probably tomorrow.

stephen

Good work on the DFU port!

The option of a 100Mbps RMII Ethernet would add something – particularly as PHY modules are cheaply available, e.g. LAN8720 for $3.20 on ebay.

The NRF is SPI, rather than I2C, so separate /CS pins are required for sharing. For instance SPI1 (or SPI3 as an AF) is already shared with NRF and the onboard Flash memory.

BTW @ag123, I’ve lost track of which code implementation you’re using: Maple, Cube (new STM32duino) or Koduino?

Are you using the Arduino IDE or Eclipse, etc?

Richard

@palmerr wrote
The NRF is SPI, rather than I2C, so separate /CS pins are required for sharing. For instance SPI1 (or SPI3 as an AF) is already shared with NRF and the onboard Flash memory.
sharing the spi sck,miso & mosi signals with multiple devices and with separate control lines is fine, almost expected.
i’d be serious doubtful about i2c with the nrf24 control signals and vice versa. its just plain wrong.

stephen

Stephen,

If you’re saying that sharing pins between SPI and I2C, being “just plain wrong”, I heartily agree.

I don’t have any problem sharing other SPI devices with the NRF on SPI2, however.

Richard

richard,
its the thought of trying to use i2c1 bus protocols on the CE/CS control lines of the nrf24, to me as pb8 is also used with the nrf24 irq then it means i2c1 is effectively blocked even using its alternate.

attaching my current srp1.ioc
mainly its just adding labels and setting some gpio states.

stephen

Stephen,

Thanks, I’ll digest them.

Agreed on PB8. PB6 is always available as an alternate I2C1_SC to PB8, particularly as UART1_TX (ISP header) is allocated to PA9.

Any thoughts on the best Arduino Digital pin numbering arrangement (see previous post)? The Pinout Options spreadsheet view is a bit complex, but you can largely ignore everything that isn’t in the middle set of columns.

BTW: in xxx.ioc.txt – what are the Mcu.pinxx numbers – they don’t seem to equate with chip ins, or a logical numbering scheme?

SDIO.BusWide=SDIO_BUS_WIDE_1B
and
SDIO.WideMode=SDIO_BUS_WIDE_4B
seems odd.

Also your clock tree looks somewhat off. Mine is as in the f4-1.pdf in the gitub.

My HSE + PLL drives 168MHz Sysclk and leads to APB1 = 42MHz, etc.
Your Sysclk at 160MHz leads to APB1 at 16MHz, which may not allow for high data rates, or oversampling, on some peripherals.

Your RTC.Enable is off. I use LSE as clock source for RTC.

Richard

in no particular order
i suspect i started with a stm32f407vet as a new custom project.
i’m beginning to dislike GUI’s, no merge facility

hse/lse
istr getting right in one of my trials, see above

sdio – default setting, can’t see anything off defaults
istr setting gpio modes and initial output states for LED0 & LED1 – altering blinky mark/space ratios, so i know which is running

hse/lse/rtc – i thought i used a crystal for both. had a look at the diff, so copy and over paste might work

MCU.pin/RCC.xxx etc – that’s inserted by CubeMX, what i do to modify them is unclear, only thing i did was add user labels, not sure if i set up the spi alternate(s) as well.

i’m missing the really, really useful unicore-mx defines GPIO[ABCDEF] for ports, GPIOn/GPIOnn for the bit.

pin/port – i’d suggest 103VET as a reasonable starting point, if using the default mapping SPI1 on PA4-7 i’d define SPI1_CLK as PA5, then SPI2_CLK as PB13 etc, if using alternates, you would probably know of and how to use the std port/number we all love.

btw you can run two CubeMX windows!

i’m wondering if maybe ST might let us know how the ioc file is generated/used and broken down – nah unlikely

stephen

palmerr wrote:Good work on the DFU port!

The option of a 100Mbps RMII Ethernet would add something – particularly as PHY modules are cheaply available, e.g. LAN8720 for $3.20 on ebay.

The NRF is SPI, rather than I2C, so separate /CS pins are required for sharing. For instance SPI1 (or SPI3 as an AF) is already shared with NRF and the onboard Flash memory.

BTW @ag123, I’ve lost track of which code implementation you’re using: Maple, Cube (new STM32duino) or Koduino?

Are you using the Arduino IDE or Eclipse, etc?

Richard

OT: i’m thinking that when roger is around, perhaps roger could perhaps help to ‘move’ this thread to STM32F4 Boards section
as the discussions seemed pretty much F4 specific
hope that could be done conveniently

We could shift it there now, and simply make reference to this thread in the initial post.

oh just in case anyone ‘missed’ it 2 emerging stm32duino implementations that may run on F4

STM32GENERIC
http://www.stm32duino.com/viewtopic.php?f=42&t=1966

ST’s core
http://www.stm32duino.com/viewtopic.php?f=48&t=1943