Is the NVIC_VTABLE repointed to the RAM vectors?
-----Original Message-----
From: James Dougherty <jafr...@gmail.com>
Sent: Thursday, December 8, 2022 12:40 AM
To: dev@nuttx.apache.org
Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
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
>>> >
>>>
>>
