You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by James Dougherty <ja...@gmail.com> on 2022/12/06 19:08:07 UTC
SAM-E70 progmem - in system programming and RAMFUNCS
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
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
Hi Petro,
I checked the Errata:
https://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Errata-DS80000767J.pdf
There is the ARM note:
3. Arm® Cortex®-M73.1 Arm Cortex-M7All issues related to the Arm r0p1 (for
MRLA) and r1p1 (and MRLB)
cores are described on the Arm website.
WorkaroundRefer to the following Arm documentation:
• For Arm Cortex-M7 r0p1 core (MRLA device):
https://silver.arm.com/download/download.tm?pv=2004343
• For Arm Cortex-M7 r1p1 core (MRLB device):
https://silver.arm.com/download/download.tm?pv=3257391&p=1929427
• Arm Embedded Trace Macrocell CoreSight ETM–M7 (TM975) Software
Developers Errata Notice:
https://silver.arm.com/download/download.tm?pv=1998309
Do you know about these or what they cover? I couldn't find the link but
didn't really search after that.
5. Device 5.1 AHB Peripheral (AHBP) Port Frequency Ratio
Peripheral accesses done through the AHBP with a Core/Bus ratio of 1/3 and
1/4 may lead to unpredictable results.
WorkaroundThe user must use a Core/Bus frequency ratio of 1 or 1/2.
So I am running 300Mhz core and 150Mhz core, but I ready this in reverse -
the core should be 150 and the backplane
75 or 150/150? The backplane doesn't run at 300, or am I missing something?
Do you run 300/150?
I am using SAME70N21B-ANT, what about you?
Thank you and best regards
-James
On Fri, Dec 9, 2022 at 8:02 PM James Dougherty <ja...@gmail.com> wrote:
> Thanks Petro,
>
> You are right, or so it seems, but from what I can tell most of this is
> working already
> and since the armv7-m code is common across STM32 as well that should be
> ok.
>
> But I did tst and try what you said, it is an easy change because we are
> in thumb mode and
> the SAMBA bootloader initializes internal SRAM on SAME70. So we make a
> small trampoline
> by simply renaming __start() in sam_start.c to arm_boot, and add sam_head.S
> to implement __start which sets up the initial stack, calls
> arm_data_initialize and then jumps to arm_boot()
>
> In arm_data_initialize we zero bss, copy from flash to ram and we don't
> need to call arch_clean_dcache because
> the cache is in write-through mode (write-through simplifies the cache
> coherency protocol because it doesn't need the
> modified state - the main memory is always up to date).
>
> I use ISB to throw away any pre-fetched instructions and squash the
> pipeline ..
> DIffs:
> In samv7/Makedefs
>
> -HEAD_ASRC =
> +HEAD_ASRC = sam_head.S
>
>
> In samv7/sam_start.c
>
> -const uintptr_t g_idle_topstack = HEAP_BASE;
> +//const uintptr_t g_idle_topstack = HEAP_BASE;
>
> -void __start(void)
> +void arm_boot(void)
>
> Copy attached asm file into samv7 directory and rebuild.
>
>
> Anyhow, it boots, but no difference - still get that exception_common with
> a FLASH address... I will have to dig deeper but
> do please try the attached and see if it works for you or I missed
> something... changes are trivial, it is
> a basic m7 copy flash to ram like the armv7-r
>
> Oh yes, related, I was also able to catch an interrupt with symbols:
>
> Program received signal SIGINT, Interrupt.
> up_doirq (irq=3, regs=0x20402534 <g_intstackalloc+1844>) at
> armv7-m/up_doirq.c:58
> 58 {
> (gdb) up
> #1 0x00400a00 in exception_common () at armv7-m/gnu/up_lazyexception.S:237
> 237 bl up_doirq /* R0=IRQ, R1=register save (msp) */
> (gdb) up
> Initial frame selected; you cannot go up.
> (gdb) down
> #0 up_doirq (irq=3, regs=0x20402534 <g_intstackalloc+1844>) at
> armv7-m/up_doirq.c:58
> 58 {
> (gdb)
>
> up_irq in ram but exception_common still in flash, I wonder why we hit
> that IRQ (Hardfault).
>
> Thanks and let me know what you think.
>
> Best regards
> -James
>
>
>
> On Fri, Dec 9, 2022 at 2:24 AM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
>> In order to have the possibility to reprogram the whole internal flash you
>> will need to implement CONFIG_BOOT_COPYTORAM option in sam_start.c and
>> create a proper linker script.
>> Maybe even you will need to move the __start routine to the assembly file
>> because after copying code to RAM you will need to drain the instruction
>> pipeline before jumping to relocated code and that will require making
>> sure
>> that start-up is done in position independent code and just to the
>> relocated code will not use relative offset jumps.
>>
>> Best regards,
>> Petro
>>
>> пт, 9 груд. 2022 р. о 12:18 Petro Karashchenko <
>> petro.karashchenko@gmail.com>
>> пише:
>>
>> > Hi,
>> >
>> > Finally I was able to take a look here. The case is that armv7-m (and
>> some
>> > other ARM versions) do not use arm_head.S and __start entry points are
>> > implemented in C code and CONFIG_BOOT_COPYTORAM option is not
>> implemented,
>> > so code is always executed from internal flash. So when you are trying
>> to
>> > erase all internal flash you are getting an exception and that is
>> expected.
>> > Currently the CONFIG_ARCH_RAMFUNCS only copies functions marked with
>> > __ramfunc__ attribute. The internal flash access APIs should be in SRAM
>> > because that is a requirement of flash access, uness IAP is used to
>> access
>> > flash. I will try to push the IAP version and remove many of EEFC APIs.
>> >
>> > The MCUboot variant works because MCUboot is located at the separate
>> flash
>> > partition and erase/reprogram only application slots. I mean that
>> MCUboot
>> > can't update itself.
>> >
>> > Even having CONFIG_ARCH_RAMVECTORS enabled you will not be able to
>> > reprogram the whole internal flash because of the above.
>> >
>> > Best regards,
>> > Petro
>> >
>> > пт, 9 груд. 2022 р. о 07:56 David Sidrane <da...@nscdg.com>
>> пише:
>> >
>> >> Have you ensured that all the code (and support code, systic etc) is in
>> >> RAM?
>> >>
>> >> Also, Is this an ECCed FLASH? Is the write size correct? We must line
>> >> cache
>> >> the writes on some parts in the PX4 bootloader.
>> >>
>> >>
>> >>
>> https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
>> >>
>> >>
>> >> David
>> >> -----Original Message-----
>> >> From: James Dougherty <ja...@gmail.com>
>> >> Sent: Friday, December 9, 2022 12:46 AM
>> >> To: dev@nuttx.apache.org
>> >> Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
>> >>
>> >> Thank you Greg, Thank you David!
>> >>
>> >> I did check that is correct:
>> >>
>> >> arch/arm/src/samv7/sam_start.c - 344:356
>> >>
>> >> /* Copy any necessary code sections from FLASH to RAM. The correct
>> >> * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
>> >> * temporary location is in flash after the data initialization code
>> >> * at _framfuncs. This should be done before sam_clockconfig() is
>> >> * called (in case it has some dependency on initialized C
>> variables).
>> >> */
>> >>
>> >> #ifdef CONFIG_ARCH_RAMFUNCS
>> >> for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
>> >> {
>> >> *dest++ = *src++;
>> >> }
>> >> #endif
>> >>
>> >> Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
>> >> 36:113
>> >>
>> >> /* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000
>> and
>> >> * 384Kb of SRAM beginining at 0x2040:0000
>> >> *
>> >> * When booting from FLASH, FLASH memory is aliased to address
>> 0x0000:0000
>> >> * where the code expects to begin execution by jumping to the entry
>> point
>> >> in
>> >> * the 0x0400:0000 address range (Assuming that ITCM is not enable).
>> >> */
>> >>
>> >> MEMORY
>> >> {
>> >> flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
>> >> 0x20400000, LENGTH = 384K }
>> >>
>> >> OUTPUT_ARCH(arm)
>> >> EXTERN(_vectors)
>> >> ENTRY(_stext)
>> >>
>> >> SECTIONS
>> >> {
>> >> .text : {
>> >> _stext = ABSOLUTE(.);
>> >> *(.vectors)
>> >> *(.text .text.*)
>> >> *(.fixup)
>> >> *(.gnu.warning)
>> >> *(.rodata .rodata.*)
>> >> *(.gnu.linkonce.t.*)
>> >> *(.glue_7)
>> >> *(.glue_7t)
>> >> *(.got)
>> >> *(.gcc_except_table)
>> >> *(.gnu.linkonce.r.*)
>> >> _etext = ABSOLUTE(.);
>> >> } > flash
>> >>
>> >> .init_section : {
>> >> _sinit = ABSOLUTE(.);
>> >> *(.init_array .init_array.*)
>> >> _einit = ABSOLUTE(.);
>> >> } > flash
>> >>
>> >> .ARM.extab : {
>> >> *(.ARM.extab*)
>> >> } > flash
>> >>
>> >> __exidx_start = ABSOLUTE(.);
>> >> .ARM.exidx : {
>> >> *(.ARM.exidx*)
>> >> } > flash
>> >> __exidx_end = ABSOLUTE(.);
>> >>
>> >> _eronly = ABSOLUTE(.);
>> >>
>> >> .data : {
>> >> _sdata = ABSOLUTE(.);
>> >> *(.data .data.*)
>> >> *(.gnu.linkonce.d.*)
>> >> CONSTRUCTORS
>> >> _edata = ABSOLUTE(.);
>> >> } > sram AT > flash
>> >>
>> >> .ramfunc ALIGN(4): {
>> >> _sramfuncs = ABSOLUTE(.);
>> >> *(.ramfunc .ramfunc.*)
>> >> _eramfuncs = ABSOLUTE(.);
>> >> } > sram AT > flash
>> >>
>> >> _framfuncs = LOADADDR(.ramfunc);
>> >>
>> >> .bss : {
>> >> _sbss = ABSOLUTE(.);
>> >> *(.bss .bss.*)
>> >> *(.gnu.linkonce.b.*)
>> >> *(COMMON)
>> >> _ebss = ABSOLUTE(.);
>> >> } > sram
>> >>
>> >> To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
>> >> arm/src/samv7/samv7_irq.c
>> >>
>> >> #ifdef CONFIG_ARCH_RAMVECTORS
>> >> /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a
>> RAM-based
>> >> * vector table that requires special initialization.
>> >> */
>> >>
>> >> up_ramvec_initialize();
>> >> #endif
>> >>
>> >> arm/src/armv7-m/up_ramvec_initialize.c
>> >> after we copy the ram vectors:
>> >>
>> >> /* Now configure the NVIC to use the new vector table. */
>> >> putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
>> >>
>> >> and after sam_bringup.c
>> >>
>> >> printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
>> >>
>> >> NVIC: 0x20401180
>> >>
>> >> Looks good.
>> >>
>> >> And yes, still hitting flash on exception:
>> >>
>> >> flash_erasell /dev/mtd0
>> >>
>> >> Whammo - hardfault in openocd monitor:
>> >>
>> >> target halted due to debug-request, current mode: Handler HardFault
>> >> xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
>> >>
>> >> Try to flash the lower 256KB of flash, works like a champ:
>> >>
>> >> nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
>> >>
>> >>
>> ..............................................................................
>> >>
>> >>
>> ..............................................................................
>> >>
>> ..........................................................................
>> >> Installed application of size 233692 bytes to program memory [440000h -
>> >> 4790dch].
>> >> nsh> reboot
>> >>
>> >> So tomorrow, I will maybe move the image to another location in flash
>> and
>> >> hack up the linker script.
>> >> Also do a detailed read on the errata, Petro mentioned there is some
>> >> possible chip bug, maybe that is it ..
>> >> There is some nasty Komodo dragon lurking in there, hissing and
>> snapping
>> >> at
>> >> ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work
>> >> perfectly
>> >> on this codebase.. could also be a timing issue - 300Mhz core clock and
>> >> 150Mhz AHB clock, I will try to slow it down and change the flash wait
>> >> states also ... maybe a bus error is occuring.
>> >>
>> >> I will pick this up again tomorrow, any ideas, please share!
>> >>
>> >> Thank you for your time and attention to this issue...
>> >> -James
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com>
>> wrote:
>> >>
>> >> > On 12/8/2022 5:55 AM, David Sidrane wrote:
>> >> > > Is the NVIC_VTABLE repointed to the RAM vectors?
>> >> >
>> >> > The RAM functions are like .bss: There is a storage area of code
>> that
>> >> > that is copied into RAM only power up. But the symbols associated
>> >> > with the RAMFUNCs are defined by the linker script to be the address
>> >> > of the RAM destination, not the address of the FLASH copy-source
>> storage
>> >> > area:
>> >> >
>> >> > 186 /* Copy any necessary code sections from FLASH to RAM. The
>> >> correct
>> >> > 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs.
>> The
>> >> > 188 * temporary location is in flash after the data initialization
>> >> code
>> >> > 189 * at _framfuncs. This should be done before
>> sam_clockconfig() is
>> >> > 190 * called (in case it has some dependency on initialized C
>> >> > variables).
>> >> > 191 */
>> >> > 192
>> >> > 193 #ifdef CONFIG_ARCH_RAMFUNCS
>> >> > 194 for (src = (const uint32_t *)_framfuncs,
>> >> > 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t
>> *)_eramfuncs;
>> >> > 196 )
>> >> > 197 {
>> >> > 198 *dest++ = *src++;
>> >> > 199 }
>> >> > 200 #endif
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
Thanks Petro,
You are right, or so it seems, but from what I can tell most of this is
working already
and since the armv7-m code is common across STM32 as well that should be ok.
But I did tst and try what you said, it is an easy change because we are in
thumb mode and
the SAMBA bootloader initializes internal SRAM on SAME70. So we make a
small trampoline
by simply renaming __start() in sam_start.c to arm_boot, and add sam_head.S
to implement __start which sets up the initial stack, calls
arm_data_initialize and then jumps to arm_boot()
In arm_data_initialize we zero bss, copy from flash to ram and we don't
need to call arch_clean_dcache because
the cache is in write-through mode (write-through simplifies the cache
coherency protocol because it doesn't need the
modified state - the main memory is always up to date).
I use ISB to throw away any pre-fetched instructions and squash the
pipeline ..
DIffs:
In samv7/Makedefs
-HEAD_ASRC =
+HEAD_ASRC = sam_head.S
In samv7/sam_start.c
-const uintptr_t g_idle_topstack = HEAP_BASE;
+//const uintptr_t g_idle_topstack = HEAP_BASE;
-void __start(void)
+void arm_boot(void)
Copy attached asm file into samv7 directory and rebuild.
Anyhow, it boots, but no difference - still get that exception_common with
a FLASH address... I will have to dig deeper but
do please try the attached and see if it works for you or I missed
something... changes are trivial, it is
a basic m7 copy flash to ram like the armv7-r
Oh yes, related, I was also able to catch an interrupt with symbols:
Program received signal SIGINT, Interrupt.
up_doirq (irq=3, regs=0x20402534 <g_intstackalloc+1844>) at
armv7-m/up_doirq.c:58
58 {
(gdb) up
#1 0x00400a00 in exception_common () at armv7-m/gnu/up_lazyexception.S:237
237 bl up_doirq /* R0=IRQ, R1=register save (msp) */
(gdb) up
Initial frame selected; you cannot go up.
(gdb) down
#0 up_doirq (irq=3, regs=0x20402534 <g_intstackalloc+1844>) at
armv7-m/up_doirq.c:58
58 {
(gdb)
up_irq in ram but exception_common still in flash, I wonder why we hit that
IRQ (Hardfault).
Thanks and let me know what you think.
Best regards
-James
On Fri, Dec 9, 2022 at 2:24 AM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> In order to have the possibility to reprogram the whole internal flash you
> will need to implement CONFIG_BOOT_COPYTORAM option in sam_start.c and
> create a proper linker script.
> Maybe even you will need to move the __start routine to the assembly file
> because after copying code to RAM you will need to drain the instruction
> pipeline before jumping to relocated code and that will require making sure
> that start-up is done in position independent code and just to the
> relocated code will not use relative offset jumps.
>
> Best regards,
> Petro
>
> пт, 9 груд. 2022 р. о 12:18 Petro Karashchenko <
> petro.karashchenko@gmail.com>
> пише:
>
> > Hi,
> >
> > Finally I was able to take a look here. The case is that armv7-m (and
> some
> > other ARM versions) do not use arm_head.S and __start entry points are
> > implemented in C code and CONFIG_BOOT_COPYTORAM option is not
> implemented,
> > so code is always executed from internal flash. So when you are trying to
> > erase all internal flash you are getting an exception and that is
> expected.
> > Currently the CONFIG_ARCH_RAMFUNCS only copies functions marked with
> > __ramfunc__ attribute. The internal flash access APIs should be in SRAM
> > because that is a requirement of flash access, uness IAP is used to
> access
> > flash. I will try to push the IAP version and remove many of EEFC APIs.
> >
> > The MCUboot variant works because MCUboot is located at the separate
> flash
> > partition and erase/reprogram only application slots. I mean that MCUboot
> > can't update itself.
> >
> > Even having CONFIG_ARCH_RAMVECTORS enabled you will not be able to
> > reprogram the whole internal flash because of the above.
> >
> > Best regards,
> > Petro
> >
> > пт, 9 груд. 2022 р. о 07:56 David Sidrane <da...@nscdg.com>
> пише:
> >
> >> Have you ensured that all the code (and support code, systic etc) is in
> >> RAM?
> >>
> >> Also, Is this an ECCed FLASH? Is the write size correct? We must line
> >> cache
> >> the writes on some parts in the PX4 bootloader.
> >>
> >>
> >>
> https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
> >>
> >>
> >> David
> >> -----Original Message-----
> >> From: James Dougherty <ja...@gmail.com>
> >> Sent: Friday, December 9, 2022 12:46 AM
> >> To: dev@nuttx.apache.org
> >> Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
> >>
> >> Thank you Greg, Thank you David!
> >>
> >> I did check that is correct:
> >>
> >> arch/arm/src/samv7/sam_start.c - 344:356
> >>
> >> /* Copy any necessary code sections from FLASH to RAM. The correct
> >> * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> >> * temporary location is in flash after the data initialization code
> >> * at _framfuncs. This should be done before sam_clockconfig() is
> >> * called (in case it has some dependency on initialized C variables).
> >> */
> >>
> >> #ifdef CONFIG_ARCH_RAMFUNCS
> >> for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
> >> {
> >> *dest++ = *src++;
> >> }
> >> #endif
> >>
> >> Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
> >> 36:113
> >>
> >> /* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000
> and
> >> * 384Kb of SRAM beginining at 0x2040:0000
> >> *
> >> * When booting from FLASH, FLASH memory is aliased to address
> 0x0000:0000
> >> * where the code expects to begin execution by jumping to the entry
> point
> >> in
> >> * the 0x0400:0000 address range (Assuming that ITCM is not enable).
> >> */
> >>
> >> MEMORY
> >> {
> >> flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
> >> 0x20400000, LENGTH = 384K }
> >>
> >> OUTPUT_ARCH(arm)
> >> EXTERN(_vectors)
> >> ENTRY(_stext)
> >>
> >> SECTIONS
> >> {
> >> .text : {
> >> _stext = ABSOLUTE(.);
> >> *(.vectors)
> >> *(.text .text.*)
> >> *(.fixup)
> >> *(.gnu.warning)
> >> *(.rodata .rodata.*)
> >> *(.gnu.linkonce.t.*)
> >> *(.glue_7)
> >> *(.glue_7t)
> >> *(.got)
> >> *(.gcc_except_table)
> >> *(.gnu.linkonce.r.*)
> >> _etext = ABSOLUTE(.);
> >> } > flash
> >>
> >> .init_section : {
> >> _sinit = ABSOLUTE(.);
> >> *(.init_array .init_array.*)
> >> _einit = ABSOLUTE(.);
> >> } > flash
> >>
> >> .ARM.extab : {
> >> *(.ARM.extab*)
> >> } > flash
> >>
> >> __exidx_start = ABSOLUTE(.);
> >> .ARM.exidx : {
> >> *(.ARM.exidx*)
> >> } > flash
> >> __exidx_end = ABSOLUTE(.);
> >>
> >> _eronly = ABSOLUTE(.);
> >>
> >> .data : {
> >> _sdata = ABSOLUTE(.);
> >> *(.data .data.*)
> >> *(.gnu.linkonce.d.*)
> >> CONSTRUCTORS
> >> _edata = ABSOLUTE(.);
> >> } > sram AT > flash
> >>
> >> .ramfunc ALIGN(4): {
> >> _sramfuncs = ABSOLUTE(.);
> >> *(.ramfunc .ramfunc.*)
> >> _eramfuncs = ABSOLUTE(.);
> >> } > sram AT > flash
> >>
> >> _framfuncs = LOADADDR(.ramfunc);
> >>
> >> .bss : {
> >> _sbss = ABSOLUTE(.);
> >> *(.bss .bss.*)
> >> *(.gnu.linkonce.b.*)
> >> *(COMMON)
> >> _ebss = ABSOLUTE(.);
> >> } > sram
> >>
> >> To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
> >> arm/src/samv7/samv7_irq.c
> >>
> >> #ifdef CONFIG_ARCH_RAMVECTORS
> >> /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
> >> * vector table that requires special initialization.
> >> */
> >>
> >> up_ramvec_initialize();
> >> #endif
> >>
> >> arm/src/armv7-m/up_ramvec_initialize.c
> >> after we copy the ram vectors:
> >>
> >> /* Now configure the NVIC to use the new vector table. */
> >> putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
> >>
> >> and after sam_bringup.c
> >>
> >> printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
> >>
> >> NVIC: 0x20401180
> >>
> >> Looks good.
> >>
> >> And yes, still hitting flash on exception:
> >>
> >> flash_erasell /dev/mtd0
> >>
> >> Whammo - hardfault in openocd monitor:
> >>
> >> target halted due to debug-request, current mode: Handler HardFault
> >> xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
> >>
> >> Try to flash the lower 256KB of flash, works like a champ:
> >>
> >> nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
> >>
> >>
> ..............................................................................
> >>
> >>
> ..............................................................................
> >>
> ..........................................................................
> >> Installed application of size 233692 bytes to program memory [440000h -
> >> 4790dch].
> >> nsh> reboot
> >>
> >> So tomorrow, I will maybe move the image to another location in flash
> and
> >> hack up the linker script.
> >> Also do a detailed read on the errata, Petro mentioned there is some
> >> possible chip bug, maybe that is it ..
> >> There is some nasty Komodo dragon lurking in there, hissing and snapping
> >> at
> >> ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work
> >> perfectly
> >> on this codebase.. could also be a timing issue - 300Mhz core clock and
> >> 150Mhz AHB clock, I will try to slow it down and change the flash wait
> >> states also ... maybe a bus error is occuring.
> >>
> >> I will pick this up again tomorrow, any ideas, please share!
> >>
> >> Thank you for your time and attention to this issue...
> >> -James
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com>
> wrote:
> >>
> >> > On 12/8/2022 5:55 AM, David Sidrane wrote:
> >> > > Is the NVIC_VTABLE repointed to the RAM vectors?
> >> >
> >> > The RAM functions are like .bss: There is a storage area of code that
> >> > that is copied into RAM only power up. But the symbols associated
> >> > with the RAMFUNCs are defined by the linker script to be the address
> >> > of the RAM destination, not the address of the FLASH copy-source
> storage
> >> > area:
> >> >
> >> > 186 /* Copy any necessary code sections from FLASH to RAM. The
> >> correct
> >> > 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs.
> The
> >> > 188 * temporary location is in flash after the data initialization
> >> code
> >> > 189 * at _framfuncs. This should be done before sam_clockconfig()
> is
> >> > 190 * called (in case it has some dependency on initialized C
> >> > variables).
> >> > 191 */
> >> > 192
> >> > 193 #ifdef CONFIG_ARCH_RAMFUNCS
> >> > 194 for (src = (const uint32_t *)_framfuncs,
> >> > 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t
> *)_eramfuncs;
> >> > 196 )
> >> > 197 {
> >> > 198 *dest++ = *src++;
> >> > 199 }
> >> > 200 #endif
> >> >
> >> >
> >>
> >
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by Petro Karashchenko <pe...@gmail.com>.
In order to have the possibility to reprogram the whole internal flash you
will need to implement CONFIG_BOOT_COPYTORAM option in sam_start.c and
create a proper linker script.
Maybe even you will need to move the __start routine to the assembly file
because after copying code to RAM you will need to drain the instruction
pipeline before jumping to relocated code and that will require making sure
that start-up is done in position independent code and just to the
relocated code will not use relative offset jumps.
Best regards,
Petro
пт, 9 груд. 2022 р. о 12:18 Petro Karashchenko <pe...@gmail.com>
пише:
> Hi,
>
> Finally I was able to take a look here. The case is that armv7-m (and some
> other ARM versions) do not use arm_head.S and __start entry points are
> implemented in C code and CONFIG_BOOT_COPYTORAM option is not implemented,
> so code is always executed from internal flash. So when you are trying to
> erase all internal flash you are getting an exception and that is expected.
> Currently the CONFIG_ARCH_RAMFUNCS only copies functions marked with
> __ramfunc__ attribute. The internal flash access APIs should be in SRAM
> because that is a requirement of flash access, uness IAP is used to access
> flash. I will try to push the IAP version and remove many of EEFC APIs.
>
> The MCUboot variant works because MCUboot is located at the separate flash
> partition and erase/reprogram only application slots. I mean that MCUboot
> can't update itself.
>
> Even having CONFIG_ARCH_RAMVECTORS enabled you will not be able to
> reprogram the whole internal flash because of the above.
>
> Best regards,
> Petro
>
> пт, 9 груд. 2022 р. о 07:56 David Sidrane <da...@nscdg.com> пише:
>
>> Have you ensured that all the code (and support code, systic etc) is in
>> RAM?
>>
>> Also, Is this an ECCed FLASH? Is the write size correct? We must line
>> cache
>> the writes on some parts in the PX4 bootloader.
>>
>>
>> https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
>>
>>
>> David
>> -----Original Message-----
>> From: James Dougherty <ja...@gmail.com>
>> Sent: Friday, December 9, 2022 12:46 AM
>> To: dev@nuttx.apache.org
>> Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
>>
>> Thank you Greg, Thank you David!
>>
>> I did check that is correct:
>>
>> arch/arm/src/samv7/sam_start.c - 344:356
>>
>> /* Copy any necessary code sections from FLASH to RAM. The correct
>> * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
>> * temporary location is in flash after the data initialization code
>> * at _framfuncs. This should be done before sam_clockconfig() is
>> * called (in case it has some dependency on initialized C variables).
>> */
>>
>> #ifdef CONFIG_ARCH_RAMFUNCS
>> for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
>> {
>> *dest++ = *src++;
>> }
>> #endif
>>
>> Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
>> 36:113
>>
>> /* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000 and
>> * 384Kb of SRAM beginining at 0x2040:0000
>> *
>> * When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
>> * where the code expects to begin execution by jumping to the entry point
>> in
>> * the 0x0400:0000 address range (Assuming that ITCM is not enable).
>> */
>>
>> MEMORY
>> {
>> flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
>> 0x20400000, LENGTH = 384K }
>>
>> OUTPUT_ARCH(arm)
>> EXTERN(_vectors)
>> ENTRY(_stext)
>>
>> SECTIONS
>> {
>> .text : {
>> _stext = ABSOLUTE(.);
>> *(.vectors)
>> *(.text .text.*)
>> *(.fixup)
>> *(.gnu.warning)
>> *(.rodata .rodata.*)
>> *(.gnu.linkonce.t.*)
>> *(.glue_7)
>> *(.glue_7t)
>> *(.got)
>> *(.gcc_except_table)
>> *(.gnu.linkonce.r.*)
>> _etext = ABSOLUTE(.);
>> } > flash
>>
>> .init_section : {
>> _sinit = ABSOLUTE(.);
>> *(.init_array .init_array.*)
>> _einit = ABSOLUTE(.);
>> } > flash
>>
>> .ARM.extab : {
>> *(.ARM.extab*)
>> } > flash
>>
>> __exidx_start = ABSOLUTE(.);
>> .ARM.exidx : {
>> *(.ARM.exidx*)
>> } > flash
>> __exidx_end = ABSOLUTE(.);
>>
>> _eronly = ABSOLUTE(.);
>>
>> .data : {
>> _sdata = ABSOLUTE(.);
>> *(.data .data.*)
>> *(.gnu.linkonce.d.*)
>> CONSTRUCTORS
>> _edata = ABSOLUTE(.);
>> } > sram AT > flash
>>
>> .ramfunc ALIGN(4): {
>> _sramfuncs = ABSOLUTE(.);
>> *(.ramfunc .ramfunc.*)
>> _eramfuncs = ABSOLUTE(.);
>> } > sram AT > flash
>>
>> _framfuncs = LOADADDR(.ramfunc);
>>
>> .bss : {
>> _sbss = ABSOLUTE(.);
>> *(.bss .bss.*)
>> *(.gnu.linkonce.b.*)
>> *(COMMON)
>> _ebss = ABSOLUTE(.);
>> } > sram
>>
>> To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
>> arm/src/samv7/samv7_irq.c
>>
>> #ifdef CONFIG_ARCH_RAMVECTORS
>> /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
>> * vector table that requires special initialization.
>> */
>>
>> up_ramvec_initialize();
>> #endif
>>
>> arm/src/armv7-m/up_ramvec_initialize.c
>> after we copy the ram vectors:
>>
>> /* Now configure the NVIC to use the new vector table. */
>> putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
>>
>> and after sam_bringup.c
>>
>> printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
>>
>> NVIC: 0x20401180
>>
>> Looks good.
>>
>> And yes, still hitting flash on exception:
>>
>> flash_erasell /dev/mtd0
>>
>> Whammo - hardfault in openocd monitor:
>>
>> target halted due to debug-request, current mode: Handler HardFault
>> xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
>>
>> Try to flash the lower 256KB of flash, works like a champ:
>>
>> nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
>>
>> ..............................................................................
>>
>> ..............................................................................
>> ..........................................................................
>> Installed application of size 233692 bytes to program memory [440000h -
>> 4790dch].
>> nsh> reboot
>>
>> So tomorrow, I will maybe move the image to another location in flash and
>> hack up the linker script.
>> Also do a detailed read on the errata, Petro mentioned there is some
>> possible chip bug, maybe that is it ..
>> There is some nasty Komodo dragon lurking in there, hissing and snapping
>> at
>> ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work
>> perfectly
>> on this codebase.. could also be a timing issue - 300Mhz core clock and
>> 150Mhz AHB clock, I will try to slow it down and change the flash wait
>> states also ... maybe a bus error is occuring.
>>
>> I will pick this up again tomorrow, any ideas, please share!
>>
>> Thank you for your time and attention to this issue...
>> -James
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com> wrote:
>>
>> > On 12/8/2022 5:55 AM, David Sidrane wrote:
>> > > Is the NVIC_VTABLE repointed to the RAM vectors?
>> >
>> > The RAM functions are like .bss: There is a storage area of code that
>> > that is copied into RAM only power up. But the symbols associated
>> > with the RAMFUNCs are defined by the linker script to be the address
>> > of the RAM destination, not the address of the FLASH copy-source storage
>> > area:
>> >
>> > 186 /* Copy any necessary code sections from FLASH to RAM. The
>> correct
>> > 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
>> > 188 * temporary location is in flash after the data initialization
>> code
>> > 189 * at _framfuncs. This should be done before sam_clockconfig() is
>> > 190 * called (in case it has some dependency on initialized C
>> > variables).
>> > 191 */
>> > 192
>> > 193 #ifdef CONFIG_ARCH_RAMFUNCS
>> > 194 for (src = (const uint32_t *)_framfuncs,
>> > 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
>> > 196 )
>> > 197 {
>> > 198 *dest++ = *src++;
>> > 199 }
>> > 200 #endif
>> >
>> >
>>
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by Petro Karashchenko <pe...@gmail.com>.
Hi,
Finally I was able to take a look here. The case is that armv7-m (and some
other ARM versions) do not use arm_head.S and __start entry points are
implemented in C code and CONFIG_BOOT_COPYTORAM option is not implemented,
so code is always executed from internal flash. So when you are trying to
erase all internal flash you are getting an exception and that is expected.
Currently the CONFIG_ARCH_RAMFUNCS only copies functions marked with
__ramfunc__ attribute. The internal flash access APIs should be in SRAM
because that is a requirement of flash access, uness IAP is used to access
flash. I will try to push the IAP version and remove many of EEFC APIs.
The MCUboot variant works because MCUboot is located at the separate flash
partition and erase/reprogram only application slots. I mean that MCUboot
can't update itself.
Even having CONFIG_ARCH_RAMVECTORS enabled you will not be able to
reprogram the whole internal flash because of the above.
Best regards,
Petro
пт, 9 груд. 2022 р. о 07:56 David Sidrane <da...@nscdg.com> пише:
> Have you ensured that all the code (and support code, systic etc) is in
> RAM?
>
> Also, Is this an ECCed FLASH? Is the write size correct? We must line cache
> the writes on some parts in the PX4 bootloader.
>
>
> https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
>
>
> David
> -----Original Message-----
> From: James Dougherty <ja...@gmail.com>
> Sent: Friday, December 9, 2022 12:46 AM
> To: dev@nuttx.apache.org
> Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
>
> Thank you Greg, Thank you David!
>
> I did check that is correct:
>
> arch/arm/src/samv7/sam_start.c - 344:356
>
> /* Copy any necessary code sections from FLASH to RAM. The correct
> * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> * temporary location is in flash after the data initialization code
> * at _framfuncs. This should be done before sam_clockconfig() is
> * called (in case it has some dependency on initialized C variables).
> */
>
> #ifdef CONFIG_ARCH_RAMFUNCS
> for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
> {
> *dest++ = *src++;
> }
> #endif
>
> Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
> 36:113
>
> /* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000 and
> * 384Kb of SRAM beginining at 0x2040:0000
> *
> * When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
> * where the code expects to begin execution by jumping to the entry point
> in
> * the 0x0400:0000 address range (Assuming that ITCM is not enable).
> */
>
> MEMORY
> {
> flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
> 0x20400000, LENGTH = 384K }
>
> OUTPUT_ARCH(arm)
> EXTERN(_vectors)
> ENTRY(_stext)
>
> SECTIONS
> {
> .text : {
> _stext = ABSOLUTE(.);
> *(.vectors)
> *(.text .text.*)
> *(.fixup)
> *(.gnu.warning)
> *(.rodata .rodata.*)
> *(.gnu.linkonce.t.*)
> *(.glue_7)
> *(.glue_7t)
> *(.got)
> *(.gcc_except_table)
> *(.gnu.linkonce.r.*)
> _etext = ABSOLUTE(.);
> } > flash
>
> .init_section : {
> _sinit = ABSOLUTE(.);
> *(.init_array .init_array.*)
> _einit = ABSOLUTE(.);
> } > flash
>
> .ARM.extab : {
> *(.ARM.extab*)
> } > flash
>
> __exidx_start = ABSOLUTE(.);
> .ARM.exidx : {
> *(.ARM.exidx*)
> } > flash
> __exidx_end = ABSOLUTE(.);
>
> _eronly = ABSOLUTE(.);
>
> .data : {
> _sdata = ABSOLUTE(.);
> *(.data .data.*)
> *(.gnu.linkonce.d.*)
> CONSTRUCTORS
> _edata = ABSOLUTE(.);
> } > sram AT > flash
>
> .ramfunc ALIGN(4): {
> _sramfuncs = ABSOLUTE(.);
> *(.ramfunc .ramfunc.*)
> _eramfuncs = ABSOLUTE(.);
> } > sram AT > flash
>
> _framfuncs = LOADADDR(.ramfunc);
>
> .bss : {
> _sbss = ABSOLUTE(.);
> *(.bss .bss.*)
> *(.gnu.linkonce.b.*)
> *(COMMON)
> _ebss = ABSOLUTE(.);
> } > sram
>
> To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
> arm/src/samv7/samv7_irq.c
>
> #ifdef CONFIG_ARCH_RAMVECTORS
> /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
> * vector table that requires special initialization.
> */
>
> up_ramvec_initialize();
> #endif
>
> arm/src/armv7-m/up_ramvec_initialize.c
> after we copy the ram vectors:
>
> /* Now configure the NVIC to use the new vector table. */
> putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
>
> and after sam_bringup.c
>
> printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
>
> NVIC: 0x20401180
>
> Looks good.
>
> And yes, still hitting flash on exception:
>
> flash_erasell /dev/mtd0
>
> Whammo - hardfault in openocd monitor:
>
> target halted due to debug-request, current mode: Handler HardFault
> xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
>
> Try to flash the lower 256KB of flash, works like a champ:
>
> nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
>
> ..............................................................................
>
> ..............................................................................
> ..........................................................................
> Installed application of size 233692 bytes to program memory [440000h -
> 4790dch].
> nsh> reboot
>
> So tomorrow, I will maybe move the image to another location in flash and
> hack up the linker script.
> Also do a detailed read on the errata, Petro mentioned there is some
> possible chip bug, maybe that is it ..
> There is some nasty Komodo dragon lurking in there, hissing and snapping at
> ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work
> perfectly
> on this codebase.. could also be a timing issue - 300Mhz core clock and
> 150Mhz AHB clock, I will try to slow it down and change the flash wait
> states also ... maybe a bus error is occuring.
>
> I will pick this up again tomorrow, any ideas, please share!
>
> Thank you for your time and attention to this issue...
> -James
>
>
>
>
>
>
>
> On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> > On 12/8/2022 5:55 AM, David Sidrane wrote:
> > > Is the NVIC_VTABLE repointed to the RAM vectors?
> >
> > The RAM functions are like .bss: There is a storage area of code that
> > that is copied into RAM only power up. But the symbols associated
> > with the RAMFUNCs are defined by the linker script to be the address
> > of the RAM destination, not the address of the FLASH copy-source storage
> > area:
> >
> > 186 /* Copy any necessary code sections from FLASH to RAM. The correct
> > 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> > 188 * temporary location is in flash after the data initialization
> code
> > 189 * at _framfuncs. This should be done before sam_clockconfig() is
> > 190 * called (in case it has some dependency on initialized C
> > variables).
> > 191 */
> > 192
> > 193 #ifdef CONFIG_ARCH_RAMFUNCS
> > 194 for (src = (const uint32_t *)_framfuncs,
> > 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
> > 196 )
> > 197 {
> > 198 *dest++ = *src++;
> > 199 }
> > 200 #endif
> >
> >
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
> Have you ensured that all the code (and support code, systic etc) is in
RAM?
Primarily yes, besides the general setting breakpoints and seeing stuff end
up in ram, that is all good.
I also did some deep dive analysis before and after using GDB memory dumps
and objdump ..
Disassemble nuttx from ELF && BIN, remap address to sram:
arm-none-eabi-objdump -D nuttx > nuttx-full-dis.txt
arm-none-eabi-objdump --adjust-vma=0x20400000 -D -bbinary -marm nuttx.bin
-Mforce-thumb > nuttx-ram-dis.txt
arm-none-eabi-objdump --adjust-vma=0x00040000 -D -bbinary -marm nuttx.bin
-Mforce-thumb > nuttx-flash-dis.txt
Disassemble live capture of sram memory from GDB while relocating to ram
(as nuttx would):
arm-none-eabi-objdump --adjust-vma=0x20400000 -D -bbinary -marm sram.bin
-Mforce-thumb > sram-reloc-dis.txt
arm-none-eabi-objdump -D -bbinary -marm sram.bin -Mforce-thumb >
sram-dis.txt
Disassemble raw flash binary while pretending to be relocated from FLASH to
SRAM (for addresses to be the same in diff):
arm-none-eabi-objdump --adjust-vma=0x20400000 -D -bbinary -marm flash.bin
-Mforce-thumb > flash-ram-reloc-dis.txt
Disassemble raw flash binary while pretending to be relocated from FLASH to
SRAM (for addresses to be the same) and zero based:
arm-none-eabi-objdump --adjust-vma=0x00040000 -D -bbinary -marm flash.bin
-Mforce-thumb > flash-base-dis.txt
arm-none-eabi-objdump -D -bbinary -marm flash.bin -Mforce-thumb >
flash-dis.txt
postmortem invariants of flash memory diffs confirm the flash programming
worked correctly, they are the same
(except for the unused sectors which read all 1's - 0xffffffff):
diff nuttx-flash-dis.txt flash-dis.txt
Compare flash dissasembly to sram dissasembly:
diff sram-dis.txt flash-dis.txt
They show almost the same except for the relocations, removing the remap of
memory
addresses will help confirm which parts are different also so generally we
are running out of ram.
I can find some differences, I consult nuttx-full.dis as an oracle for the
missing symbols & basic block
analysis shows the code was basically relocated. I can also set breakpoints
on functions
I am running and see they hit ram addresses so that is all good. But yes,
you are right, possibly
I am missing some __ramfunc__ tagging on critical code, yes, that is
another round of debug now
from userland apps.
> Also, Is this an ECCed FLASH? Is the write size correct? We must line
cache the writes on some parts in the PX4 bootloader.
Nope. But the FLASH driver works great, Petro made some nice mods for this.
The original one Greg wrote
seems to work the same as Petro's changes which has the critical
programming routines for the
Enhanced Embedded Flash Controller (EEFC) tagged as __ramfuncs__ - I made
the same changes to gregs
driver which had all of the EEFC integrated. Same flash programming
sequence, writes the first page and hang.
>
https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
Nice! Thanks for the references, yes, I have checked out PX4 bootloader, it
is a work of art. I fly 550/1100 hex/quads with
at least one of my own builds on several pixhawk boards. FYI, I am not
using a bootloader for this experiment,
I am flashing from OpenOCD, running and getting into memory, and then
in-system programming myself from
the SD-Card. It should work fine so long as the signature matches the
SD-Card and you don't power-down of course.
Thank you for these pointers, that is one line of debug I should continued
- look for missing __ramfuncs__
On Thu, Dec 8, 2022 at 9:56 PM David Sidrane <da...@nscdg.com>
wrote:
> Have you ensured that all the code (and support code, systic etc) is in
> RAM?
>
> Also, Is this an ECCed FLASH? Is the write size correct? We must line cache
> the writes on some parts in the PX4 bootloader.
>
>
> https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
>
>
> David
> -----Original Message-----
> From: James Dougherty <ja...@gmail.com>
> Sent: Friday, December 9, 2022 12:46 AM
> To: dev@nuttx.apache.org
> Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
>
> Thank you Greg, Thank you David!
>
> I did check that is correct:
>
> arch/arm/src/samv7/sam_start.c - 344:356
>
> /* Copy any necessary code sections from FLASH to RAM. The correct
> * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> * temporary location is in flash after the data initialization code
> * at _framfuncs. This should be done before sam_clockconfig() is
> * called (in case it has some dependency on initialized C variables).
> */
>
> #ifdef CONFIG_ARCH_RAMFUNCS
> for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
> {
> *dest++ = *src++;
> }
> #endif
>
> Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
> 36:113
>
> /* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000 and
> * 384Kb of SRAM beginining at 0x2040:0000
> *
> * When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
> * where the code expects to begin execution by jumping to the entry point
> in
> * the 0x0400:0000 address range (Assuming that ITCM is not enable).
> */
>
> MEMORY
> {
> flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
> 0x20400000, LENGTH = 384K }
>
> OUTPUT_ARCH(arm)
> EXTERN(_vectors)
> ENTRY(_stext)
>
> SECTIONS
> {
> .text : {
> _stext = ABSOLUTE(.);
> *(.vectors)
> *(.text .text.*)
> *(.fixup)
> *(.gnu.warning)
> *(.rodata .rodata.*)
> *(.gnu.linkonce.t.*)
> *(.glue_7)
> *(.glue_7t)
> *(.got)
> *(.gcc_except_table)
> *(.gnu.linkonce.r.*)
> _etext = ABSOLUTE(.);
> } > flash
>
> .init_section : {
> _sinit = ABSOLUTE(.);
> *(.init_array .init_array.*)
> _einit = ABSOLUTE(.);
> } > flash
>
> .ARM.extab : {
> *(.ARM.extab*)
> } > flash
>
> __exidx_start = ABSOLUTE(.);
> .ARM.exidx : {
> *(.ARM.exidx*)
> } > flash
> __exidx_end = ABSOLUTE(.);
>
> _eronly = ABSOLUTE(.);
>
> .data : {
> _sdata = ABSOLUTE(.);
> *(.data .data.*)
> *(.gnu.linkonce.d.*)
> CONSTRUCTORS
> _edata = ABSOLUTE(.);
> } > sram AT > flash
>
> .ramfunc ALIGN(4): {
> _sramfuncs = ABSOLUTE(.);
> *(.ramfunc .ramfunc.*)
> _eramfuncs = ABSOLUTE(.);
> } > sram AT > flash
>
> _framfuncs = LOADADDR(.ramfunc);
>
> .bss : {
> _sbss = ABSOLUTE(.);
> *(.bss .bss.*)
> *(.gnu.linkonce.b.*)
> *(COMMON)
> _ebss = ABSOLUTE(.);
> } > sram
>
> To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
> arm/src/samv7/samv7_irq.c
>
> #ifdef CONFIG_ARCH_RAMVECTORS
> /* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
> * vector table that requires special initialization.
> */
>
> up_ramvec_initialize();
> #endif
>
> arm/src/armv7-m/up_ramvec_initialize.c
> after we copy the ram vectors:
>
> /* Now configure the NVIC to use the new vector table. */
> putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
>
> and after sam_bringup.c
>
> printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
>
> NVIC: 0x20401180
>
> Looks good.
>
> And yes, still hitting flash on exception:
>
> flash_erasell /dev/mtd0
>
> Whammo - hardfault in openocd monitor:
>
> target halted due to debug-request, current mode: Handler HardFault
> xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
>
> Try to flash the lower 256KB of flash, works like a champ:
>
> nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
>
> ..............................................................................
>
> ..............................................................................
> ..........................................................................
> Installed application of size 233692 bytes to program memory [440000h -
> 4790dch].
> nsh> reboot
>
> So tomorrow, I will maybe move the image to another location in flash and
> hack up the linker script.
> Also do a detailed read on the errata, Petro mentioned there is some
> possible chip bug, maybe that is it ..
> There is some nasty Komodo dragon lurking in there, hissing and snapping at
> ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work
> perfectly
> on this codebase.. could also be a timing issue - 300Mhz core clock and
> 150Mhz AHB clock, I will try to slow it down and change the flash wait
> states also ... maybe a bus error is occuring.
>
> I will pick this up again tomorrow, any ideas, please share!
>
> Thank you for your time and attention to this issue...
> -James
>
>
>
>
>
>
>
> On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> > On 12/8/2022 5:55 AM, David Sidrane wrote:
> > > Is the NVIC_VTABLE repointed to the RAM vectors?
> >
> > The RAM functions are like .bss: There is a storage area of code that
> > that is copied into RAM only power up. But the symbols associated
> > with the RAMFUNCs are defined by the linker script to be the address
> > of the RAM destination, not the address of the FLASH copy-source storage
> > area:
> >
> > 186 /* Copy any necessary code sections from FLASH to RAM. The correct
> > 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> > 188 * temporary location is in flash after the data initialization
> code
> > 189 * at _framfuncs. This should be done before sam_clockconfig() is
> > 190 * called (in case it has some dependency on initialized C
> > variables).
> > 191 */
> > 192
> > 193 #ifdef CONFIG_ARCH_RAMFUNCS
> > 194 for (src = (const uint32_t *)_framfuncs,
> > 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
> > 196 )
> > 197 {
> > 198 *dest++ = *src++;
> > 199 }
> > 200 #endif
> >
> >
>
RE: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by David Sidrane <da...@nscdg.com>.
Have you ensured that all the code (and support code, systic etc) is in RAM?
Also, Is this an ECCed FLASH? Is the write size correct? We must line cache
the writes on some parts in the PX4 bootloader.
https://github.com/PX4/PX4-Autopilot/blob/main/platforms/nuttx/src/bootloader/common/lib/flash_cache.c
David
-----Original Message-----
From: James Dougherty <ja...@gmail.com>
Sent: Friday, December 9, 2022 12:46 AM
To: dev@nuttx.apache.org
Subject: Re: SAM-E70 progmem - in system programming and RAMFUNCS
Thank you Greg, Thank you David!
I did check that is correct:
arch/arm/src/samv7/sam_start.c - 344:356
/* Copy any necessary code sections from FLASH to RAM. The correct
* destination in SRAM is geive by _sramfuncs and _eramfuncs. The
* temporary location is in flash after the data initialization code
* at _framfuncs. This should be done before sam_clockconfig() is
* called (in case it has some dependency on initialized C variables).
*/
#ifdef CONFIG_ARCH_RAMFUNCS
for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
{
*dest++ = *src++;
}
#endif
Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
36:113
/* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000 and
* 384Kb of SRAM beginining at 0x2040:0000
*
* When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
* where the code expects to begin execution by jumping to the entry point
in
* the 0x0400:0000 address range (Assuming that ITCM is not enable).
*/
MEMORY
{
flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K sram (rwx) : ORIGIN =
0x20400000, LENGTH = 384K }
OUTPUT_ARCH(arm)
EXTERN(_vectors)
ENTRY(_stext)
SECTIONS
{
.text : {
_stext = ABSOLUTE(.);
*(.vectors)
*(.text .text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata .rodata.*)
*(.gnu.linkonce.t.*)
*(.glue_7)
*(.glue_7t)
*(.got)
*(.gcc_except_table)
*(.gnu.linkonce.r.*)
_etext = ABSOLUTE(.);
} > flash
.init_section : {
_sinit = ABSOLUTE(.);
*(.init_array .init_array.*)
_einit = ABSOLUTE(.);
} > flash
.ARM.extab : {
*(.ARM.extab*)
} > flash
__exidx_start = ABSOLUTE(.);
.ARM.exidx : {
*(.ARM.exidx*)
} > flash
__exidx_end = ABSOLUTE(.);
_eronly = ABSOLUTE(.);
.data : {
_sdata = ABSOLUTE(.);
*(.data .data.*)
*(.gnu.linkonce.d.*)
CONSTRUCTORS
_edata = ABSOLUTE(.);
} > sram AT > flash
.ramfunc ALIGN(4): {
_sramfuncs = ABSOLUTE(.);
*(.ramfunc .ramfunc.*)
_eramfuncs = ABSOLUTE(.);
} > sram AT > flash
_framfuncs = LOADADDR(.ramfunc);
.bss : {
_sbss = ABSOLUTE(.);
*(.bss .bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
_ebss = ABSOLUTE(.);
} > sram
To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
arm/src/samv7/samv7_irq.c
#ifdef CONFIG_ARCH_RAMVECTORS
/* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
* vector table that requires special initialization.
*/
up_ramvec_initialize();
#endif
arm/src/armv7-m/up_ramvec_initialize.c
after we copy the ram vectors:
/* Now configure the NVIC to use the new vector table. */
putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
and after sam_bringup.c
printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
NVIC: 0x20401180
Looks good.
And yes, still hitting flash on exception:
flash_erasell /dev/mtd0
Whammo - hardfault in openocd monitor:
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
Try to flash the lower 256KB of flash, works like a champ:
nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
..............................................................................
..............................................................................
..........................................................................
Installed application of size 233692 bytes to program memory [440000h -
4790dch].
nsh> reboot
So tomorrow, I will maybe move the image to another location in flash and
hack up the linker script.
Also do a detailed read on the errata, Petro mentioned there is some
possible chip bug, maybe that is it ..
There is some nasty Komodo dragon lurking in there, hissing and snapping at
ankles ... SAMV7 doesn't work like an STM32F1/F4/F7 which all work perfectly
on this codebase.. could also be a timing issue - 300Mhz core clock and
150Mhz AHB clock, I will try to slow it down and change the flash wait
states also ... maybe a bus error is occuring.
I will pick this up again tomorrow, any ideas, please share!
Thank you for your time and attention to this issue...
-James
On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com> wrote:
> On 12/8/2022 5:55 AM, David Sidrane wrote:
> > Is the NVIC_VTABLE repointed to the RAM vectors?
>
> The RAM functions are like .bss: There is a storage area of code that
> that is copied into RAM only power up. But the symbols associated
> with the RAMFUNCs are defined by the linker script to be the address
> of the RAM destination, not the address of the FLASH copy-source storage
> area:
>
> 186 /* Copy any necessary code sections from FLASH to RAM. The correct
> 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> 188 * temporary location is in flash after the data initialization code
> 189 * at _framfuncs. This should be done before sam_clockconfig() is
> 190 * called (in case it has some dependency on initialized C
> variables).
> 191 */
> 192
> 193 #ifdef CONFIG_ARCH_RAMFUNCS
> 194 for (src = (const uint32_t *)_framfuncs,
> 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
> 196 )
> 197 {
> 198 *dest++ = *src++;
> 199 }
> 200 #endif
>
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
Thank you Greg, Thank you David!
I did check that is correct:
arch/arm/src/samv7/sam_start.c - 344:356
/* Copy any necessary code sections from FLASH to RAM. The correct
* destination in SRAM is geive by _sramfuncs and _eramfuncs. The
* temporary location is in flash after the data initialization code
* at _framfuncs. This should be done before sam_clockconfig() is
* called (in case it has some dependency on initialized C variables).
*/
#ifdef CONFIG_ARCH_RAMFUNCS
for (src = &_framfuncs, dest = &_sramfuncs; dest < &_eramfuncs; )
{
*dest++ = *src++;
}
#endif
Also looks correct - in: same70-xplained/samv7-scripts/flash-sram.ld -
36:113
/* The SAME70Q21 has 2048Kb of FLASH beginning at address 0x0040:0000 and
* 384Kb of SRAM beginining at 0x2040:0000
*
* When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
* where the code expects to begin execution by jumping to the entry point
in
* the 0x0400:0000 address range (Assuming that ITCM is not enable).
*/
MEMORY
{
flash (rx) : ORIGIN = 0x00400000, LENGTH = 2048K
sram (rwx) : ORIGIN = 0x20400000, LENGTH = 384K
}
OUTPUT_ARCH(arm)
EXTERN(_vectors)
ENTRY(_stext)
SECTIONS
{
.text : {
_stext = ABSOLUTE(.);
*(.vectors)
*(.text .text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata .rodata.*)
*(.gnu.linkonce.t.*)
*(.glue_7)
*(.glue_7t)
*(.got)
*(.gcc_except_table)
*(.gnu.linkonce.r.*)
_etext = ABSOLUTE(.);
} > flash
.init_section : {
_sinit = ABSOLUTE(.);
*(.init_array .init_array.*)
_einit = ABSOLUTE(.);
} > flash
.ARM.extab : {
*(.ARM.extab*)
} > flash
__exidx_start = ABSOLUTE(.);
.ARM.exidx : {
*(.ARM.exidx*)
} > flash
__exidx_end = ABSOLUTE(.);
_eronly = ABSOLUTE(.);
.data : {
_sdata = ABSOLUTE(.);
*(.data .data.*)
*(.gnu.linkonce.d.*)
CONSTRUCTORS
_edata = ABSOLUTE(.);
} > sram AT > flash
.ramfunc ALIGN(4): {
_sramfuncs = ABSOLUTE(.);
*(.ramfunc .ramfunc.*)
_eramfuncs = ABSOLUTE(.);
} > sram AT > flash
_framfuncs = LOADADDR(.ramfunc);
.bss : {
_sbss = ABSOLUTE(.);
*(.bss .bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
_ebss = ABSOLUTE(.);
} > sram
To David's point, I looked at NVIC since I have CONFIG_ARCH_RAMVECTORS.
arm/src/samv7/samv7_irq.c
#ifdef CONFIG_ARCH_RAMVECTORS
/* If CONFIG_ARCH_RAMVECTORS is defined, then we are using a RAM-based
* vector table that requires special initialization.
*/
up_ramvec_initialize();
#endif
arm/src/armv7-m/up_ramvec_initialize.c
after we copy the ram vectors:
/* Now configure the NVIC to use the new vector table. */
putreg32((uint32_t)g_ram_vectors, NVIC_VECTAB);
and after sam_bringup.c
printf("NVIC: 0x%08x\n", getreg32(NVIC_VECTAB));
NVIC: 0x20401180
Looks good.
And yes, still hitting flash on exception:
flash_erasell /dev/mtd0
Whammo - hardfault in openocd monitor:
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x81000003 pc: 0x00401114 msp: 0x204025e8
Try to flash the lower 256KB of flash, works like a champ:
nsh> sdflash 0x440000 /mnt/sdcard/nuttx.bin /
..............................................................................
..............................................................................
..........................................................................
Installed application of size 233692 bytes to program memory [440000h -
4790dch].
nsh> reboot
So tomorrow, I will maybe move the image to another location in flash and
hack up the linker script.
Also do a detailed read on the errata, Petro mentioned there is some
possible chip bug, maybe that is it ..
There is some nasty Komodo dragon lurking in there, hissing and snapping at
ankles ... SAMV7
doesn't work like an STM32F1/F4/F7 which all work perfectly on this
codebase.. could also be a timing
issue - 300Mhz core clock and 150Mhz AHB clock, I will try to slow it down
and change the flash
wait states also ... maybe a bus error is occuring.
I will pick this up again tomorrow, any ideas, please share!
Thank you for your time and attention to this issue...
-James
On Thu, Dec 8, 2022 at 7:57 AM Gregory Nutt <sp...@gmail.com> wrote:
> On 12/8/2022 5:55 AM, David Sidrane wrote:
> > Is the NVIC_VTABLE repointed to the RAM vectors?
>
> The RAM functions are like .bss: There is a storage area of code that
> that is copied into RAM only power up. But the symbols associated with
> the RAMFUNCs are defined by the linker script to be the address of the
> RAM destination, not the address of the FLASH copy-source storage area:
>
> 186 /* Copy any necessary code sections from FLASH to RAM. The correct
> 187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
> 188 * temporary location is in flash after the data initialization code
> 189 * at _framfuncs. This should be done before sam_clockconfig() is
> 190 * called (in case it has some dependency on initialized C
> variables).
> 191 */
> 192
> 193 #ifdef CONFIG_ARCH_RAMFUNCS
> 194 for (src = (const uint32_t *)_framfuncs,
> 195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
> 196 )
> 197 {
> 198 *dest++ = *src++;
> 199 }
> 200 #endif
>
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by Gregory Nutt <sp...@gmail.com>.
On 12/8/2022 5:55 AM, David Sidrane wrote:
> Is the NVIC_VTABLE repointed to the RAM vectors?
The RAM functions are like .bss: There is a storage area of code that
that is copied into RAM only power up. But the symbols associated with
the RAMFUNCs are defined by the linker script to be the address of the
RAM destination, not the address of the FLASH copy-source storage area:
186 /* Copy any necessary code sections from FLASH to RAM. The correct
187 * destination in SRAM is geive by _sramfuncs and _eramfuncs. The
188 * temporary location is in flash after the data initialization code
189 * at _framfuncs. This should be done before sam_clockconfig() is
190 * called (in case it has some dependency on initialized C variables).
191 */
192
193 #ifdef CONFIG_ARCH_RAMFUNCS
194 for (src = (const uint32_t *)_framfuncs,
195 dest = (uint32_t *)_sramfuncs; dest < (uint32_t *)_eramfuncs;
196 )
197 {
198 *dest++ = *src++;
199 }
200 #endif
RE: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by David Sidrane <da...@nscdg.com>.
Is the NVIC_VTABLE repointed to the RAM vectors?
-----Original Message-----
From: James Dougherty <ja...@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 <ja...@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 <ja...@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.karashchenko@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 <ja...@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
>>> >
>>>
>>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
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 <ja...@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 <ja...@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.karashchenko@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 <ja...@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
>>> >
>>>
>>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
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 <ja...@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.karashchenko@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 <ja...@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
>> >
>>
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by James Dougherty <ja...@gmail.com>.
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.karashchenko@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 <ja...@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
> >
>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Posted by Petro Karashchenko <pe...@gmail.com>.
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 <ja...@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
>