- Wed Mar 11, 2020 10:04 pm
#41440
Tjeerd wrote: ↑Wed Mar 11, 2020 7:21 pmI 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.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!
Tjeerd wrote: ↑Wed Mar 11, 2020 7:21 pmThe 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.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 workUSB 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?
This might not be the proper solution but at least it is a workaround.