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 <jafr...@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 <spudan...@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 > >
