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.karashche...@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 <david.sidr...@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 <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 >> > >> > >> >
