Hello James, I've been working with SAMe70 based device and can try to take a look at a case that you are talking about. Do you have any specific config that I can start from?
In general I expect that if you fully relocate your program to SRAM you should be capable of reprogramming a full flash, but I have not tried that. If you are running one part from flash and only a few functions from SRAM, then I forecast hardfaults to happen. Also for EEFC I have IAP integrated somewhere in a branch. I added it when I was working on an issue when SAMe70 flash bits sporadically flip during partial sector programming. BTW, I have not been able to fix it and can't find anything in errata as well. If you are interested, then I can share details with you. The mcuboot is a good option, but it will not handle the full flash reprogramming. Best regards, Petro вт, 6 груд. 2022 р. о 21:08 James Dougherty <jafr...@gmail.com> пише: > Hi Folks, > > I've finished a major milestone on some of the firmware I developed for > this processor. > As such, I wanted to add a firmware update which uses progmem. My > understanding is that > if I run from ram, I should be able to erase all sectors and update the > flash. Well, I tried that > and in debug I found that exception_common is still in the flash addrspace > (0x4x0000). So > when I flash any sector that overlaps the image I get a Hardfault. I did > add __ramfuncs__ to a > few eefc routines and that got me out of jail, I can erase and program any > page/sector which > is not being used by the program, but anything inside the program region > yields a hardfault. > I debugged a few of them, but I am still confused why exception_common is > not in ram ... > > Any pointers or guidance here would be greatly appreciated! > > PS, I could just byte the bullet and use mcuboot, which I will probably do, > but for starters > the basics should work (e.g. flash the entire 2MB flash which running from > Ram). > > Thanks! > -James >
