Re: NuttX PTP Support
Beware of that 1PPS signal. A few years ago I bought several GPS modules and compared the signals. Some differ by exactly 100ns (within 2ns, the accuracy of my scope) from others, and that is not the width of the pulse, that is much wider, I compared only the edge that are comes close to the others. Maybe I will test again, have a 1 GHz LeCroy now, should be able to do jitter measurements too. Oh, and yes, before someone asks: all antenna and scope cables were the same length... ;-) Arie On 2022-12-08 06:33, James Dougherty wrote: Related to this, I have a GPS receiver generating PPS interrupts on SAME70. It would be a perfect GMC - Atomic clock sync! I will look at this when I get a chance. I have a lot of upstream contributions from HW platforms I have done over the last 5 years or so with myself and others ... I need some time to patch master on upstream -- something for 2023 and now that NuttX has graduated! Yay!
RE: SAM-E70 progmem - in system programming and RAMFUNCS
Is the NVIC_VTABLE repointed to the RAM vectors? -Original Message- From: James Dougherty 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 0x40 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 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 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: 0x8103 pc: 0x004009a0 msp: 0x2041bfb4 Polling target >> samv.cpu failed, trying to reexamine Info : samv.cpu: hardware has 8 >> breakpoints,
Re: SAM-E70 progmem - in system programming and RAMFUNCS
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: NuttX PTP Support
Thanks Arie, Yes, very true, it depends on your application! My statement about what makes a good clock is very subjective. This all depends on your application, your measurement and of course your jitter. - For Wireless AV, a 10ms gps clock is fine. - For Wireless Earbuds, a 10us clock is required with 1us phase max drift. - For Photon measurements, you're in the nano/pico domain... Accuracy costs money, how well do you need to measure? So the message is to know your application! Your application will have varying time requirements. The infrastructure and machinery for relaying and exchanging time is all PTP provides as a tool. The 802.1AS spec specifies how to manage that clock across multiple time domains. Related, know your latencies! https://gist.github.com/jboner/2841832 Best regards -James On Thu, Dec 8, 2022 at 3:37 AM Arie de Muijnck wrote: > Beware of that 1PPS signal. A few years ago I bought several GPS modules > and compared the signals. Some differ by exactly 100ns (within 2ns, the > accuracy of my scope) from others, and that is not the width of the pulse, > that is much wider, I compared only the edge that are comes close to the > others. Maybe I will test again, have a 1 GHz LeCroy now, should be able to > do jitter measurements too. > Oh, and yes, before someone asks: all antenna and scope cables were the > same length... ;-) > > Arie > > > On 2022-12-08 06:33, James Dougherty wrote: > > Related to this, I have a GPS receiver generating PPS interrupts on > SAME70. It would be a perfect GMC - Atomic clock sync! > > I will look at this when I get a chance. I have a lot of upstream > contributions from HW platforms I have done over the last 5 years or so > with myself and others ... I need some time to > > patch master on upstream -- something for 2023 and now that NuttX has > graduated! Yay! > > >
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: and
* 384Kb of SRAM beginining at 0x2040:
*
* When booting from FLASH, FLASH memory is aliased to address 0x:
* where the code expects to begin execution by jumping to the entry point
in
* the 0x0400: address range (Assuming that ITCM is not enable).
*/
MEMORY
{
flash (rx) : ORIGIN = 0x0040, LENGTH = 2048K
sram (rwx) : ORIGIN = 0x2040, 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: 0x8103 pc: 0x00401114 msp: 0x204025e8
Try to flash the lower 256KB of flash, works like a champ:
nsh> sdflash 0x44 /mnt/sdcard/nuttx.bin /
..
..
..
Installed application of size 233692 bytes to program memory [44h -
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 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,
> 195dest = (ui
RE: SAM-E70 progmem - in system programming and RAMFUNCS
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
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: and
* 384Kb of SRAM beginining at 0x2040:
*
* When booting from FLASH, FLASH memory is aliased to address 0x:
* where the code expects to begin execution by jumping to the entry point
in
* the 0x0400: address range (Assuming that ITCM is not enable).
*/
MEMORY
{
flash (rx) : ORIGIN = 0x0040, LENGTH = 2048K sram (rwx) : ORIGIN =
0x2040, 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: 0x8103 pc: 0x00401114 msp: 0x204025e8
Try to flash the lower 256KB of flash, works like a champ:
nsh> sdflash 0x44 /mnt/sdcard/nuttx.bin /
..
..
..
Installed application of size 233692 bytes to program memory [44h -
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 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 /*
