Re: NuttX PTP Support
i’ll take a look at it as soon as I get some free time ; I have a working, GPS master clock. On Mon, Apr 24, 2023 at 6:45 AM Alan C. Assis wrote: > Could be relevant to this thread: > https://github.com/apache/nuttx/pull/9084 > > On 1/30/23, Alan C. Assis wrote: > > Hi James, > > > > Yes, Espressif is doing a good work adding support to it. > > > > I hope in the future others silicon vendors start to contribute as > > well (hello ST, Microchip, Renesas, ...) > > > > Very nice James, I think PTP will be very useful. > > > > Please let me know if you want some help with tests, etc. > > > > BR, > > > > Alan > > > > On 1/30/23, James Dougherty wrote: > >> wow, it is really well supported! > >> OK I will start looking at a PTP server implementation and work on > client > >> later… > >> > >>> On Jan 27, 2023, at 11:36 AM, James Dougherty > wrote: > >>> > >>> Thanks, I will try it this weekend on one of my boards…. > >>> > >>>> On Jan 27, 2023, at 11:12 AM, Alan C. Assis > wrote: > >>>> > >>>> Yes, it is supported: serial and network (ethernet and WiFi). > >>>> > >>>>>> On 1/27/23, James Dougherty wrote: > >>>>> Outstanding! > >>>>> > >>>>> Serial and Network… > >>>>> > >>>>> Thank you > >>>>> > >>>>>>> On Jan 27, 2023, at 10:01 AM, Alan C. Assis > >>>>>>> wrote: > >>>>>> > >>>>>> Hi James, > >>>>>> > >>>>>> ESP32 is supported, which features do you need? > >>>>>> > >>>>>> BR, > >>>>>> > >>>>>> Alan > >>>>>> > >>>>>>> On 1/27/23, James Dougherty wrote: > >>>>>>> I haven’t looked at it yet, but I am working on ESP32; is WROOM > >>>>>>> supported > >>>>>>> in master or just the S3/C3? > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Jan 27, 2023 at 4:23 AM Robert Alexa > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> What's the current status of this? I'm also interested in adding > >>>>>>>> PTP > >>>>>>>> support to NuttX, especially on ESP32 if that's possible - I > >>>>>>>> haven't > >>>>>>>> done > >>>>>>>> any research yet regarding the hardware capabilities of ESP32 in > >>>>>>>> this > >>>>>>>> matter. > >>>>>>>> > >>>>>>>> As a first step I was thinking of adding support for the PTP > >>>>>>>> daemon, > >>>>>>>> as > >>>>>>>> Alan suggested. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Robert > >>>>>>>> > >>>>>>>>> On Fri, 9 Dec 2022 at 07:39, James Dougherty > >>>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> 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? > >>>>
Re: NuttX PTP Support
wow, it is really well supported! OK I will start looking at a PTP server implementation and work on client later… > On Jan 27, 2023, at 11:36 AM, James Dougherty wrote: > > Thanks, I will try it this weekend on one of my boards…. > >> On Jan 27, 2023, at 11:12 AM, Alan C. Assis wrote: >> >> Yes, it is supported: serial and network (ethernet and WiFi). >> >>>> On 1/27/23, James Dougherty wrote: >>> Outstanding! >>> >>> Serial and Network… >>> >>> Thank you >>> >>>>> On Jan 27, 2023, at 10:01 AM, Alan C. Assis wrote: >>>> >>>> Hi James, >>>> >>>> ESP32 is supported, which features do you need? >>>> >>>> BR, >>>> >>>> Alan >>>> >>>>> On 1/27/23, James Dougherty wrote: >>>>> I haven’t looked at it yet, but I am working on ESP32; is WROOM >>>>> supported >>>>> in master or just the S3/C3? >>>>> >>>>> >>>>> On Fri, Jan 27, 2023 at 4:23 AM Robert Alexa >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> What's the current status of this? I'm also interested in adding PTP >>>>>> support to NuttX, especially on ESP32 if that's possible - I haven't >>>>>> done >>>>>> any research yet regarding the hardware capabilities of ESP32 in this >>>>>> matter. >>>>>> >>>>>> As a first step I was thinking of adding support for the PTP daemon, as >>>>>> Alan suggested. >>>>>> >>>>>> Regards >>>>>> Robert >>>>>> >>>>>>> On Fri, 9 Dec 2022 at 07:39, James Dougherty >>>>>>> wrote: >>>>>> >>>>>>> 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: NuttX PTP Support
Thanks, I will try it this weekend on one of my boards…. > On Jan 27, 2023, at 11:12 AM, Alan C. Assis wrote: > > Yes, it is supported: serial and network (ethernet and WiFi). > >> On 1/27/23, James Dougherty wrote: >> Outstanding! >> >> Serial and Network… >> >> Thank you >> >>>> On Jan 27, 2023, at 10:01 AM, Alan C. Assis wrote: >>> >>> Hi James, >>> >>> ESP32 is supported, which features do you need? >>> >>> BR, >>> >>> Alan >>> >>>> On 1/27/23, James Dougherty wrote: >>>> I haven’t looked at it yet, but I am working on ESP32; is WROOM >>>> supported >>>> in master or just the S3/C3? >>>> >>>> >>>> On Fri, Jan 27, 2023 at 4:23 AM Robert Alexa >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> What's the current status of this? I'm also interested in adding PTP >>>>> support to NuttX, especially on ESP32 if that's possible - I haven't >>>>> done >>>>> any research yet regarding the hardware capabilities of ESP32 in this >>>>> matter. >>>>> >>>>> As a first step I was thinking of adding support for the PTP daemon, as >>>>> Alan suggested. >>>>> >>>>> Regards >>>>> Robert >>>>> >>>>>> On Fri, 9 Dec 2022 at 07:39, James Dougherty >>>>>> wrote: >>>>> >>>>>> 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: NuttX PTP Support
Outstanding! Serial and Network… Thank you > On Jan 27, 2023, at 10:01 AM, Alan C. Assis wrote: > > Hi James, > > ESP32 is supported, which features do you need? > > BR, > > Alan > >> On 1/27/23, James Dougherty wrote: >> I haven’t looked at it yet, but I am working on ESP32; is WROOM supported >> in master or just the S3/C3? >> >> >> On Fri, Jan 27, 2023 at 4:23 AM Robert Alexa >> wrote: >> >>> Hi all, >>> >>> What's the current status of this? I'm also interested in adding PTP >>> support to NuttX, especially on ESP32 if that's possible - I haven't done >>> any research yet regarding the hardware capabilities of ESP32 in this >>> matter. >>> >>> As a first step I was thinking of adding support for the PTP daemon, as >>> Alan suggested. >>> >>> Regards >>> Robert >>> >>>> On Fri, 9 Dec 2022 at 07:39, James Dougherty wrote: >>> >>>> 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: NuttX PTP Support
I haven’t looked at it yet, but I am working on ESP32; is WROOM supported in master or just the S3/C3? On Fri, Jan 27, 2023 at 4:23 AM Robert Alexa wrote: > Hi all, > > What's the current status of this? I'm also interested in adding PTP > support to NuttX, especially on ESP32 if that's possible - I haven't done > any research yet regarding the hardware capabilities of ESP32 in this > matter. > > As a first step I was thinking of adding support for the PTP daemon, as > Alan suggested. > > Regards > Robert > > On Fri, 9 Dec 2022 at 07:39, James Dougherty wrote: > > > 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: Re: SAM-E70 progmem - in system programming and RAMFUNCS
Hi Greg, Thank you for your suggestions; I did add the -mlong-calls to the platform Make.defs -ARCHCFLAGS = -fno-builtin +ARCHCFLAGS = -fno-builtin -mlong-calls I tried it out, same issue. Let me know if you have other ideas; I wonder if anyone has done in-system programming like this before without a boot-loader? Thank you! -james On Mon, Dec 12, 2022 at 11:05 PM James Dougherty wrote: > Hi Greg, > > No,l I don't, the relevant extract from make V=1 is as below! > > arm-none-eabi-gcc" -- -fno-builtin -Wall -Wstrict-prototypes -Wshadow > -Wundef -fno-strict-aliasing -g -Os -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 > -mfloat-abi=hard -I. > > I will test that out tomorrow... > > Thank you! > -James > > > On Mon, Dec 12, 2022 at 12:18 PM Gregory Nutt wrote: > >> Do you have the compiler option -mlong-calls selected? That is necessary >> in order to call from the FLASH address space (at 0xxx ) to the SRAM >> address space (2xxx ). >> >
Re: Re: SAM-E70 progmem - in system programming and RAMFUNCS
Hi Greg, No,l I don't, the relevant extract from make V=1 is as below! arm-none-eabi-gcc" -- -fno-builtin -Wall -Wstrict-prototypes -Wshadow -Wundef -fno-strict-aliasing -g -Os -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -I. I will test that out tomorrow... Thank you! -James On Mon, Dec 12, 2022 at 12:18 PM Gregory Nutt wrote: > Do you have the compiler option -mlong-calls selected? That is necessary > in order to call from the FLASH address space (at 0xxx ) to the SRAM > address space (2xxx ). >
Re: Port to M5Stamp-C3U
That's sweet! I am updating an existing design from ESP32-WROOM-32U-N4/platformio to ESP32-S3-WROOM-1U-N16/nuttx so I got this new S3 board - https://www.mouser.com/ProductDetail/356-ESP32S3DEVKTM1N8 I will have to try it out! Thank you! On Fri, Dec 9, 2022 at 6:17 AM Sebastien Lorquet wrote: > (Note that I did write "use" not port :p) > > I got it working very fast by reading all the provided docs! This was > very well made this time, the level of support for this chip is very pro. > > I could even recompile the required second stage bootloader from source. > > It's fun that this bootloader requires a riscv32 toolchain whereas nuttx > is compiled with another riscv64 toolchain! > > All that would remain to do is write a board config for the name > "m5stamp-c3u" instead of "esp32c3-devkit" but I'm too lazy for that, > sorry :p > > Sebastien > > Le 09/12/2022 à 13:14, Alan C. Assis a écrit : > > Hi Sebastien, > > > > On 12/9/22, Sebastien Lorquet wrote: > >> Hi, > >> > >> As an introduction to the RISCV, I would like to use NuttX on my M5stamp > >> C3U, which I can get for 8 dollars at a local store. > >> > >> https://docs.m5stack.com/en/core/stamp_c3u > >> > > This M5stamp C3U uses that ESP32-C3 that is already completely > > supported on NuttX. > > > > So, if your plan was to do a port, you arrived too late in the party :-D > > > >> The module does not use a usb serial chip but direct USB connection > >> (there is a schematic in the bottom of the page). > >> > > The USB serial on ESP32-C3 is already support on NuttX mainline too. > > > >> I wonder how it works: Is serial on USB supported by an internal > >> bootloader or does this require firmware support that will disappear > >> after I flash this board for the first time? > >> > > It doesn't require a firmware and normally will not require a host > > driver because it is a generic USB CDC Serial internal. > > > > Espressif create a nice thing that all MCU should have: a USB Serial / > > JTAG internally integrated in the chip. > > > > So, you don't need an external programmer neither an external > > USB/Serial. Just a USB cable and you can program the chip and get a > > console interface. > > > > You can get more info about it reading the "USB Serial/JTAG > > Controller" chapter of the ESP32-C3 TRM. > > > > BR, > > > > Alan >
Re: SAM-E70 progmem - in system programming and RAMFUNCS
Hi Petro,
I checked the Errata:
https://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Errata-DS8767J.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=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 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 ) 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 ) 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.karashche...@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.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_
Re: SAM-E70 progmem - in system programming and RAMFUNCS
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 ) 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 ) 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.karashche...@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.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
> пише:
> >
> >> 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!
> >>
Re: SAM-E70 progmem - in system programming and RAMFUNCS
> 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=0x2040 -D -bbinary -marm nuttx.bin
-Mforce-thumb > nuttx-ram-dis.txt
arm-none-eabi-objdump --adjust-vma=0x0004 -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=0x2040 -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=0x2040 -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=0x0004 -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 - 0x):
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
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
> 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-s
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 =
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
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: >> >> op
Re: SAM-E70 progmem - in system programming and RAMFUNCS
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, 4 watchpoints
>
> 00400980 :
> 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
> < ai!
>
> So big question is why the exception_com
Re: NuttX PTP Support
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! nsh> PPS: sys 227752 slip 0 PPS: sys 243752 slip 17 PPS: sys 259752 slip 0 PPS: sys 275752 slip 10 PPS: sys 291752 slip 8 PPS: sys 307752 slip 0 PPS: sys 323752 slip 4 PPS: sys 339752 slip 0 PPS: sys 355751 slip 0 PPS: sys 371751 slip 22 PPS: sys 387751 slip 0 PPS: sys 403751 slip 0 PPS: sys 419751 slip 4 PPS: sys 435751 slip 0 PPS: sys 451751 slip 9 PPS: sys 467751 slip 0 PPS: sys 483751 slip 0 PPS: sys 499751 slip 0 PPS: sys 515751 slip 12 PPS: sys 499751 slip 0 PPS: sys 499751 slip 0 nsh> PPS: sys 499751 slip 0 On Tue, Dec 6, 2022 at 8:16 PM James Dougherty wrote: > Great project! I've done a few commercial implementation of PHY > timestamping protocols - IEEE1588 for Ethernet 802.3 > and the WLAN version (802.11v2012) for 802.11n. Products with that > technology are still shipping today (but that was 10 years > ago now). Both are key foundations and building blocks for any > time-sensitive networking (in my case RTP streaming Audio and > Video via uni/multicast). You'll find you don't need a heavy weight > implementation for this -on ethernet, it is a mac layer protocol > where all you need to do is tx/rx IEEE ethertype=0x88f7 packets. The SYNC > message is from an 802.1AS grand-master clock. > You will syntonize your local clock from this message and concurrently and > periodically run a PID control loop to adjust your local > phase and epoch over a system-performance specific period. My > recommendation and direction for this development would be to get 2 Linux > boxes with an Intel Ethernet MAC (any intel MAC), read the 1588 spec and > use Wireshark (with linux ptpd and p2p4l as Alan mentioned) > to study the SYNC message exchanges between a GMC and peer (client) > device. Sounds like greek but 1588 is the place to start. > NuttX could fully support this and servo control loop. You can contact me > offline if you need protocol decode or net debug help, I lived > the dream, even have teh T-shirt :) > > Have fun! > > > > > > > On Tue, Dec 6, 2022 at 1:30 PM Alan C. Assis wrote: > >> Hi Markus, >> >> I don't know if there is someone already using PTP with NuttX >> (probably since NuttX is used by many industrial automation >> companies). >> >> I think the first step should be add a PTP daemon for NuttX. >> >> The ptpd could be a good candidate: https://github.com/ptpd/ptpd >> >> BR, >> >> Alan >> >> On 12/5/22, Markus Noll wrote: >> > Dear all, >> > >> > I'm just investigating NuttX a bit as there is definitely more and more >> > momentum coming about it. >> > I was just wondering if PTP (IEEE1588) is supported or if this is >> planned >> > for the future? Currently, it doesn't look like this, however some >> Eth-MAC >> > drivers have at least some register-definitions for the >> > timestamping-module. >> > >> > Thanks in advance, >> > Markus >> > >> >
Re: NuttX PTP Support
Yes, it’s good stuff. I will look at it next year. > On Dec 7, 2022, at 5:41 PM, Nathan Hartman wrote: > > On Tue, Dec 6, 2022 at 11:16 PM James Dougherty wrote: > >> Great project! I've done a few commercial implementation of PHY >> timestamping protocols - IEEE1588 for Ethernet 802.3 >> and the WLAN version (802.11v2012) for 802.11n. Products with that >> technology are still shipping today (but that was 10 years >> ago now). Both are key foundations and building blocks for any >> time-sensitive networking (in my case RTP streaming Audio and >> Video via uni/multicast). You'll find you don't need a heavy weight >> implementation for this -on ethernet, it is a mac layer protocol >> where all you need to do is tx/rx IEEE ethertype=0x88f7 packets. The SYNC >> message is from an 802.1AS grand-master clock. >> You will syntonize your local clock from this message and concurrently and >> periodically run a PID control loop to adjust your local >> phase and epoch over a system-performance specific period. My >> recommendation and direction for this development would be to get 2 Linux >> boxes with an Intel Ethernet MAC (any intel MAC), read the 1588 spec and >> use Wireshark (with linux ptpd and p2p4l as Alan mentioned) >> to study the SYNC message exchanges between a GMC and peer (client) device. >> Sounds like greek but 1588 is the place to start. >> NuttX could fully support this and servo control loop. You can contact me >> offline if you need protocol decode or net debug help, I lived >> the dream, even have teh T-shirt :) > > > > If this support could be built into NuttX that would be awesome. Some of my > products are built on the TI Tiva-C series which includes hardware 1588 > support in the on-chip Ethernet MAC (or PHY, I don't remember which--the > chip has both) and I have wanted to use 1588 but could never figure out how > to make it work. It has been probably 4 or 5 years since I last looked into > it, though. > > Cheers > Nathan
Re: SAM-E70 progmem - in system programming and RAMFUNCS
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, 4 watchpoints
00400980 :
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
< ai!
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 @2040 && 2MB FLASH @40
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.karashche...@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 пише:
>
> > 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
> > (0x4x). 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
Re: NuttX PTP Support
Great project! I've done a few commercial implementation of PHY timestamping protocols - IEEE1588 for Ethernet 802.3 and the WLAN version (802.11v2012) for 802.11n. Products with that technology are still shipping today (but that was 10 years ago now). Both are key foundations and building blocks for any time-sensitive networking (in my case RTP streaming Audio and Video via uni/multicast). You'll find you don't need a heavy weight implementation for this -on ethernet, it is a mac layer protocol where all you need to do is tx/rx IEEE ethertype=0x88f7 packets. The SYNC message is from an 802.1AS grand-master clock. You will syntonize your local clock from this message and concurrently and periodically run a PID control loop to adjust your local phase and epoch over a system-performance specific period. My recommendation and direction for this development would be to get 2 Linux boxes with an Intel Ethernet MAC (any intel MAC), read the 1588 spec and use Wireshark (with linux ptpd and p2p4l as Alan mentioned) to study the SYNC message exchanges between a GMC and peer (client) device. Sounds like greek but 1588 is the place to start. NuttX could fully support this and servo control loop. You can contact me offline if you need protocol decode or net debug help, I lived the dream, even have teh T-shirt :) Have fun! On Tue, Dec 6, 2022 at 1:30 PM Alan C. Assis wrote: > Hi Markus, > > I don't know if there is someone already using PTP with NuttX > (probably since NuttX is used by many industrial automation > companies). > > I think the first step should be add a PTP daemon for NuttX. > > The ptpd could be a good candidate: https://github.com/ptpd/ptpd > > BR, > > Alan > > On 12/5/22, Markus Noll wrote: > > Dear all, > > > > I'm just investigating NuttX a bit as there is definitely more and more > > momentum coming about it. > > I was just wondering if PTP (IEEE1588) is supported or if this is planned > > for the future? Currently, it doesn't look like this, however some > Eth-MAC > > drivers have at least some register-definitions for the > > timestamping-module. > > > > Thanks in advance, > > Markus > > >
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 (0x4x). 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: New names of repositories
Isn’t nuttx supposed to be the Apache RTOS? rtos/nuttx rtos/apps ? bah … when I do I upgrade to Apache, it’s gonna break more than just build scripts and Makefiles :-( > On Nov 18, 2022, at 8:30 AM, Gregory Nutt wrote: > > >> why can’t we just have : >> >> nuttx, apps >> >> as it has been for a long time (before Apache) … > > Ultimately, the repository names would appear here: > https://github.com/orgs/apache/repositories > > nuttx/ would probably be fine, but apps/ probably would not be appropriate at > that level. > >
Re: New names of repositories
why can’t we just have : nuttx, apps as it has been for a long time (before Apache) … > On Nov 18, 2022, at 8:13 AM, Gregory Nutt wrote: > > >> I see all the other two-word Apache repositories use hyphens not >> underscores, and on GitHub they are URLs which as has been pointed out >> should ideally be hyphenated? >> >> To me the underscore looks wrong...but, in the grand scheme of things, it's >> just a name and, like Sebastien, I will not lose sleep. I lose enough of >> that already, getting trying to get NuttX working on the processor I'm using >> LOL. > > There are some toolchains supported by NuttX that cannot handle hyphens in > paths. So, setting aside personal preferences, there are valid reasons why > hyphens should be avoided. There are also old, obsolete filesystems that do > not support hyphens in names. > > Some file naming standards, however, do recommend hyphens over underscores. > The primary reason seems to be that if the file name is underlined, then the > underscore character is mostly occluded. > > Paths may not begin with hyphens in most commands because the path is > interpreted as a command option. > > These directory names are never really used in the build, however; the name > $TOPDIR which defaults to $PWD/.. when the OS is configured. The user > selects the actual name of the directories when repositories are cloned so, > regardless of what is decided, it need not effect your way of doing things > other than the git clone. > > For example, in order to build with those troublesome toolchains mentioned > above, I have always cloned the repositories to incubator_nuttx and and > incubator_nuttx_apps to avoid the hyphens which do cause build failures with > those toolchains. > >
Re: New names of repositories
That’s right! and underscores are difficult to see when the file name is displayed as an underlined link you also can’t use underscores with AWS S3 … https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html Finally, the Google search engine treats, the hyphen( ‘-‘ ) separator as a word separator but the same does not apply to underscores (‘_’) yes, underscore is great for C code because it is the “space which is not a space” - however, for file names, because of the reasons above it’s problematic… I vote for nuttx, nuttx-apps > On Nov 18, 2022, at 7:07 AM, TimH wrote: > > I see all the other two-word Apache repositories use hyphens not > underscores, and on GitHub they are URLs which as has been pointed out should > ideally be hyphenated? > > To me the underscore looks wrong...but, in the grand scheme of things, it's > just a name and, like Sebastien, I will not lose sleep. I lose enough of that > already, getting trying to get NuttX working on the processor I'm using LOL. > > > >> -Original Message- >> From: Sebastien Lorquet >> >> Hi, >> >> I would also very much prefer nuttx and nuttx_apps but the other option will >> not prevent me from sleeping well at night. >> >> Sebastien >> >>> Le 18/11/2022 à 15:46, Gregory Nutt a écrit : >>> But NuttX has more features than traditional RTOS(e.g. FreeRTOS). Actually, Xiaomi uses it in the IoT space which has less real time requirements. Other similar OS(e.g. Zephyr) doesn't append rtos suffix. So, I prefer keep nuttx and nuttx-apps. >>> >>> I just endorsed nuttx_rtos and nuttx_apps, but Xiao is correct. >>> nuttx_rtos is redundant since nuttx is the name of the RTOS. >>> nuttx_apps are miscellaneous applications tailored for the NuttX RTOS. >>> It really is semantically cleaner. >>> >
Re: STM32F103RET6 and HSI
HI Alan, Yes, that is true, some are really good - SAME70 will work that way but no USB. And yes, MEMS is not there yet. In this case, my BOM was wrong - X1 DNP - so I got enough running to make progress anyhow (tested a lot of HW). The most interesting aspect of this F103 finding for me is that the system works, and then suddenly it does not! Most likely after some burn-in on the device. I noticed this on two systems which ran overnight and then suddenly, whammo, they all failed (no NSH). Then I changed the baud rate ever so slightly and it worked again! Crazy! I change the code back to 921600, hit it with cold spray - working! Let it heat up, lock up. So yes, 50 cents and the problem is solved. Thank you! -James On Tue, Aug 23, 2022 at 5:15 PM Alan Carvalho de Assis wrote: > I don't know how ST internal oscillator is implemented in silicon, but > some MCUs have good internal oscillator. > > For example the SAMD21 used on Arduino M0 board works fine with NSH > running at 115200 and it even supports USB console, but I didn't test > your freezing spray, maybe it could fail too. :-) > > This article compares crystal oscillator vs MEMS oscillator: > > > https://www.avnet.com/wps/wcm/connect/onesite/9be4733b-3e9a-4880-8887-7d19ecf34a0e/quartz-crystal-vs-mems-oscillator.pdf > > The crystal oscillators are "crystal clear winner" (pun intended). > > I agree it is better to pay some cents to include a crystal in the > board, but unfortunately the capitalism's pressure forces people to > make mistakes. > > BR, > > Alan > > On 8/23/22, James Dougherty wrote: > > Hi David, > > > > Wow. That is precisely what is wrong, you can get yourself a little TRIM > > and make one of the boards work, but > > then you would have to hand tune them +/- 1% for every baud rate and > worse, > > temperatures. So better to pay the 71 > > cents and put the 8M crystal on the board. For testing I used cold spray > > and different baud rates to see that it is much > > worse, probably more like 2% on the megabaud rates. APB1 can't go over > > 36Mhz or the backplane hangs. > > PS, the other app note is on 8Mhz HSI and link is here > > > https://www.st.com/resource/en/application_note/an2868-stm32f10xxx-internal-rc-oscillator-hsi-calibration-stmicroelectronics.pdf > > > > Anyhow, the summary is one may use the HSI for bringup and get NSH on > > /dev/ttyS0 as /dev/console but for real > > comms and especially megabaud you need external resonator or crystal and > > HSE enabled as per default in stmf103-minimum > > > > Thank you. > > -James > > > > > > > > > > On Mon, Aug 22, 2022 at 11:55 PM David Sidrane > > wrote: > > > >> HSI is not a good choice if there are external interfaces. It can vary > >> too > >> much part to part and over temperature to meet the 2% across the system > >> boundary. They claim 1% @25c but that is 1/2 the budget to begin with, > >> > >> > >> > https://www.st.com/resource/en/application_note/dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics.pdf > >> > >> > >> > >> > >> On Tue, Aug 23, 2022 at 2:10 AM James Dougherty > >> wrote: > >> > >> > Anyone ever use the HSI on STM32F103, how about RET6? I know the code > >> > is > >> > set up for HSE. I got it working, at least UART1. > >> > But now, the other usart devices ... Wondering if anyone has ever run > >> into > >> > UART baud rate mismatches on using HSI? I have a few > >> > radios that work great with an existing driver and a diff design, but > >> > not > >> > joy on the F103RET6. I am using internal PLL, x8 (64Mhz) > >> > and 32Mhz (APB1, APB2) if anyone has any debug pointers that would be > >> > great. Its weird, the UART1 uses APB2, and others > >> > use APB1. I know I need the external crystal but I got these boards > and > >> no > >> > clock stuffed... (sigh) > >> > > >> > thanks! > >> > -james > >> > > >> > > >
Re: STM32F103RET6 and HSI
Hi David, Wow. That is precisely what is wrong, you can get yourself a little TRIM and make one of the boards work, but then you would have to hand tune them +/- 1% for every baud rate and worse, temperatures. So better to pay the 71 cents and put the 8M crystal on the board. For testing I used cold spray and different baud rates to see that it is much worse, probably more like 2% on the megabaud rates. APB1 can't go over 36Mhz or the backplane hangs. PS, the other app note is on 8Mhz HSI and link is here https://www.st.com/resource/en/application_note/an2868-stm32f10xxx-internal-rc-oscillator-hsi-calibration-stmicroelectronics.pdf Anyhow, the summary is one may use the HSI for bringup and get NSH on /dev/ttyS0 as /dev/console but for real comms and especially megabaud you need external resonator or crystal and HSE enabled as per default in stmf103-minimum Thank you. -James On Mon, Aug 22, 2022 at 11:55 PM David Sidrane wrote: > HSI is not a good choice if there are external interfaces. It can vary too > much part to part and over temperature to meet the 2% across the system > boundary. They claim 1% @25c but that is 1/2 the budget to begin with, > > > https://www.st.com/resource/en/application_note/dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics.pdf > > > > > On Tue, Aug 23, 2022 at 2:10 AM James Dougherty wrote: > > > Anyone ever use the HSI on STM32F103, how about RET6? I know the code is > > set up for HSE. I got it working, at least UART1. > > But now, the other usart devices ... Wondering if anyone has ever run > into > > UART baud rate mismatches on using HSI? I have a few > > radios that work great with an existing driver and a diff design, but not > > joy on the F103RET6. I am using internal PLL, x8 (64Mhz) > > and 32Mhz (APB1, APB2) if anyone has any debug pointers that would be > > great. Its weird, the UART1 uses APB2, and others > > use APB1. I know I need the external crystal but I got these boards and > no > > clock stuffed... (sigh) > > > > thanks! > > -james > > >
STM32F103RET6 and HSI
Anyone ever use the HSI on STM32F103, how about RET6? I know the code is set up for HSE. I got it working, at least UART1. But now, the other usart devices ... Wondering if anyone has ever run into UART baud rate mismatches on using HSI? I have a few radios that work great with an existing driver and a diff design, but not joy on the F103RET6. I am using internal PLL, x8 (64Mhz) and 32Mhz (APB1, APB2) if anyone has any debug pointers that would be great. Its weird, the UART1 uses APB2, and others use APB1. I know I need the external crystal but I got these boards and no clock stuffed... (sigh) thanks! -james
Re: I does an app know it is building on NuttX
And yes, I was just commenting to someone the other day that NuttX is the only RTOS you can easily write your app on Linux and deploy with POSIX equivalent semantics on Nuttx. Great job, and Kudos to you and the whole NuttX team! On Tue, Feb 22, 2022 at 7:48 PM James Dougherty wrote: > Right. you have to decide whether you want to build in an existing tree or > setup a new out of tree build > using sources pulled elsewhere. A simple (yet dangerous) way to do that in > GNU makefiles is to just override > vpath in a Makefile.linux, and then make -f GNUMakefile.linux from > wherever you are building: > > //Makefile.linux > # Find Nutt-X apps directory relative to where I am building from > CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ > else if [ -x /bin/bash ]; then echo /bin/bash; \ > else echo sh; fi ; fi) > SHELL := $(CONFIG_SHELL) > TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) > APPSDIR := $(TOPDIR)/../.. > > > # pull in sources from nuttx appsdir > vpath %.c %.h $(APPSDIR)/pathing/to/file > > for a single top-level makefile with no children this works OK. > > > > On Tue, Feb 22, 2022 at 7:00 PM Gregory Nutt wrote: > >> I think we have done a great job with C code compatibility across >> platforms. I was thinking more of a common application make system that >> could work on both Linux and NuttX platforms. The apps/ Makefiles and >> Make.defs files and some of the apps Kconfig menu=ing are not compatible. >> I would like to be able to just type 'make' and the app build would just >> do >> the right thing. But in order to do that, the build system would have to >> know which platform it is building on. >> >> Perhaps some indirect, ad hoc, heuristic like checking if TOPDIR and >> APPDIR >> are defined. That would probably be enough. Those should always be passed >> to the Makefile from the higher level apps/ build logic, but would never >> be >> defined when building the application to run natively on Linux or any >> other >> non-NuttX platform. >> >> Greg >> >> >> >> On Tue, Feb 22, 2022 at 8:31 PM James Dougherty >> wrote: >> >> > Hi Greg, >> > >> > Thanks for this; it is one of the greatest features you have built into >> > NuttX - POSIX compliance!!! >> > >> > I have a few programs which compile either for NuttX or Linux/MacOS >> with no >> > changes (or Makefile >> > -D options). I started out that way, using -D__NuttX__ but then found >> that >> > besides the includes for NuttX, >> > almost all of the std c library and some of sys (at least >> filesystem/serial >> > code) needs no change! >> > >> > Instead of gcc dumpspecs archaeology, I just did the opposite and have >> > NuttX be the fall-out for >> > conditional includes in the Posix environment. Most NuttX/Linux >> > cross-platform code files have the below: >> > >> > #ifndef __linux__ >> > #include /* NuttX */ >> > #endif >> > >> > /* POSIX Includes (Linux/Nutt-X) common */ >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > #include >> > >> > I also found some mutually exclusive cases like the below: >> > >> > #ifdef __linux__ >> > /* Linux include -D__linux__ */ >> > #else >> > /* Nutt-X include -D__NuttX__ */ >> > #endif >> > >> > And yes, I found __NuttX__ defined in the past also >> > >> > $find . -type f | xargs grep _NuttX__ >> > ./nuttx/configs/stm32f4discovery/testlibcxx/Make.defs: >> > -D__NuttX__ >> > ./nuttx/configs/bambino-200e/netnsh/Make.defs:CXXFLAGS += $(ARCHDEFINES) >> > $(EXTRADEFINES) -pipe -std=c++11 -DCLOCK_MONOTONIC -D__NuttX__ >> > ./nuttx/configs/imxrt1050-evk/libcxxtest/Make.defs: >> -D__NuttX__ >> > $ >> > >> > Of course if you're targeting more than one RTOS you'll need more, but I >> > have had great luck with >> > filesystem, pthread, mutex, and serial (termios) portability. >> > >> > Thank you >> > -James >> > >&
Re: I does an app know it is building on NuttX
Right. you have to decide whether you want to build in an existing tree or setup a new out of tree build using sources pulled elsewhere. A simple (yet dangerous) way to do that in GNU makefiles is to just override vpath in a Makefile.linux, and then make -f GNUMakefile.linux from wherever you are building: //Makefile.linux # Find Nutt-X apps directory relative to where I am building from CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ else if [ -x /bin/bash ]; then echo /bin/bash; \ else echo sh; fi ; fi) SHELL := $(CONFIG_SHELL) TOPDIR := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi) APPSDIR := $(TOPDIR)/../.. # pull in sources from nuttx appsdir vpath %.c %.h $(APPSDIR)/pathing/to/file for a single top-level makefile with no children this works OK. On Tue, Feb 22, 2022 at 7:00 PM Gregory Nutt wrote: > I think we have done a great job with C code compatibility across > platforms. I was thinking more of a common application make system that > could work on both Linux and NuttX platforms. The apps/ Makefiles and > Make.defs files and some of the apps Kconfig menu=ing are not compatible. > I would like to be able to just type 'make' and the app build would just do > the right thing. But in order to do that, the build system would have to > know which platform it is building on. > > Perhaps some indirect, ad hoc, heuristic like checking if TOPDIR and APPDIR > are defined. That would probably be enough. Those should always be passed > to the Makefile from the higher level apps/ build logic, but would never be > defined when building the application to run natively on Linux or any other > non-NuttX platform. > > Greg > > > > On Tue, Feb 22, 2022 at 8:31 PM James Dougherty wrote: > > > Hi Greg, > > > > Thanks for this; it is one of the greatest features you have built into > > NuttX - POSIX compliance!!! > > > > I have a few programs which compile either for NuttX or Linux/MacOS with > no > > changes (or Makefile > > -D options). I started out that way, using -D__NuttX__ but then found > that > > besides the includes for NuttX, > > almost all of the std c library and some of sys (at least > filesystem/serial > > code) needs no change! > > > > Instead of gcc dumpspecs archaeology, I just did the opposite and have > > NuttX be the fall-out for > > conditional includes in the Posix environment. Most NuttX/Linux > > cross-platform code files have the below: > > > > #ifndef __linux__ > > #include /* NuttX */ > > #endif > > > > /* POSIX Includes (Linux/Nutt-X) common */ > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > I also found some mutually exclusive cases like the below: > > > > #ifdef __linux__ > > /* Linux include -D__linux__ */ > > #else > > /* Nutt-X include -D__NuttX__ */ > > #endif > > > > And yes, I found __NuttX__ defined in the past also > > > > $find . -type f | xargs grep _NuttX__ > > ./nuttx/configs/stm32f4discovery/testlibcxx/Make.defs: > > -D__NuttX__ > > ./nuttx/configs/bambino-200e/netnsh/Make.defs:CXXFLAGS += $(ARCHDEFINES) > > $(EXTRADEFINES) -pipe -std=c++11 -DCLOCK_MONOTONIC -D__NuttX__ > > ./nuttx/configs/imxrt1050-evk/libcxxtest/Make.defs: > -D__NuttX__ > > $ > > > > Of course if you're targeting more than one RTOS you'll need more, but I > > have had great luck with > > filesystem, pthread, mutex, and serial (termios) portability. > > > > Thank you > > -James > > > > > > > > > > > > > > On Tue, Feb 22, 2022 at 5:11 PM Gregory Nutt > wrote: > > > > > Hmm.. but that doesn't help with setting up the build. That definition > > is > > > only visible to C code since it is a C pre-processor definition defined > > in > > > the CFLAGS. It can't really be used to customize the build, at least > not > > > in any clean way. > > > > > > It would have been useful to have a similar, Make=friendly definition > as > > > well. > > > > > > On Tue, Feb 22, 2022 at 7:03 PM Gregory Nutt > > wrote: > > > > > > > Thanks! Now I see it defined tools/Config.mk. Looks like that was > > added > > > > with #2192. That is
Re: I does an app know it is building on NuttX
Hi Greg, Thanks for this; it is one of the greatest features you have built into NuttX - POSIX compliance!!! I have a few programs which compile either for NuttX or Linux/MacOS with no changes (or Makefile -D options). I started out that way, using -D__NuttX__ but then found that besides the includes for NuttX, almost all of the std c library and some of sys (at least filesystem/serial code) needs no change! Instead of gcc dumpspecs archaeology, I just did the opposite and have NuttX be the fall-out for conditional includes in the Posix environment. Most NuttX/Linux cross-platform code files have the below: #ifndef __linux__ #include /* NuttX */ #endif /* POSIX Includes (Linux/Nutt-X) common */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include I also found some mutually exclusive cases like the below: #ifdef __linux__ /* Linux include -D__linux__ */ #else /* Nutt-X include -D__NuttX__ */ #endif And yes, I found __NuttX__ defined in the past also $find . -type f | xargs grep _NuttX__ ./nuttx/configs/stm32f4discovery/testlibcxx/Make.defs: -D__NuttX__ ./nuttx/configs/bambino-200e/netnsh/Make.defs:CXXFLAGS += $(ARCHDEFINES) $(EXTRADEFINES) -pipe -std=c++11 -DCLOCK_MONOTONIC -D__NuttX__ ./nuttx/configs/imxrt1050-evk/libcxxtest/Make.defs:-D__NuttX__ $ Of course if you're targeting more than one RTOS you'll need more, but I have had great luck with filesystem, pthread, mutex, and serial (termios) portability. Thank you -James On Tue, Feb 22, 2022 at 5:11 PM Gregory Nutt wrote: > Hmm.. but that doesn't help with setting up the build. That definition is > only visible to C code since it is a C pre-processor definition defined in > the CFLAGS. It can't really be used to customize the build, at least not > in any clean way. > > It would have been useful to have a similar, Make=friendly definition as > well. > > On Tue, Feb 22, 2022 at 7:03 PM Gregory Nutt wrote: > > > Thanks! Now I see it defined tools/Config.mk. Looks like that was added > > with #2192. That is exactly what I need! > > > > I was thrown off because there are applications that ARE using __NUTTX__: > > > > $ grep -rl __NUTTX__ * > > system/adb/Makefile > > system/libuv/0001-initial-libuv-port-to-nuttx.patch > > system/libuv/libuv/Makefile > > system/libuv/tests/Makefile > > > > There are a couple using __NuttX__, but didn't catch those: > > > > $ grep -rl __NuttX__ * > > netutils/ftpd/ftpd.c > > netutils/webclient/webclient.c > > > > Thanks again. > > > > > > > > On Tue, Feb 22, 2022 at 6:43 PM Nathan Hartman > > > wrote: > > > >> On Tue, Feb 22, 2022 at 2:14 PM Gregory Nutt > wrote: > >> > >> > One option would be to define __NUTTX_ in tools/Config.mk instead of > in > >> > each individual apps/Makefile. That would provide a single point > >> > definition coordinate all usage. > >> > >> > >> Just one (possible) correction: IIRC it is capitalized as __NuttX__. All > >> my > >> cross platform applications look for __NuttX__ to detect that they are > >> being built this way. The buildroot toolchain does define that, though I > >> am > >> *not* using the buildroot toolchain and it is somehow defined anyway. I > am > >> away from my computer at the moment so I cannot check where it is coming > >> from, but from memory I think we added something to the NuttX build > >> scripts > >> some time ago (maybe about 1 or 2 years ago) to cause that to be defined > >> with all compilers. (Or perhaps I remember wrong and I added it to our > >> in-house boards' Make.defs.) > >> > >> Nathan > >> > > >
Re: NuttX system load
David, Greg, Thank you for the pointers more on this later. Best regards -james On Wed, May 12, 2021 at 6:40 AM Gregory Nutt wrote: > > Dave Marples was using Orbuculum with some success in the past: > > https://groups.google.com/g/nuttx/c/XwzRjsgq1rA/m/Kcpe4vydAgAJ > https://nuttx.events/wp-content/uploads/2019/11/DMarples_nx2019.pdf > > On 5/12/2021 12:43 AM, David S. Alessio wrote: > >> On May 11, 2021, at 11:22 PM, James Dougherty wrote: > >> > >> Hi Folks, > >> > >> What is an easy way to compute the system load on Nutt-X? > >> I don't need the procinfo (Unix LA) just current CPU load and > >> optimally, I would like a measure 0-1000 where I can get 4 digits of > >> precision ... > >> The simpler the better, doesn't need to be a lot of code, only used > >> for a "busy-ness" factor. > >> > >> Thank you very much! > >> > >> -James > > > > I added this feature a few years ago, but it seems it has since succumb to > > bit rot and perhaps a few too many fat fingers… > > Take a look at the earliest to procfs.c and look for “/proc/load” or > > “/proc/cpuload”, I don’t recall… > > > > Cheers, > > -david > >
NuttX system load
Hi Folks, What is an easy way to compute the system load on Nutt-X? I don't need the procinfo (Unix LA) just current CPU load and optimally, I would like a measure 0-1000 where I can get 4 digits of precision ... The simpler the better, doesn't need to be a lot of code, only used for a "busy-ness" factor. Thank you very much! -James
Re: STM32H7 ethernet hardfaults
Wow, nice! Thank you guys! David, nice description of the descriptors, it looks like zero padding is being done by the MAC. Do you guys have any iperf numbers for UDP on H7? On Fri, Mar 5, 2021 at 7:15 AM John Rippetoe wrote: > Wow, that was fast David! Good find on the cache invalidation issue. > I'll get your fix running on my board to verify the hard faults have > been resolved. > > Thanks everyone for all of your input and help! > > - John > > On 3/5/21 9:11 AM, David Sidrane wrote: > > PR is in. Please have a look and test with the default > > CONFIG_NET_ETH_PKTSIZE. All should be happy now. :) > > > > https://github.com/apache/incubator-nuttx/pull/2985 > > > > -Original Message- > > From: David Sidrane [mailto:david.sidr...@nscdg.com] > > Sent: Friday, March 05, 2021 1:26 AM > > To: 'dev@nuttx.apache.org' > > Subject: RE: STM32H7 ethernet hardfaults > > > > Hi, > > > > Thank you all for sharing your Networking and dcache expertise! > > > > The descriptors and buffers are all aligned and sized for the dcache line > > size. > > > > The problem is the following. (The value of number do not matter, but > help > > express the nature of the problem.) > > > > If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the > network > > is received by the F7. > > > > The DMA HW will store the frame as n buffer sizes segments and one or 0 > > remainder sizes buffer. > > > > The following will happen: > > > > 490 becomes 608 after the sizing and alignment. > > > > DMA populates the buffers from the descriptors > > > > +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits > in > > RDES0[29:16]) - 4 > > || > > |V > > |D1->B1(608) > > || > > | V > > | D2->B2(298) > > | > > | | > > | V > > <+Dn->Bn[] > > > > > > From RM410: To compute the amount of valid data in this final buffer, > the > > driver must read the frame length (FL bits in RDES0[29:16]) and subtract > > the sum of the buffer sizes of the preceding buffers in this frame. > > > > But the code is invalidating from [0] to [1513]. If the buffers > were > > contiguous in memory this would be ok. But the buffers that are used in > RX > > are replaced (in the descriptors) from the free pool using the g_txbuffer > > memory. > > > > While at boot B0 to Bn are contiguous, they become scattered as a > process of > > receiving (the nature of the ring and replacement from the free pool) > > > > The ring: > > > > /* Scan descriptors owned by the CPU. Scan until: > > * > > * 1) We find a descriptor still owned by the DMA, > > * 2) We have examined all of the RX descriptors, or > > * 3) All of the TX descriptors are in flight. > > * > > > > The replacement: > > > >buffer = stm32_allocbuffer(priv); > >/* Take the buffer from the RX descriptor of the first > free > > * segment, put it into the network device structure, then > > * replace the buffer in the RX descriptor with the newly > > * allocated buffer. > > */ > >dev->d_buf= (uint8_t *)rxcurr->rdes2; > >rxcurr->rdes2 = (uint32_t)buffer; > > > > > > Eventually, B0 is allocated from one of the buffers in the g_txbuffer > array. > > > > > > Given this layout of memory low-high > > > > /* Descriptor allocations */ > > > > g_rxtable[RXTABLE_SIZE] > > g_txtable[TXTABLE_SIZE] > > > > /* Buffer allocations */ > > > > g_rxbuffer[RXBUFFER_ALLOC] > > g_txbuffer[TXBUFFER_ALLOC] > > > > /* These are the pre-allocated Ethernet device structures */ > > > > stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET]; > > > > The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame > Length > > 1514 NOT the buffer length! > > > > The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is > > dev->d_buf and + dev->d_len are both 0. > > > > Context before the call to up_invalidate_dcache > > > > dev->d_buf = _txbuffer[n * (RXBUFFER_ALLOC/608)] > > dev->d_len = 1514 > > > > up_invalidate_dcache((uintptr_t)dev->d_buf, > > (uintptr_t)dev->d_buf + > dev->d_len); > > > > Context after the call to up_invalidate_dcache > > dev->d_buf =0 > > dev->d_len = 0 > > > > > > This then returns OK and stm32_receive dereferences a null pointer and > > places the null into the free pool. > > The hard fault then happens. > > > > When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen > > because sizeof FRAME == sizeof BUFFER > > > > (The system will still crash if the hardware can receive a bigger frame > the > > numbers are relaitve) > > > > The driver is not quite right, the code manages the segments but does not > > coalesce them back in to a frame. (memcpy with such a DMA is gross > thought) > > So the data RX data is useless to the network layer. > > > > If the
Re: STM32H7 ethernet hardfaults
That “thing i quoted” *was* the ethernet spec - THE NORMAL STANDARD - the latest version 802.3-2018 going for about $1000 USD. And like I said, there is no such thing as a "Jumbo" frame, it's not IEEE standard, the spec shows that also. therefore saying "it's already a jumbo frame" is meaningless. The Ethernet Layer-2 standard defines a 14-byte ethernet header and 1500 byte payload size, with a 4 byte CRC that is 1518 bytes. When you say "it's part of the data" you have to be clear about what layer you are talking about. No. The TAG comes after the DA/SA, the length after the tag. Here is a picture https://en.wikipedia.org/wiki/EtherType See section VLAN tagging. What happens in hardware is the fixed DA/SA (12 bytes) is extracted, a 0x8100 type / len re-inserted and CRC recomputed. The firmware for the Broadcom StrataSwitch 56xx ethernet switches handles L2 Ethernet I/II, tagged/untagged with/without snap headers, as well as L3 hardware routing including rewriting up to 52 bytes of the IP header field, all while respecting TOS and QoS — we didn’t drop packets over 1500 bytes at L2 - and that was 20 years ago. This is where the defines in net/if_ether.h in any modern linux kernel come from - note the distinction between ETH_FRAME_LEN (1514) and ETH_DATA_LEN (1500) the former which handles the Ethernet header. To make it even more complicated, there are additional header values which are typically inserted on a GigE/VLAN based controller and that is all "pulled up" (removed) by the time the IP layer gets the packet (by your Ethernet MAC or driver). Regardless, the recommendation for any Ethernet L2 use case today is a 1518 to 2K frame size. I understand on these microcontrollers that may seem excessive, but newer chips will have even more ram and performance and you have to decide whether you want interop or a dedicated point to point use-case. If you want to nitpick on something, it should be the standard, the latest envelope extensions are going to make networking even more difficult in the future :( > On Mar 5, 2021, at 2:45 AM, Johnny Billquist wrote: > >> On 2021-03-05 05:35, James Dougherty wrote: >> Technically, the MTU should be 1496 of you use VLANs, or else it's >>> actually already a jumbo frame. The total size according to the ethernet >>> spec is really 1518. Larger are not allowed. VLAN information is >>> actually a part of the payload. >>> >>> >> Yes, 1518 is the size, true. But VLANS are not part of the payload. An >> untagged frame which enters a VLAN >> switch will have the 802.1Q tag inserted after the DA/SA. When that happens >> the CRC has to be recomputed >> so therefore *it is not* just part of the payload (e.g. like a UDP >> datagram). Larger are allowed, we typically use 2K >> sizes for additional link layer encapsulation (most of the switching >> hardware today does at least). > > The CRC covers the whole packet, so of course the CRC have to be recomputed > if you add a VLAN tag. > > The VLAN tags are not added after the DA/SA, but actually after the length > field. > When you add VLANs, you normally no longer use ethernet, but instead 802.3. > In which this is not considered a part of the payload, I know. But the > controller receiving the packet might have no clue about this. It's all at a > higher level of protocol handling. It's nice that 802.3 have defined so that > larger frames are allowed. Older ethernet controllers will still drop such > packets because they are over 1500 bytes of payload. Even if they understand > 802.3. And even if software would understand VLANs. > Not that the thing you quoted states "MAC Client Data Field". And that is > 1500 (the normal standard), 1504 with Q-tag, and so on. That's the MAC Client > *Data* field. It's part of the data. > > But I suspect you know this. :-) > > I feel I should stop now anyway. Feel free to mail me in private though. But > I don't want to pollute the mailbox of everyone with my nitpickings. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol
Re: STM32H7 ethernet hardfaults
Yes, that's true. very good discussion. I bring this up since you can do whatever you want on a point to point link. For maximum compatibility, using 1500 or 1518 will help you handle all of the cross-network cases where you cross a bridge/switch or gateway. The other unintended side-effect of this is that when you use these smaller MTU's you will impose a slightly larger number of packets in overhead. Many people think the bitrates are the limitation but it usually ends up being the number of packets. What you put in your payload is going to mandate your fragmentation and therefore your true number of packets to/from your stack. Its time or space, you can't have both :-) On Thu, Mar 4, 2021 at 6:38 PM Johnny Billquist wrote: > On 2021-03-05 00:21, Gregory Nutt wrote: > > > > On 3/4/2021 4:59 PM, James Dougherty wrote: > >> Thank you, that is interesting. Doesn't it also imply is that with the > >> smaller MTU of 590 you'll end up having > >> fragmentation which will add a little bit of processing overhead? I > >> understand it is not that big of a deal since > >> fragmentation happens a lot, but for the best performance yes, both > sides > >> have to agree on a decent MTU. > > > > In TCP, both sides do agree. That is the negotiated MTU. > > Sorry for jumping in like this. Stop me if I bore people too much. > > Actually, TCP do not negotiate any MTU. > > But there are two mechanisms that is sortof close to this, which might > be what you are thinking of. > > The first one is MSS. This is a value each TCP endpoint announce to the > other end, and which essentially declares the largest packet size that > end is capable of handle (well, primarily receive). Each side just sends > the MSS that applies for that size. And each side should not send > packets that are larger than MSS the other end declared. And usually you > would not send packets larger than your own MSS, since usually there is > some good reason for whatever MSS you declare to the other end, and it > applies just as much to transmission as reception. > > That means you'll commonly not see packets larger than the smaller MSS > of the two ends involved in communication. > > However, this does not avoid packet fragmentation happen, because packet > fragmentation is an IP level feature, and it will also happen if any hop > between the two endpoints have a small enough MTU, or possibly if > various IP options are added that TCP just don't know about, and so on. > > So, the second mechanism is the path MTU detection (or PMTU). But this > is no negotiation at all, but a trick the sending TCP do in order to try > and figure out how large packets can be sent without them being > fragmented along the way. The basics of the trick is that TCP sends > packets with the don't fragment bit set in IP, and if any hop along the > way require the packet to be fragmented, an ICMP error packet will > instead be returned. This is then a signal to TCP that it should > retransmit, but also reduce the PMTU. And once it a while, TCP should > try to increase the PMTU, to just check if the path might actually have > changed to allow larger packets (assuming you're not already at your own > interface MTU, at which you can't go larger anyway). > > And as to MTU, the actual "legal" lower limit of the MTU in IP is 68. > However, the minimum sized packet an IP implementation must support is > 576 bytes. But there is nothing saying that it has be able to be > transferred without fragmentation. But an IP stack is technically > allowed to drop without notice packets that are larger than 576 bytes > (although it wouldn't be very nice). > > If people want to read all the itty bitty details, I can give you the > RFCs. But you can just google it as well. > > > Of course, larger MTUs have better transfer rates. That is the old > > performance vs. size trade-off. If so configured, both end points > > should use the configured MTU of the network. However, they should also > > work with limited devices with smaller MTUs. > > All very true. But it does mean that if you are on the same ethernet, > and one host have defined a smaller MTU, and you use UDP for example, > then larger packets might get lost without any feedback. Because UDP > have no clue about the other end having a different/smaller MTU. > > TCP should usually manage, since MSS should reflect the local MTU, and > thus the other end knows it can't send larger packets than that, when > using TCP at least. > > It's rather recommended that all hosts on a shared medium use the same > MTU, if possible. Otherwise there is a clear risk that communication > might not work as expected. > >Johnny > > -- > Johnny Billquist || "I'm on a bus >|| on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol >
Re: STM32H7 ethernet hardfaults
Technically, the MTU should be 1496 of you use VLANs, or else it's > actually already a jumbo frame. The total size according to the ethernet > spec is really 1518. Larger are not allowed. VLAN information is > actually a part of the payload. > > Yes, 1518 is the size, true. But VLANS are not part of the payload. An untagged frame which enters a VLAN switch will have the 802.1Q tag inserted after the DA/SA. When that happens the CRC has to be recomputed so therefore *it is not* just part of the payload (e.g. like a UDP datagram). Larger are allowed, we typically use 2K sizes for additional link layer encapsulation (most of the switching hardware today does at least). IEEE Std 802.3-2012 (Revision of IEEE Std 802.3-2008) 1.4.102 basic frame A MAC frame that carries a Length/Type field with the Length or type interpretation and has a maximum length of *1518* octets. The basic frame is not intended to allow inclusion of additional tags (i.e., untagged) or encapsulations required by higher layer protocols. (See IEEE Std 802.3, 3.2.7.) 3.2.7 MAC Client Data Field Ethernet implementations shall support at least one of three maximum MAC Client Data field sizes defined as follows: a) 1500 decimal—basic frames (see 1.4.102) b) 1504 decimal—Q-tagged frames (see 1.4.334) c) 1982 decimal—envelope frames (see 1.4.184) If layer management is implemented, frames with a MAC Client Data field larger than the supported maximum MAC Client Data field size are counted. Also, if we have a length field, then it's an 802.3 frame, while if you > have type information in there it is a Ethernet II frame. So IP commonly > use Ethernet II, and not 802.3. There is a standard for sending IP over > 802.3 as well, but it has been declared obsolete since many years now. > 3.2.6 Length/Type field This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field. a)If the value of this field is less than or equal to 1500 decimal (05DC hexadecimal), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent MAC Client Data field of the basic frame (Length interpretation). b)If the value of this field is greater than or equal to 1536 decimal (0600 hexadecimal), then the Length/Type field indicates the Ethertype of the MAC client protocol (Type interpretation). The Length and Type interpretations of this field are mutually exclusive. > > Sorry, this was mostly silly trivia... > > We are running with STM32H7 chips, but I think we are actually using a > large enough packet size. So I don't have any direct feedback on this > problem. > > So what packet size do you use? We're running STM32F7 with some exotic radio hardware, probably will get to this later on in the year (Ethernet bridging). >Johnny > > On 2021-03-04 22:48, James Dougherty wrote: > > John, to answer your question on ethernet, 1500 is a very common MTU. For > > VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on > the > > wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is > > common. Minimum frame size with CRC is 64-bytes and zero padding is > common, > > < 64 is considered a runt frame. And note if ethernet_len field is 0x800 > > you have an IP packet. Good luck on STM32H7 ethernet hardfault debug. > > > > On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe < > jrippe...@roboticresearch.com> > > wrote: > > > >> Hello All, > >> > >> I've been playing around with networking on the STM32H7 and am seeing > >> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log > >> below, the driver would appear to be dropping packets that are too large > >> to fit into the default packet size of 590. By increasing the packet > >> size to the max (1518), the problem seems to disappear, but I am a > >> little confused why the driver is able to catch the fact that the > >> received packet was too large and drop it appropriately, but then crash. > >> After poking around the ethernet driver, I think I understand the issue > >> to be that because the MAC DMA does not know that the buffer it is > >> writing into has a size limit, it is overflowing the buffer and writing > >> into adjacent memory. Am I understanding this correctly? > >> > >> My main concern here is that increasing NET_ETH_PKTSIZE to the limit > >> will only hide the issue for a time instead of solving it. A quick > >> google search does show that the maximum ethernet frame size is 1518 > >> bytes though, so I am working under the assumption that maxing it out in > >> my config will account for all possible frame size
Re: STM32H7 ethernet hardfaults
Thank you, that is interesting. Doesn't it also imply is that with the smaller MTU of 590 you'll end up having fragmentation which will add a little bit of processing overhead? I understand it is not that big of a deal since fragmentation happens a lot, but for the best performance yes, both sides have to agree on a decent MTU. On Thu, Mar 4, 2021 at 2:39 PM Gregory Nutt wrote: > > John, to answer your question on ethernet, 1500 is a very common MTU. For > > VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on > the > > wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is > > common. Minimum frame size with CRC is 64-bytes and zero padding is > common, > > < 64 is considered a runt frame. And note if ethernet_len field is 0x800 > > you have an IP packet. Good luck on STM32H7 ethernet hardfault debug. > > The MTU is a property of a network that is controlled by the network > configuration. These are the "standard" MTUs used on commercial > networks and are pervasive in commercial networks. Other MTUs are > theoretically possible for custom networks but are not supported by the > H7 Ethernet MAC. > > The value 590 is the minimum size that you can use for a fully > functional network. It is not commonly used but perfectly valid. > Increasing this default would break some configurations. Some older > parts, such as LPC17xx have plenty of SRAM, but are constrained to a > very small bank of DMA-able memory for Ethernet and USB. > > Ethernet MACs that are not able to support certain packet sizes need to > have checks to prohibit selection of sizes that they cannot support. > > >
Re: STM32H7 ethernet hardfaults
John, to answer your question on ethernet, 1500 is a very common MTU. For VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is common. Minimum frame size with CRC is 64-bytes and zero padding is common, < 64 is considered a runt frame. And note if ethernet_len field is 0x800 you have an IP packet. Good luck on STM32H7 ethernet hardfault debug. On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe wrote: > Hello All, > > I've been playing around with networking on the STM32H7 and am seeing > hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log > below, the driver would appear to be dropping packets that are too large > to fit into the default packet size of 590. By increasing the packet > size to the max (1518), the problem seems to disappear, but I am a > little confused why the driver is able to catch the fact that the > received packet was too large and drop it appropriately, but then crash. > After poking around the ethernet driver, I think I understand the issue > to be that because the MAC DMA does not know that the buffer it is > writing into has a size limit, it is overflowing the buffer and writing > into adjacent memory. Am I understanding this correctly? > > My main concern here is that increasing NET_ETH_PKTSIZE to the limit > will only hide the issue for a time instead of solving it. A quick > google search does show that the maximum ethernet frame size is 1518 > bytes though, so I am working under the assumption that maxing it out in > my config will account for all possible frame sizes and eliminate this > issue. I have no experience with low level networking protocols and > standards, so I thought it would be prudent to seek out additional help > to make sure I am on the right track. > > Thanks in advance. > > - John > > stm32_receive: WARNING: DROPPED Too big: 684 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1332 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1264 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 684 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1364 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1264 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1436 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > stm32_receive: WARNING: DROPPED Too big: 1300 > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! > up_hardfault: PANIC!!! Hard fault: 4000 > up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 > task: lpwork > up_registerdump: R0: 24012080 2401206e 024e 24012000 > 40029160 24011fc0 8040 > up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 0001 > 38002f88 080a26a7 080a2538 > up_registerdump: xPSR: 8100 BASEPRI: 00f0 CONTROL: >
