Any general discussion around the firmware, what is does, how it does it etc.
By iLeeeZi
#41440
Tjeerd wrote: Wed Mar 11, 2020 7:21 pm
iLeeeZi wrote: Tue Mar 10, 2020 9:40 pm After a while I got it working by modifying the BackupSramAsEEPROM.cpp file. For some reason I needed to disable the backup domain write protection at boot rather than temporarily disabling it when writing to SRAM. Also I needed to wait until the backup power regulator is ready at boot by adding "((PWR->CSR & PWR_CSR_BRR) == 0);" after the backup power regulator is enabled because otherwise it would randomly mess things up.
Interesting. It could be that i already powered my backup regulator during one of my many tests and it left like that. Then the whole thing worked for me but not for anyone else. Can you make a PR with the work around? I think it is actually not a bad solution. I just did not implement the checks needed!
I was not sure if there is any disadvantages when the write protection is disabled all the time rather than only when writing to the backup SRAM. I try to get it working by disabling it only when writing and after that I could make the PR.
Tjeerd wrote: Wed Mar 11, 2020 7:21 pm
iLeeeZi wrote: Tue Mar 10, 2020 9:40 pm Usb communications did still randomly break after those changes were made if there was random data in the SRAM. That was fixed by clearing the backup SRAM by setting all bytes to zero. if it was cleared by setting all bytes to 255 it still wouldn't work :?

This might not be the proper solution but at least it is a workaround.
USB communication problems where all solved for me as soon as i removed some resistor on the ebay board. (that resistor has to do with the USB enumeration). A few posts back i wrote about it. Maybe that is the usb issue? Or is it Only when backup Sram is used and not when SPI flash is used?
The usb issue happened only when the SRAM was full of random data. My board doesn't have the pullup resistor so it wasn't the issue. The board also doesn't have a SPI flash chip so I couldn't test it.
By Tjeerd
#41850
Hi All

I fixed the SPI flash as EEPROM again and made some updates in the Flash and Sram storage solutions. Also included the backup Sram and timer updates from @iLeeeZi . Thanks for making it work @iLeeeZi!

Unfortunately a storage solution with internal flash is not on the horizon yet (at least not from my part). Especially not with the correct methods. (with wear leveling that is).

This is the updated manual to compile/test the code on a Black stm32F407VE6T board from eBay.

Install tool chain
1. Install the arduino IDE (1.8.12)
2. Install the stm32duino core from: https://github.com/stm32duino/Arduino_Core_STM32 (version 1.8.0)
3. install https://www.st.com/content/st_com/en/pr ... eprog.html

Build code
1. Download the speeduino master code from my fork (https://github.com/Tjeerdie/speeduino)
2. Open the code in de arduino IDE.
3. In arduino IDE select Tools->Board: GENERIC STM32F4 series
4. In Arduino IDE select Tools->Board part number: "BLACK F407VE"
5. In Arduino IDE select Tools->USART support: Enabled (generic serial)
6. In Arduino IDE select Tools->USB support: CDC (generic serial)
7. Edit the board.txt file located in
--------Windows: C:\Users\%USER%\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\
--------Linux: ~/.arduino15/packages/STM32/hardware/stm32/1.8.0/boards.txt
8a. Replace line 942 with the following for spi flash storage: GenF4.build.extra_flags=-DUSE_SPI_EEPROM=56 -DCORE_STM32_OFFICIAL -D{build.product_line} {build.enable_usb} {build.xSerial} {build.bootloader_flags}
8b Replace line 942 with the following for battery backed sram storage: GenF4.build.extra_flags=-DSRAM_AS_EEPROM -DCORE_STM32_OFFICIAL -D{build.product_line} {build.enable_usb} {build.xSerial} {build.bootloader_flags}
10. Build the speeduino project.

Hardware modifications
1. Remove the R21 resistor from the board (close to USB port)
2. Put the jumper close to the CPU (BT0) to connect to the 3.3 volt instead of GND (one step up)
3. Reset the board.

Upload
1. In Arduino IDE select Programmer: "STM32CubeProgrammer DFU"
2. Upload the code
3. Put the Jumper back in its original position.
4. Reset the board

After these steps you should be able to connect to the board using the USB cable and use tuner studio. Tested the compilation in Linux Ubuntu 18.04.3 LTS. The board will lockup during boot when there is no SPI flash available or the incorrect chip select pin is selected for the flash chip.

To change the cs pin change the -DUSE_SPI_EEPROM=56 to the pin number where to find the correct pin.

On the hardware side of things there is another thread in the user board hardware channel.
Last edited by Tjeerd on Tue Apr 07, 2020 5:02 pm, edited 1 time in total.
By NickZ
#41858
what does the 56 mean? is it the physical pin number on the processor?

But is does compile and run on my board.
20200405_235815.jpg
20200405_235815.jpg (757.17 KiB) Viewed 9980 times
By Tjeerd
#41863
NickZ wrote: Sun Apr 05, 2020 1:40 pm what does the 56 mean? is it the physical pin number on the processor?
This is the decimal number representing pin PB0. Noisy asked me to change the pin naming because PB0 will only be valid on a STM32 cpu. So now i representing this as a decimal number like the Arduino. I think using PB0 etc should also work but i did not test. Unfortunately there is no clear mapping of numbers to pin names. You need to take a look at the ST Arduino core code to find the decimal number. In visual studio code this is easy as the editor does that for you.
NickZ wrote: Sun Apr 05, 2020 1:40 pm But is does compile and run on my board.
Thanks for testing! How is the development going on the hardware side?
By NickZ
#41869
great, i used PB0.
im waiting on the next revision of the board to arrive to fully populate it.
Ill also have to sit down and workout the numbering system for the pins.
By Tjeerd
#41918
added the macro defines for vbat usage as configuration storage. use Steps 8a OR 8b
8a Is for spi flash step
8b Used for battery backed Sram when the vbat pin of the MCU is connected to a backup battery.

Step 8b is not fully tested.
By Tjeerd
#42053
Hi All

It took me much more time to debug this than expected but it seems to work now. It is a bit of a waste of time, especially considering this is never ending up in the speeduino project.

But you can now store a configuration on the stm32F407VE boards without any Vbat pins connected to backup battery or SPI flash connected! It stores the configuration on internal flash. Most of the ground work for this had already been done by the ST arduino core. But a pesky uninitialized pointer in the idle routine messed everything up. This pointer points toward flash memory and tried to write to the flash every 250ms. This is raising all kind of errors!

No guaranties that it will work. Also no guarantee it will not damage your board/car or MCU in any way.

It however means that speeduino is one step closer to run on the competitors hardware that uses the stm32F4 MCU. Pin outs still need to change to correspond to the hardware. Maybe someone is interested. If you tested it, please let me know the results.

To try it out:
Download the master branch from my github repsoitory. https://github.com/Tjeerdie/speeduino Remove the “-DUSE_SPI_EEPROM=56” from the board.txt file if you used the previous manual. Build speeduino for the BLACK stm32F407VE board using the arduino IDE, or using PIO on visual studio code.

Remark 1: There is no wear leveling in this implementation. This means the flash can wear very quickly! ~10k erase cycles and the flash is toast. Every configuration burn in TS will use around 2 tot 4 erases. This means around 2.5k to 5k configuration burns can be performed. If noisymime is interested in using something like this I can make a more robust implementation with wear leveling. Much like the SPI flash implementation.

Remark 2: The stm32 stops fetching code from flash during an erase. This effectively means speeduino stops running for ~1 sec at least during each burn. This can cause ignition coils to be burned! There is no over dwell protection code running! If the coil is energized when burning a config in TS this can fry it.
By joey120373
#42321
Quick question,

What are the benifits to using the STM32 platform over the Mega or teensy ?

I understand the teensy and STM offer a faster clock and are 32 bit micro controllers, but from everything I have yet to read, the firmware does not yet add any real advantage over the Mega.

As I understand it, the available clocks on the Mega are a limiting factor, and I am assuming that the teensy and possibly the STM32 might allow for more sequential channels if/when the firmware gets developed?

Outside of that, what advantages does the STM platform offer? It seems like there are a lot of hoops to jump through to make it work, so I am assuming there are some real advantages ( outside of cost ) but I have yet to find any explanation of what they are or might be.
By joey120373
#42322
Quick question,

What are the benifits to using the STM32 platform over the Mega or teensy ?

I understand the teensy and STM offer a faster clock and are 32 bit micro controllers, but from everything I have yet to read, the firmware does not yet add any real advantage over the Mega.

As I understand it, the available clocks on the Mega are a limiting factor, and I am assuming that the teensy and possibly the STM32 might allow for more sequential channels if/when the firmware gets developed?

Outside of that, what advantages does the STM platform offer? It seems like there are a lot of hoops to jump through to make it work, so I am assuming there are some real advantages ( outside of cost ) but I have yet to find any explanation of what they are or might be.
  • 1
  • 10
  • 11
  • 12
  • 13
  • 14
  • 30

It looks like you have a fuel supply issue. readin[…]

Will this have an updated version about this featu[…]

Vr Conditioner Noise when cranking

I did the fix, but it's not work. I put my setti[…]

Perhaps some different points and pictures. Instr[…]

Still can't find what you're looking for?