I did a quick review of this tonight at least with RAMFUNCS and COPYTORAM
defines.
I read through most of the code related to copying the vectors to ram. I
didn't find where
exception_common gets put into the ram-vectors for the CM7... maybe someone
knows?
Seems like something is missing...
jfd@area51:~/nuttx/apache/grad/nuttx$ find . -type f |xargs grep
CONFIG_BOOT_COPYTORAM
./arch/arm/src/arm/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y). In this case
./arch/arm/src/arm/arm_head.S:#elif defined(CONFIG_BOOT_COPYTORAM)
./arch/arm/src/arm/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n). In this case SDRAM
./arch/arm/src/imx1/imx_allocateheap.c:#if
!defined(CONFIG_BOOT_RUNFROMFLASH) && !defined(CONFIG_BOOT_COPYTORAM)
./arch/arm/src/imx1/imx_boot.c: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y).
./arch/arm/src/imx1/imx_boot.c: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n).
./arch/arm/src/imx1/imx_boot.c:#if !defined(CONFIG_BOOT_RUNFROMFLASH) &&
!defined(CONFIG_BOOT_COPYTORAM)
./arch/arm/src/imx1/imx_memorymap.h: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y). In this case:
./arch/arm/src/imx1/imx_memorymap.h: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n).
./arch/arm/src/armv7-r/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y). In this case
./arch/arm/src/armv7-r/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n). In this case SDRAM
./arch/arm/src/armv7-a/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y). In this case
./arch/arm/src/armv7-a/arm_head.S:#elif defined(CONFIG_BOOT_COPYTORAM)
./arch/arm/src/armv7-a/arm_head.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n). In this case SDRAM
./arch/arm/src/armv7-a/arm_pghead.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=y). In this case
./arch/arm/src/armv7-a/arm_pghead.S:#elif defined(CONFIG_BOOT_COPYTORAM)
./arch/arm/src/armv7-a/arm_pghead.S: * (CONFIG_BOOT_RUNFROMFLASH=n &&
CONFIG_BOOT_COPYTORAM=n). In this case SDRAM
jfd@area51:~/nuttx/apache/grad/nuttx$
On Tue, Dec 6, 2022 at 8:23 PM James Dougherty <jafr...@gmail.com> wrote:
> 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
>> >
>>
>
