1
\$\begingroup\$

I tried to detect a blackout on an stm32F405VGT6, which should write a counter inside the virtual EEPROM (Flash). It seems, that the writing process was not fast enough. Now, i cannot initalize the Flash anymore, it always gives me back a HAL_ERROR (FLASH_FLAG_PGPERR and FLASH_FLAG_PGSERR) when I call the HAL_FLASH_Program(uint32_t TypeProgram, uint32_t Address, uint64_t Data) function.

I tried already to completely erease the STM32 with the STUtility tool, but also this did not work. Is it possible, that I broke my Flash? Are there any ways to protect the flash from a blackout while it is writing?

\$\endgroup\$
5
  • \$\begingroup\$ It looks like you are using a separate library? Perhaps this one? Look at the library's code and see where you can find HAL_ERROR. I believe I see some conditional code that will tell how this exception is raised. \$\endgroup\$
    – user103380
    Sep 5, 2018 at 14:17
  • \$\begingroup\$ I've been looking at the code. You should look around at 594 and 595. That should should give you a clue on where to start your investigation. I would read what the comments say in line 577. \$\endgroup\$
    – user103380
    Sep 5, 2018 at 14:25
  • \$\begingroup\$ Try to flash with utility tool and then verify the writen data. If it fails, then the flash is broken. Flashing in runtime can soon destroy a flash, because it does hundreds thousands times before you can notice a bug in the program. \$\endgroup\$
    – Marko Buršič
    Sep 5, 2018 at 15:56
  • \$\begingroup\$ Ok, well I think the flash is gone. I will try to replace the microcontroller. \$\endgroup\$
    – HansPeterLoft
    Sep 5, 2018 at 18:11
  • 2
    \$\begingroup\$ @MarkoBursic you are 100% wrong. Even if you use SWD programmer debugger you actually program FLASH memory runtime. There is no other way. Programs like openOCD or gdbserver first load small program to RAM and this program writes the FLASH. \$\endgroup\$
    – 0___________
    Sep 6, 2018 at 3:08

1 Answer 1

Reset to default
1
\$\begingroup\$

Try to perform mass erase. Use registers instead of this silly library

The comments about the dangers of the runtime FLASH programming are wrong. There is no other way of FLASH programming and even when you program the chip using your favourite debug probe (it does not matter SWD or JTAG) the software (in most cases ooenOCD or gdbserver load small program to the RAM which programs the FLASH. There are no hardware mechanisms of STM32 FLASH writing.

\$\endgroup\$
5
  • \$\begingroup\$ You can also just program FLASH directly over SWD, flashloaders just tend to speed up the process by transferring the binary with less protocol overhead than with direct programming. Of course your point that no other method exists is still correct. The FLASH is still physically written in the same manner, just with data over the AHB AP bus instead of over the D bus. \$\endgroup\$
    – Patrick Roberts
    Sep 6, 2018 at 3:27
  • \$\begingroup\$ @PatrickRoberts there is no way of direct FLASH writing. comparing to the speed of FLASH writing protocol overhead would be marginal \$\endgroup\$
    – 0___________
    Sep 6, 2018 at 4:03
  • \$\begingroup\$ your first statement is incorrect. The AHB AP bus allows you to directly access flash memory. It's not a "hardware mechanism" which is why I agree with your answer (just clarifying that in case you think I didn't agree with it). And your second statement seems to be a result of misunderstanding what I'm saying. The protocol overhead of SWD is quite a lot. Off the top of my head, you clock about 416 bits for every 64 bits programmed in standard programming mode. So no the overhead is not marginal by any measure. \$\endgroup\$
    – Patrick Roberts
    Sep 6, 2018 at 4:14
  • \$\begingroup\$ FLASH erase time 2ms and DW programming 80us. At 4MHz it will be 320x8 clocks per 64 bytes \$\endgroup\$
    – 0___________
    Sep 6, 2018 at 4:32
  • \$\begingroup\$ to be fair, I was referring to the percentage overhead (which as you can see I wasn't far off, which is good for estimating from memory if I say so myself), not the absolute time necessary. But thankfully after triple-checking your math, it led me to find a discrepancy in an SWD programmer I wrote recently. It runs at 1.25MHz but it's taking about 19 seconds to program (not exactly sure since it skips empty pages) ~50kB of data, which by your math is really far off from the target. Thank you for helping me realize that. \$\endgroup\$
    – Patrick Roberts
    Sep 6, 2018 at 5:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.