speeduino
speeduino copied to clipboard
stm32f401cc hangs on startup using spi eeprom
STM32F401CC hangs on startup release 2022.02 and 2022.7 when using spi as eeprom if board layout is selected in ts and I can only get it to boot again if I erase the memory, Using release 2021.08 it boots as it should.
What board are you selecting in TS to make this happen?
im trying to use v0.4 but it also happen when selecting any other board
Hmm i cannot find any changes that created a pin conflict between 202108 and 202207. And i have no STM32F401 board with a windbond eeprom chip to test.
I do know that the last version of STM32F401 that did work with internal flash as eeprom would have been around 202108. After that time the size of the image grew and the last page of flash is now used by the image (and cannot be used for eeprom).
Are you using internal flash as EEPROM by any chance?
I have compiled using arduino ide with use spi as eeprom uncommented and changed pin to use external flash. When compiling latest release i get an error if i try to compile using internal flash
Look at line 30 in board_stm32_official.ino and make sure the correct MISO, MOSI en SCK pins are selected. In 202107 those are:
SPIClass SPI_for_flash(PB5, PB4, PB3); //SPI1_MOSI, SPI1_MISO, SPI1_SCK
and in 202208
SPIClass SPI_for_flash(PB15, PB14, PB13);
Not sure which one is correct but this would explain the difference?
In the schematic of the blackpill STM32F401 boards it should be:
SPIClass SPI_for_flash(PA7, PA6, PA5);
The SPI pins are PB12 to PB15. The footprint on the board uses ADC pins and because that I choose to use SPI2. The board selected on TS must be STM32F407 as any other will lock the board.
i got latest release working by changing in board_stm32_official.ino
#if defined(STM32F407xx)
SPIClass SPI_for_flash(PB5, PB4, PB3); //SPI1_MOSI, SPI1_MISO, SPI1_SCK
#else //Blue/Black Pills
SPIClass SPI_for_flash(PB15, PB14, PB13);
to
#if defined(STM32F407xx)
SPIClass SPI_for_flash(PB15, PB14, PB13); //SPI1_MOSI, SPI1_MISO, SPI1_SCK
#else //Blue/Black Pills
SPIClass SPI_for_flash(PB15, PB14, PB13);
@sixten9999 Good, happy that works. But a bit strange... In your example you chance the STM32F407 definition. And in your post you mention the STM32F401CC board. If you build for the STM32F401 the change in your example does nothing... If you build for the STM32F407 the code should not run on a STM32F401CC. I am a bit confused :-D.
@VitorBoss Any reason to change the SPI for the STM32F401 from PB5, PB4, PB3 (In the 202107 this was the default for STM32F401). To the PB15, PB14, PB13 (The default for STM32F401 from release 202202 and onwards)? The PB5, PB4, PB3 are not analog inputs...
This is my settings in arduino ide. I dont know why changing the pins for f407 has an effect for me
when using the memory chip that i wrote board layout to with 2021.08 it works it also works with 2022.07 but when i use the memory i wrote board layout to using 2022.07 it does not boot.
@sixten9999 Good, happy that works. But a bit strange... In your example you chance the STM32F407 definition. And in your post you mention the STM32F401CC board. If you build for the STM32F401 the change in your example does nothing... If you build for the STM32F407 the code should not run on a STM32F401CC. I am a bit confused :-D.
@VitorBoss Any reason to change the SPI for the STM32F401 from PB5, PB4, PB3 (In the 202107 this was the default for STM32F401). To the PB15, PB14, PB13 (The default for STM32F401 from release 202202 and onwards)? The PB5, PB4, PB3 are not analog inputs...
https://stm32-base.org/boards/STM32F401CCU6-WeAct-Black-Pill-V1.2.html As seen in that link and at bottom of this: https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1/tree/master/SDK/STM32F401CEU6/MicroPython#readme The CS pin, SCK, MISO and MOSI uses PA4, PA5, PA6 and PA7
The real problem here is the detection as STM32F407 by the code, making it choose the F407 code specifics, this is why it is falling to compile with internal flash.
Also, just checked using git lens, last time those lines was modified was 10 months ago
@VitorBoss
https://stm32-base.org/boards/STM32F401CCU6-WeAct-Black-Pill-V1.2.html As seen in that link and at bottom of this: https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1/tree/master/SDK/STM32F401CEU6/MicroPython#readme The CS pin, SCK, MISO and MOSI uses PA4, PA5, PA6 and PA7
Yes i know, So that was not the question. I know the board location itself uses analog pins, and there not enough of those so indeed maybe not a good idea to use those for SPI eeprom/fram. But in 2021.07 it used to be PB5, PB4, PB3. This is SPI3 on the STM32F4x1 and that are not analog pins? Why change from SPI3 to SPI2 from that point and later?
Checkout the 2021.08 tag and see that is uses the PB5, PB4, PB3 for both the STM32F407 (SPI1) and STm32F4x1 (SPI3).
The real problem here is the detection as STM32F407 by the code, making it choose the F407 code specifics, this is why it is falling to compile with internal flash.
That is a strange thing indeed. All works fine in PIO. But i have not checked the arduino IDE lately. @sixten9999 Did you update and use the latest STM32 core during your tests?
BTW. The internal flash as eeprom for the STM32F401 might build fine, but it does not work.. The flash size of this chip is too small to support the firmware and the EEPROM emulation.
Now I got the question, that is easy, it was defined wrongly before 202108, check 6179d4b, pins PB4 to PB7 was defined to injectors outputs way before 202108. Also those pins was defined as injectors in January 2019(0c43400) for 0.4 definition
Now I got the question, that is easy, it was defined wrongly before 202108, check 6179d4b, pins PB4 to PB7 was defined to injectors outputs way before 202108. Also those pins was defined as injectors in January 2019(0c43400) for 0.4 definition
Ahh a bit of de dilemma what to prioritize as backwards compatible. Too bad.
BTW. on my arduino ide with STM32duino core 2.3.0 i can build with internal flash as eeprom fine. (Still does not work but it builds fine).
The image is exactly 4288 bytes too large. Cutting part of the code with SMALL_FLASH_MODE it might be able to reduce the size below 50% of the flash size. In that case internal flash as eeprom works again.