Esp32 - sx127x support
Hi I am trying to integrate sx1276 based LoRa module (RFM9x), however I am unsure of any preexisting support for it. I see configuration for ttgo-lora module with sx127x example application, however did not have any luck in establishing successful link. Please advise. Thank you
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
NuttX PTP Support
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
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: SAM-E70 progmem - in system programming and RAMFUNCS
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 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: 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 > > >
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 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
