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