RAMFUNCS certainly works for this funcs with __ramfuncs__ attributed tagged
funcs for the eefr procs. And I do see ramvectors load from OpenOCD..
(gdb) lo
Loading section .text, size 0x30e14 lma 0x400000
Loading section .ARM.exidx, size 0x8 lma 0x430e14
Loading section .data, size 0x1158 lma 0x430e1c
Loading section .ram_vectors, size 0x154 lma 0x431f74
Loading section .ramfunc, size 0x2a4 lma 0x4320c8
Start address 0x400154, load size 205676
Transfer rate: 28 KB/sec, 12098 bytes/write.
(gdb) mon reset run
On Wed, Dec 7, 2022 at 9:37 PM James Dougherty <jafr...@gmail.com> wrote:
> 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
>>> >
>>>
>>
