2024-02-16 02:46 AM
Hey Team, I am working on STM32H745 for display project.
I have faced following issue.
Some time when I was program my device it was completed in 1.38 minutes usually it takes around 4 minutes because of external flash erase and program loading.
1) Issue was on device that took ~1.31 minutes to program it went to hard fault.
2) On device that took ~3.51 minutes to program no issues were found.
Controller: STM32H745.
External Memory using QSPI: W25Q512JV.
configuration of memory
/*W25Q512JV memory parameters*/
#define MEMORY_FLASH_SIZE 0x4000000 /* 64Mbit =>8Mbyte */
#define MEMORY_BLOCK_SIZE 0x10000 /* 64KBytes */
#define MEMORY_SECTOR_SIZE 0x10000 /* 4kBytes *///0x1000
#define MEMORY_PAGE_SIZE 0x100 /* 256 bytes */
#define TOTAL_PAGES 262144 /* Total number of pages */
2024-02-17 05:23 AM
Step through the code, debug the hard fault, determine where and why it's happening and correct those issues. There's unlikely to be a magic solution here.
If you think loading is failing, perhaps do a CRC check at program startup to verify memory content.
2024-02-19 01:23 AM
It appears that even though I selected the memory erase option during programming, it did not erase properly after a failed attempt. Here's a revised version with rephrased sentences and spell-checked:
2024-02-19 05:42 AM
You shouldn't be having connection issues as a general rule. If you are, something is likely wrong. Maybe recheck your hardware setup. Use a genuine programmer. Lower connection clock speed if you must.
Flash can be verified after writing which will provide assurance that it programmed successfully.
2024-02-24 03:14 AM
I've verified that the connection isn't the issue. My main concern is this:
When programming with the STM Cube Programmer, if we leave the "skip erase memory" option unchecked, do we need to manually erase the memory every time after a failed programming attempt?
Here's the sequence of events:
Is this manual erasure step necessary every time after a failed attempt, or is there a more efficient approach?
2024-02-24 01:17 PM
Generally one would CRC / HASH firmware images so they can be validated in-situ and you'd know what you have on the PC side is what you've got on the STM32 side, and you'd be able to pin down WHERE the problem lies, and WHAT you need to fix.