Program loading is failed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-16 2: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 */
- Labels:
-
STM32CubeProgrammer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-17 5: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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-19 1: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:
- Initially, I began programming the hardware using Cube Programmer with the flash memory erase option selected.
- However, due to intermittent connection issues, the programming process was interrupted, leading to a failure to download the code.
- Subsequently, I restarted the programming process, again opting for the flash memory erase option.
- Unfortunately, the process encountered an error and halted at around 50% completion.
- To address this issue, I manually performed a full chip erase on the external flash memory.
- After waiting for approximately four minutes, I restarted the programming process, which then completed successfully, loading the code onto the device.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-19 5: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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-24 3: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:
- Begin programming with the "skip erase memory" option unchecked.
- Programming fails at some point (seemingly randomly).
- Despite multiple attempts to re-establish connection and program again, it fails to load.
- Manually erase internal and external files.
- Restart programming with the "skip erase memory" option unchecked, and it successfully loads.
Is this manual erasure step necessary every time after a failed attempt, or is there a more efficient approach?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-24 1: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.
Up vote any posts that you find helpful, it shows what's working..
