Speeduino is now on Github Sponsors (Rather than Patreon): https://github.com/sponsors/noisymime
Any general discussion around the firmware, what is does, how it does it etc.
By Tjeerd
#41369
pazi88 wrote:
Fri Mar 06, 2020 6:11 pm
I'm using same board and it works fine with USB when using these settings in Arduino IDE:
Settings.png

But I have problems when trying to change any values in TS. No matter what I touch, I get this error:
Error.png

Probably something related to eeprom emulation, but not sure where to start looking for the fault.
Hi pazi88
I did have the same problem. This is related to the slow (VERY SLOW) eeprom emulation in think. That is the reason i gave up on using eeprom emulation and used the SPI flash chip on the black STM32F407VE boards. This does work for me at the moment. Only the first time loading the initial tune it gets into the same timeout problem sometimes. But after 1 or 2 restarts trying to load the tune it does work. Also then changing just one variable works without a hitch. Does the board u use have the spi flash somewhere?

At the moment using SPI flashs is not enabled by default form the speeduino master branch using the Microsoft visual studio code environment. Do you use this or are you using arduino ide?
By pazi88
#41370
I use Arduino IDE. Getting the PlatformIO in VScode to work for me has been a pain. Currently got it compiling with strange warnings but no idea how to configure it to use stm32cube flasher by DFU mode.

Anyways I now got it working using the SPI flash. I needed to uncomment the #define SPIFLASH_AS_EEPROM line in globals.h. I also needed to add the -DUSE_SPI_EEPROM and -DCORE_STM32_OFFICIAL build flags to boards.txt. And even that wasn't enough, because I also needed to add your PR329 to my branch and add =PA15 to the end of the -DUSE_SPI_EEPROM (spi flash CS is at PA15). And then finally burning the values in TS started to work. I then tried to use my base tune and burning the values in TS went dead again. I suspect that the board I selected has some SPI pin defined for other use and that made the SPI bus dead after loading base tune, because it looks like that the arduino avr pins (1,2,3 etc.) are translated to stm32 pins (like pb1) in strange fashion.
Last edited by pazi88 on Mon Mar 09, 2020 7:17 am, edited 2 times in total.
By pazi88
#41371
Yeah. That was it. I added F407 pin mapping to my BMW-PnP board configuration and it started working.

Bit confusing to setup everything because there seems to be several build configs for that SPI flash usage that are named slightly different. Like that USE_SPI_EEPROM and SPIFLASH_AS_EEPROM.
By Tjeerd
#41381
pazi88 wrote:
Sun Mar 08, 2020 7:35 pm
Yeah. That was it. I added F407 pin mapping to my BMW-PnP board configuration and it started working.

Bit confusing to setup everything because there seems to be several build configs for that SPI flash usage that are named slightly different. Like that USE_SPI_EEPROM and SPIFLASH_AS_EEPROM.
Nice! you got it working! The way to configure the spi flash at the moment is not ideal indeed. Also the spi flash implementation can be broken very easily indeed by selecting some pins for other uses that are the SPI pins on the board. If noisy add my PR to the master i will make a new manual howto configure using spi flash with Arduino IDE and the VScode environment.
By iLeeeZi
#41382
Tjeerd wrote:
Mon Mar 09, 2020 2:08 pm

Nice! you got it working! The way to configure the spi flash at the moment is not ideal indeed. Also the spi flash implementation can be broken very easily indeed by selecting some pins for other uses that are the SPI pins on the board. If noisy add my PR to the master i will make a new manual howto configure using spi flash with Arduino IDE and the VScode environment.
Tjeerd have you tested the SRAM backup lately? I have been trying to use it but it doesn't seem to keep the settings between reboots as after a reboot it reads garbage. Vbat pin voltage is over 3.2v whole time so it shouldn't be a problem but I might be missing something hardware related.
By iLeeeZi
#41417
iLeeeZi wrote:
Mon Mar 09, 2020 2:27 pm
Tjeerd have you tested the SRAM backup lately? I have been trying to use it but it doesn't seem to keep the settings between reboots as after a reboot it reads garbage. Vbat pin voltage is over 3.2v whole time so it shouldn't be a problem but I might be missing something hardware related.
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.

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.
By pazi88
#41425
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 :?
That might be because of that same pin usage issue. If there is random data in the memory, it will use random pin configuration and settings and might try use the usb pins for something else and braking up the connection like that.

I had zero luck using the SRAM option. The USB connection was corrupted soon as I powered up the board. The SPI FLASH seems to work well enough. Currently trying to make the 8x8 sequential working.
By Tjeerd
#41437
iLeeeZi wrote:
Mon Mar 09, 2020 2:27 pm
Tjeerd wrote:
Mon Mar 09, 2020 2:08 pm

Nice! you got it working! The way to configure the spi flash at the moment is not ideal indeed. Also the spi flash implementation can be broken very easily indeed by selecting some pins for other uses that are the SPI pins on the board. If noisy add my PR to the master i will make a new manual howto configure using spi flash with Arduino IDE and the VScode environment.
Tjeerd have you tested the SRAM backup lately? I have been trying to use it but it doesn't seem to keep the settings between reboots as after a reboot it reads garbage. Vbat pin voltage is over 3.2v whole time so it shouldn't be a problem but I might be missing something hardware related.
Hi iLeeeZi

No i did not try this recently. I could be broken maybe this weeknd i have some time to investigate

Regards,
Tjeerd
Last edited by Tjeerd on Wed Mar 11, 2020 7:27 pm, edited 1 time in total.
By Tjeerd
#41438
pazi88 wrote:
Wed Mar 11, 2020 7:11 am
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 :?
That might be because of that same pin usage issue. If there is random data in the memory, it will use random pin configuration and settings and might try use the usb pins for something else and braking up the connection like that.

I had zero luck using the SRAM option. The USB connection was corrupted soon as I powered up the board. The SPI FLASH seems to work well enough. Currently trying to make the 8x8 sequential working.
Hi. Yes that could indeed be an issue. Maybe use the CRC to check if SRAM has valid data. And if not use default pin mapping not to break the usb connection?
By Tjeerd
#41439
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!
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?
  • 1
  • 9
  • 10
  • 11
  • 12
  • 13
  • 15
Fuel Injected Two Stroke

. The AFR lower Yellow line stays consistent for t[…]

Gamma Enrichment?

So, either take a log of it happening and post it,[…]

Hi All For everyone that is interested: I designe[…]

STM32 development

Standard dec to STM32 pins in variant.h is: // Ri[…]

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