Hi Petro,
Thank you for your email (the silence was deafening) :)
The SAME70-XPlained board in master would be very similar and a good test
case.
In doing some archaeology on master, I found that the XULT board has
RAMFUNCS enabled!
I'm using SAME70N21B, configuration parameters as below:
#
# ARM Options
#
CONFIG_ARMV7M_USEBASEPRI=y
#
# SAMV7 Peripheral Selection
#
CONFIG_SAMV7_PROGMEM=y
CONFIG_SAMV7_PROGMEM_NSECTORS=16
#
# Architecture Options
#
CONFIG_ARCH_HAVE_PROGMEM=y
CONFIG_ARCH_IRQPRIO=y
CONFIG_ARCH_RAMFUNCS=y
CONFIG_ARCH_RAMVECTORS=y
#
# Interrupt options
#
CONFIG_ARCH_HIPRI_INTERRUPT=y
#
# Boot options
#
CONFIG_BOOT_COPYTORAM=y
#
# MTD Configuration
#
CONFIG_MTD_PROGMEM=y
#
# MTD Device Drivers
#
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_MAXNUMBLOCKS=1024
CONFIG_MTD_NAND_MAXNUMPAGESPERBLOCK=256
CONFIG_MTD_NAND_MAXPAGEDATASIZE=4096
CONFIG_MTD_NAND_MAXPAGESPARESIZE=256
CONFIG_MTD_NAND_MAXSPAREECCBYTES=48
CONFIG_MTD_NAND_BLOCKCHECK=y
CONFIG_MTD_NAND_SWECC=y
CONFIG_MTD_NAND_MAXSPAREEXTRABYTES=206
#
# File System Utilities
#
CONFIG_FSUTILS_FLASH_ERASEALL=y
#
# System Libraries and NSH Add-Ons
#
CONFIG_SYSTEM_FLASH_ERASEALL=y
CONFIG_SYSTEM_INSTALL=y
Debugger is SAM-AVR, via open-ocd/DAP and GDB target remote:
openocd -f interface/cmsis-dap.cfg -f target/atsamv.cfg
A very simple way to recreate the issue is to issue the flash_eraseall:
NuttShell (NSH)
nsh> flash_eraseall /dev/mtd0
Wammo, it lands in hardfault:
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x81000003 pc: 0x004009a0 msp: 0x2041bfb4
Polling target samv.cpu failed, trying to reexamine
Info : samv.cpu: hardware has 8 breakpoints, 4 watchpoints
00400980 <exception_common>:
400980: f3ef 8005 mrs r0, IPSR
400984: 466a mov r2, sp
400986: f102 0220 add.w r2, r2, #32
40098a: f3ef 8311 mrs r3, BASEPRI
40098e: b0a1 sub sp, #132 ; 0x84
400990: e92d 0ffc stmdb sp!, {r2, r3, r4, r5, r6, r7, r8, r9, sl, fp}
400994: f04f 0240 mov.w r2, #64 ; 0x40
400998: f382 8811 msr BASEPRI, r2
40099c: 4669 mov r1, sp
40099e: 466c mov r4, sp
4009a0: f8df d038 ldr.w sp, [pc, #56] ; 4009dc <exception_common+0x5c>
<---- aieeee!
So big question is why the exception_common is in FLASH when COPYTORAM and
RAMVECT
enabled? Maybe some work needs to be done there, I will have to dig deeper.
I did check
my dissasembly and map files and linker scripts:
384K SRAM @20400000 && 2MB FLASH @400000
and all is bueno. Alas, there is probably some bug as-yet undiscovered;
maybe Greg knows?
Thank you Petro, Greg for looking at this, I will have to do something else
nice for you
given the current world situation right now - I really appreciate this!
Best regards
-James
PS, maybe not coincidental - a thread earlier mentioned Precision Time
Protocol (IEEE1588); an excellent target platform would be SAMV7x
or SAME7x which has the MAC PHY timestamping ....
On Tue, Dec 6, 2022 at 4:14 PM Petro Karashchenko <
petro.karashche...@gmail.com> wrote:
> 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
> >
>
