USB Host and Bluetooth "dongle".
I hope this is not too much if a newbie/dumb question as I have tried to research this first. I've been playing with Nuttx on a SAMA5D2-XULT board ahead of porting to my custom board (SAMA5D27C-5M, actually), especially in regard to USB Host functionality as that's what's drawn me to NuttX in the first place. USB memory sticks are recognised and I can mount them (not got automount to work, yet - I'm still learning!; and date/time stamping of files written doesn't seem to work either) - nice to have things like this work "out of the box"! I can also build in Bluetooth support and the demo app, but as far as I can tell there are no actual Bluetooth host drivers in NuttX to properly support a detected Bluetooth device. My custom board actually has a SiLabs Bluetooth module on it (connected to the SAM via UART and proven to work) but I quite like the idea of just using plug-in Bluetooth devices instead :) I can see the device is detected (it gets powered, and dmesg reports stuff) but no drivers are loaded as best as I can tell. Is that correct or have I missed something? Drivers are not my strong point but, if I'm right and a driver will be needed, is a generic Linux driver a good place to start were I to look to add/create one to NuttX? Or maybe someone has already done this? Thanks, Tim.
RE: USB Host and Bluetooth "dongle".
> Am 24.03.2021 um 18:34 schrieb Tim:
>
> > I can also build in Bluetooth support and the demo app, but as far as
> > I can tell there are no actual Bluetooth host drivers in NuttX to
> > properly support a detected Bluetooth device. My custom board actually
> > has a SiLabs Bluetooth module on it (connected to the SAM via UART and
> > proven to work) but I quite like the idea of just using plug-in
> > Bluetooth devices instead :)
>
> Bluetooth is quite complex. You will have to deal with several layers:
>
> 1. Hardware driver (like Ethernet Hardware driver) 2. Low Level Protocol
> Stack (HCI, like network TCP/IP layer) 3. High Level Protocol Stack
("Profiles",
> like network mail, web, ntp, nfs application protocols)
>
> USB dongles usually implement the hardware driver and the low-level
> protocol stack (HCI). The computer has to run the high level protocol
stack.
[>] Understood, of course. The documentation in NuttX regarding Bluetooth
is superficial and I am probably guilty of assumption and naivety! Because
there is Host device support, and there are Bluetooth tools and drivers, and
because Linux itself has a Bluetooth stack I leapt to the conclusion that
Nuttx probably had a stack, just not the "link" between it and the detected
USB device (i.e. a relevant USB driver, which are available in the Linux
source trees).
>
> Other modules, especially the serial ones, implement the whole stack:
> hardware driver, low-level stack, and one or more profiles (SPP,
audio,...). If
> you only need SPP, you really should use these modules.
> This allows you to write only 100 lines of code instead of 1.
[>] My custom board has a SiLabs SoC on-board. I have developed LE
applications using custom GATT on these before very successfully and it has
a UART link to my SAM processor running NuttX. I will probably stick with
that.
The reasons for considering using a USB Bluetooth device:
a) reduces unit costs, when not everyone wants to use Bluetooth
b) existence of (proven working on my custom board, using USB C) host
support so it's over the first hurdle compared to the Bare Metal approach I
had been taking
c) Trying to steer through the Bluetooth SIG nightmare of registrations and
fees...but that's another story!
>
> fchk
RE: USB Host and Bluetooth "dongle".
> Hi Tim, > > It depends on what you refers to Bluetooth: is it Bluetooth Classic or BLE ? > > If you want BT BLE maybe it is better to use a MCU with BLE. > Thanks Alan Bluetooth LE, which is why I put a SiLabs module on the board and have it working, but thought "hey, I might be able to offload the cost of the module to the customer, and they can use a USB dongle if they actually want to use Bluetooth (not all users will)". If not, so be it.
RE: USB Host and Bluetooth "dongle".
> >> Hi Tim, > >> > >> It depends on what you refers to Bluetooth: is it Bluetooth Classic > >> or BLE ? > >> > >> If you want BT BLE maybe it is better to use a MCU with BLE. > >> > > > > Thanks Alan > > Bluetooth LE, which is why I put a SiLabs module on the board and have > > it working, but thought "hey, I might be able to offload the cost of > > the module to the customer, and they can use a USB dongle if they > > actually want to use Bluetooth (not all users will)". > > > > And you can further offload the price of USB Dongle Bluetooth using a MCU > with BLE. > > Currently you have three MCUs with BLE support on NuttX: ESP32 (driver is > coming soon), Bouffalo BL-602 and Nordic nRF52832. > > I work at Espressif, so I want to suggest you to consider ESP32! ;-) Main processor is SAMA5D27C as there are many many peripherals on this custom board (LCD/CAN/GPS/Accelerometers/multiple RGB LED drivers) and a SiLabs/Bouffalo/Nordic SoC will not "cut the mustard" as the main processor; Bluetooth LE is just one of many things not the "main deal". This is why I put the SiLabs SoC on the board as I have used it before with great success and it's not that expensive of course. In this case it's a "network co-processor". The SIG licensing costs mean - and they have not clarified this to me as yet - that there is a possibility that a board with USB and a Bluetooth stack but no radio module included *may* not need the $8k declaration fee which is completely out of step with the target volumes of this design. I was/am hoping that using a plug-in radio module via USB, of the customer's choice (i.e. not supplied as part of the product) works around the need to declare the product. But this is probably cloud-cuckoo land lol. With hindsight, Wi-Fi may have been a much better choice :(
FUSB301 driver
I am in need of a driver for an FUSB301 USB C Controller/PD device. I see there are drivers for the FUSB301 and FUSB303 but not the FUSB302. Before I have a stab at porting the outline code I already have for this device, and finishing it off to become a "proper" NuttX driver (and potentially making it my first ever contribution), I thought I would ask first to see if there is one lurking somewhere and I just missed it? Also, a question from an old-school SW developer and (therefore) GitHub & Apache/incubator newbie: if I simply want to ask advice do I still email dev@nuttx.apache.org <mailto:dev@nuttx.apache.org> or should it be to a different email address? I see some emails I get from the reflector (if that's what it's called) have an unsubscribe option, whereas others do not and it seems to relate to how the question/comment has originated? Be kind to me :) Thanks, Tim Hardisty
RE: FUSB301 driver
On Wed, Apr 21, 2021 at 9:04 AM Tim > wrote: >> I am in need of a driver for an FUSB301 USB C Controller/PD device. I see >> there are drivers for the FUSB301 and FUSB303 but not the FUSB302. >> >> >> >> Before I have a stab at porting the outline code I already have for this >> device, and finishing it off to become a "proper" NuttX driver (and >> potentially making it my first ever contribution), I thought I would ask >> first to see if there is one lurking somewhere and I just missed it? >> >> >> >> Also, a question from an old-school SW developer and (therefore) GitHub & >> Apache/incubator newbie: if I simply want to ask advice do I still email >> dev@nuttx.apache.org <mailto:dev@nuttx.apache.org>> or should it be to a >> different email address? I see some emails I get from the reflector (if >> that's what it's called) have an unsubscribe option, whereas others do not >> and it seems to relate to how the question/comment has originated? Be kind >> to me :) >Hello Tim, >I can't answer your first question about the FUSB30x driver(s), but >regarding your second question: Yes, dev@nuttx.apache.org is the correct >place to discuss NuttX-related subjects, including development (as the name >dev@ implies) and user questions. But if you ever need to report security >issues, those should not be publicly disclosed until we release a fix, so >please report such issues to priv...@nuttx.apache.org instead. >We're always glad to have new contributors! Feel free to open a Pull >Request at GitHub at any time. See this helpful link: >https://nuttx.apache.org/docs/latest/contributing/index.html >In particular, the page Making Changes Using Git (second from the top) will >help walk you through the process of dealing with GitHub etc. >Cheers, >Nathan Thanks Nathan. I only found this reply on the mail archives - I never had a notification of a reply for some reason :( I have been reading up on how to use Github - and the link you provided - and am poised to start doing this "properly": I have found a number of errors in SamA5 related files and rather than raise them as issues it makes more sense for me to fix them I think. These easy fixes will get me used to the process and I will then feel more confident in submitting new drivers - it looks like I'll be creating at least 4 that may just be of use to someone else (FUSB302 USB C Controller, ACT8945 Power Management , LP5036 multi-channel RGB LED driver, ADPS-9901 ambient light/proximity sensor.).
RE: FUSB301 driver
> > Thanks Nathan. I only found this reply on the mail archives - I never
> > had a notification of a reply for some reason :(
>
> Are you subscribed to the mailing list?
I got this reply and see many other emails coming in, and unsubscribe from most.
>> Perhaps something is misconfigured -- looking at your email address as it
>> appears in this message, it ends with (dot) com (dot) invalid. You can see
>> that
>> on the first line above ("On Mon, Apr 26...") I am not sure where the (dot)
> invalid is coming from.
It looks to be configured correctly but sometime I see random issues due to it
being a (dot) uk (dot) com domain
CAN example crashes
Hi, SAMA5D27 (custom board) - trying to complete the port and also check that the CAN interface works on the board, so I'm trying to use the CAN example app. The drivers appear to be registered (I see /dev/can0 and /dev/can1) but the CAN example app crashes when trying to open /dev/can0 and I can't see why. I am hindered in debugging this fully as yet since: a. I am new to Nuttx and haven't yet sussed how to enable any low level debug-type stuff (I have used menuconfig to enable anything that seems to be related but I'm sure I missed stuff) b. I haven't yet coerced my Eclipse IDE (under Windows 10, but code configured and compiled using Windows WSL) to "see" the source code properly to enable me to insert breakpoints (Segger J-link). Not wedded to Eclipse, but it is a known entity for me and at least downloads/runs/debugs the board!) Can anyone point me in the direction of why, or a way to find out why, the call to open the device would crash the board rather than return an error? Other devices (such as Flexcom USARTs open OK and work - well, after I fixed some arch issues for Flexcoms on the SAMA5 anyway!!). The board-specific code (sam_can.c) I am using is based on the code for the sama5d2-xult board and seems pretty trivial, and largely similar to many other architectures and boards. Many thanks, Tim.
Dev environment
Pulling my hair out here!! So apologies for the lengthy brain dump and plea for help! All this starts from the CAN init code crashing (SAMA5D27) when it makes any call to print debug messages. Printf itself is fine. I need to debug it. I will need to get to that point regardless. The only way I can actually get Nuttx to build is using WSL - compiles no problem at all. I have a MAC - it won't compile without errors and there's not enough info (for me) to see what the error is - some complaint about ./builtin_list.c Mac is the machine I know least. I have no "full" Linux machine. No experience of Cygwin and its ilk - just a minefield to me. I know Windows best, and have successfully used eclipse under Windows for Arm development for many years (sometimes compiling within eclipse, sometimes from a command prompt). But although I can download and run code via my jlink, eclipse will not correctly index the source code so I cannot debug or set breakpoints. So I went back to trying to get it to compile under the Mac but no joy so not even got as far as seeing if eclipse - or any other debugger- will run and do its job. Eclipse is pointing at the source code properly and even if I stop the program and manually point the eclipse debugger to the source code - where I have inserted a while(1); - it completely refuses to pick up the source code. I am suspected a "\" vs "/" issue or something dumb. This is true either for a project pointing to a clone in the WSL location or in a more native windows location I have not succeeded in getting Nuttx to build via eclipse (in Windows) either - although my "Bare Metal" SAMA5 code compiles just fine with the eclipse GNU cross compilers and debugs nicely. I thought maybe I could run an X-windows emulator on my Win 10 machine and run eclipse on WSL...but it doesn't get very far and just throws errors. Thought I'd try Visual GDB - no SAMA5D2 support it seems. Tried to run OpenOCD (which purported to be "Windows ready") but it doesn't run. Has anyone got NuttX to successfully compile, and allow debug, under either MAC or Windows. At all? Ever? If someone has any pointers I will be extremely grateful, as this is doing my head in. I really don't want to waste yet more days finding a machine to build up exclusively for Linux unless I REALLY have to!!!
RE: Dev environment
>From: Gregory Nutt
>Sent: 11 May 2021 18:33
>
>> All this starts from the CAN init code crashing (SAMA5D27) when it
>> makes any call to print debug messages. Printf itself is fine.
>These kinds of crashes are often due to stack overrun. It might be worth
>increasing the stack size of the task that calls CAN init.
I have only just had a moment to take another look. This is the basic nsh
config, with just the CAN example enabled. Heap size is the standard 2048,
but if I increase to 4096 it still crashes in the same place:
int sam_can_setup(void)
{
#if defined(CONFIG_CAN)
int ret;
printf("PRINTF: Setting up CAN\n");
#if defined CONFIG_DEBUG_CAN_INFO
caninfo("CANINFO: Setting up CAN\n");
while(1);
...etc
I get the printf text on the console but not the caninfo message. The
program is stopped in the while(1) loop. I still can't debug this, but
that's a different problem. If I use the Eclipse debugger to pause the
program it clearly states it has a thread for sam_can_setup() at sam_can.c
and is trying to find the source but Eclipse reports:
Can't find a source file at
"/home/timh/nuttx/nuttx/boards/arm/sama5/jti-toucan2/src/sam_can.c"
Locate the file or edit the source lookup path to include its location.
That is not the full path from a Windows POV which is quite possible the
issue - Windows knows the path as:
C:\Users\TimHardisty\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWi
ndows_79rhkp1fndgsc\LocalState\rootfs\home\timh\nuttx\nuttx\boards\arm\sama5
\jti-toucan2\src
I have made sure that is the path configured in Eclipse, but it seems not to
respect that.
If you or anyone has other suggestions (and I will reply to the suggestions
others made in a moment) then I will give anything ago but I am currently
investigating either a 3rd machine to just run Ubuntu or a VM on my Win10
machine or dual booting my Mac. But, quite probably, buying a machine is a
better bang for the buck, for me as a professional engineer, rather than
spending time playing around with VMs or other "tricks" that might work but
suck up time! If a £500 mini PC sorts it, then on reflection I'll be a happy
chappy!
RE: Dev environment
>Brennan Ashton Tue, 11 May 2021 13:12:50 -0700 wrote >So back to your root issue, you said you were having issue setting >breakpoint and getting that to line up with the code, did you enable the >debug symbols in menu config? Yes: - Enable Debug Features checked - Enable Error Output checked - Enable Warnings Output checked - Enable Information Debug Output checked - Enable Debug Assertions checked - CAN Debug Features/Error Output/Warning output all checked - Optimization supressed to give the debugger the best chance Can't find anything else right now, so hopefully I got everything checked that I need. >Are you able to flash the device using the eclipse debugger? I have flashed the AT91bootloader and Uboot using the Jlink and a sam-ba calls from a good-old DOS batch file. Works fine. Code is downloaded via JTAG from within eclipse no problem at all.
RE: Dev environment
> Disruptive Solutions Tue, 11 May 2021 09:50:53 -0700 wrote >Maybe I can try to help you concerning this matter. How can we >connect? Do you have telegram? WhatsApp, Signal, email, FB Messenger...but not Telegram :) Email me if you like and we can go from there - guess you will need to remove the rather odd .INVALID that seems to be added in to my email address via this system.
Assert and Debug issues
Further to my question relating to the CAN example crashing I have found
that the issue is more generic.
1) If I enable Debug Assertions the build will not run at all as it halts
very very early on. Debugger suggests the system is in up_idle().
2) Any (valid and enabled) call for a debug info/warn/error message produces
no actual message on the console. Not just in the CAN example but others
too. Console (and nsh) working fine. For example, the PWM example works just
fine. If I enable debug messages for this it doesn't crash, still works as
expected, but no debug message text. FYI I added this to the example to
prove the point:
#if defined CONFIG_DEBUG_PWM_INFO
printf("PWM_WARN_PRINTF_DEBUG\n");
pwmerr("PWMINFO: starting pwm example PWM\n");
#else
printf("JUST A PWM WARN PRINTF\n");
#endif
I get the "PWM_WARN_PRINTF_DEBUG" text on the console, but not the "PWMINFO:
starting pwm example PWM" text.
3) In the case of the CAN example I have been trying to get working, the
call to open the CAN port open() (/dev/can0) causes a crash - debugger shows
it's in arm_assert.c but implies it's the "armv7-a/arm_assert.c" file.
There is no specific assert file in the sama5 arch folders. Is that right?
Problem 3) is most likely a silly silly bug in my modified CAN init code
that I've created for the SAMA5D27 (so I can register both CAN devices), but
without assert or debug messages working - and until I get my dev
environment properly sorted so I can add breakpoints and inspect the code
etc. - I am limited to a bit of prodding in the dark.
But I am trying to continue to basically prove my board is actually OK from
a hardware point of view.
Can anyone offer any insight into why Assert and debug info/warn/error
messages are "misbehaving" like this?
RE: Dev environment
Eventually got a Linux dev environment up and running (first PC purchased failed after a few hours...grrr...now have an Intel i5 NUC for this). Amazed how darn fast compilation is compared to WSL (even on my 3.3GHz Zeon-based workstation with the -j6 make option) so that in itself means it was a great move! Always liked Linux anyway lol. Eclipse (latest version) still not playing ball - just won't debug. So I'm assuming a platform independent setup issue with it; aka finger trouble :( I am temporarily using Segger Ozone - worked first time and can finally debug. Not sure I like it but hey ho. As an aside, has anyone got a recommendation of a good, graphical, GDB debugger for Linux, that place nicely with NuttX? Not bothered about an IDE as such, and I'm 100% happy with building via terminal, but a feature rich and easy to use debugger that looks up the source code "thoroughly" is an essential. But, now I can set breakpoints, I found that lack of debug messages on the console was because the .config was sending them to RAM not CONSOLE, because that's what is in the sama5d2-xult defconfig file I based my custom config on. Simple explanation, but is this documented anywhere? Can't find that level of syslog stuff using make menuconfig? Also now, at least, I know that the board is crashing in can_hwinitialize when it calls can_putreg(priv, SAM_PMC_PCR, regval)...so next week's task is to find out what's up with this (it's not my code). >>On 5/12/21, Tim Hardisty wrote: >>>>From: Alan Carvalho de Assis >>>> >>>>Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig? >>>> >>>> │ -> Build Setup >>>> │ >>>> │ -> Debug Options >>>> │ >>>> │ -> Enable Debug Features (DEBUG_FEATURES [=y]) >>>> │ >>>> │ -> CAN Debug Features (DEBUG_CAN [=y]) >>>> >>> >>> Indeed I did. And, anyway, even if I hadn't my debug message might >>> appear but the system would keep running, but it doesn't: it crashes. >>> I have inserted the while(1) to narrow it down to where it >>> crashesit is the call to that debug message that does it :( >>> >> >>Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the >>caninfo() and the while(1); just for a double check ;-) >> >>By PIO_LED_YOURLED I mean the LED that is turning ON when your board >>initializes. >> >>Talking about LEDs... other important thing: normally when NuttX >>crashes the board LED start to blink to indicate an issue, is it blinking on >>your >board? > >This is a custom board, and no LED such as that. I have removed any LED- >related stuff from the board.h file...is that the issue? Maybe NuttX absolutely >depends on some kind of LED?
Memory locations
This is probably not really a NuttX question per se, but it relates to getting the MCAN interface for a sama5d2 to work properly. And you are all such knowledgable and helpful people :) The MCAN controllers assume the base address of the message ram is at 0x20+offsets. 0x20 is the internal SRAM whereas everything else is in DDR from 0x200. I will readily confess that this side of programming is my very weakest!! I will, I believe, need to declare - place - MCAN related structures such that they (or at least some elements of them) are in SRAM. Is that possible? "CONFIG_MM_REGIONS" related maybe? What does the internal SRAM get used for as the system.map file lists nothing there at all. Or have I got it wrong and this isn't the way to sort it - perhaps the processor DMA "matrix" stuff (hope not - don't understand the datasheet section on this at all!)? Thanks! Tim.
sama5d2 mcan - procedure to fix
Hi all Thanks to the assistance given here I now have MCAN working on a sama5D27 processor. The changes need to apply to all sama5d2x processors. I have forked and bracnched the master repository for this and will submit pull requests once I completed the work and tested it more thorougly - and sorted the Kconfig files etc. The same will apply to flexcom ports as well (sama5d3 is not the same as sama5d2 in this area either) and possibly other things I'm yet to find of course This will all take a month or more (elapsed) but should I formally report these as issues via Github, along with some notes that may assist anyone else using this family in the mean time? Or just wait until it's all done and dusted and do my PRs in one hit with/without raising them as actual issues? Can't find guidance on this in the "Contributing" notes. TIA, Tim.
RE: Memory locations
Thanks for everyone's help on this. All working now. It transpires the msgram can be in SDRAM not just in ISRAM so the solution is much more like the samV71 using cached memory, but it is handled a little differently in a few places of course. No thanks AT ALL to the Atmel datasheet which says: "The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are configured in 0x0020". I took "in" to mean "as". The statement makes even less sense anyway, as they are actually configured in a Special Function Register which is not referenced in the MCAN section at all...and default to 0x200020 in actual fact! So, much time was wasted :( But boy have I learned a lot these last few weeks LOL.
sama5d27 UPLL
Hi, Making slow progress getting MCAN sorted properly on my custom sama5d27 board and when clocking it from the "UPLL" clokc (an internal PLL used to generate a 480MHz clock for the USB interfaces, and a useful clock for higher speed CAN setups) I found that the CAN baud rate was out. This is because there is a special function register (SFR) that has to be set to reflect the crystal frequency used. This is correctly set by the AT91 bootloader and/or Uboot (I can read it at the start of the bringup code OK) but somewhere it is being changed to the wrong value again and I can't find where - a grep for the relevant SFR register in all of the nuttx code doesn't reveal anything (it only exists in my code or the sam_sfr header file as far as I can see) I have done a quick fix by re-writing the correct value in my bringup code but that isn't the right way to sort this. Any suggestions of how to find where/why/how this is being changed? Thanks, Tim.
RE: Creating our own driver in NUCLEO-H743ZI2 with Nuttx rtos
An earlier screen shot showed a compiler warning for the function being
implicitly declared - so no lower driver function is actually present/included?
Surprised it's just a warning though.
>-Original Message-
>From: Alan Carvalho de Assis
>Sent: 18 August 2021 12:38
>To: dev@nuttx.apache.org
>Subject: Re: Creating our own driver in NUCLEO-H743ZI2 with Nuttx rtos
>
>Hi Rushikesh,
>
>Since it is there the /dev/userleds0 should be registered.
>
>Please open your drivers/leds/userled_lower.c and modify it to print some info:
>
>int userled_lower_initialize(FAR const char *devname) {
> int ret;
>
> ledinfo("Initializing LEDs\n");
>
> g_lednum = board_userled_initialize();
> ret = userled_register(devname, &g_userled_lower);
> if (ret < 0)
>{
> lederr("Failed to register userled: %d\n", ret);
>}
>}
>
>Then run it with LED debug enabled.
>
>BR,
>
>Alan
>
>On 8/18/21, rushi ghatkar wrote:
>> Hi @Alan sir,
>>
>> Found *System.map* and checked for *userled_lower_initialise* and it's
>> there. Means my firmware has it. Please find the attached image.
>>
>> Then what is the problem? and how to solve it?
>>
>>
>>
>> Regards,
>> Rushikesh
>>
>> On Wed, Aug 18, 2021 at 4:39 PM Alan Carvalho de Assis
>>
>> wrote:
>>
>>> "Open your System.map and search for userled_lower_initialize"
>>>
>>> On 8/18/21, rushi ghatkar wrote:
>>> > Hi,
>>> >
>>> > @Alan sir, I have enabled the debug option and checked, it still
>>> > gives
>>> the
>>> > same error message in nsh> prompt whenever I run the built-in
>>> > driver or
>>> my
>>> > own driver.
>>> > Please find the attached image.
>>> >
>>> > it's not reaching to* /dev/userleds* path.
>>> >
>>> >
>>> > Regards,
>>> > Rushikesh Ghatkar
>>> >
>>> > On Tue, Aug 17, 2021 at 6:59 PM Alan Carvalho de Assis <
>>> acas...@gmail.com>
>>> > wrote:
>>> >
>>> >> The /dev/userleds is created this way:
>>> >>
>>> >> ret = userled_lower_initialize("/dev/userleds");
>>> >>
>>> >> Open your System.map and search for userled_lower_initialize, if
>>> >> you find it, this mean your firmware has it and the issue is
>>> >> probably some error during the initialization.
>>> >>
>>> >> *Please* enable the DEBUG LEDS:
>>> >>
>>> >> Build Setup --->
>>> >> Debug Options --->
>>> >> [*] Enable Debug Features
>>> >> [*] Enable Error Output
>>> >> [*] Enable Warnings Output
>>> >> [*] Low-level LED Debug Features
>>> >> [*] LED Driver Error Output
>>> >> [*] LED Driver Warnings Output
>>> >> [*] LED Driver Informational Output
>>> >>
>>> >> BR,
>>> >>
>>> >> Alan
>>> >>
>>> >> On 8/17/21, rushi ghatkar wrote:
>>> >> > Hi,
>>> >> >
>>> >> > How to create * /dev/userleds* ?
>>> >> >
>>> >> > I have searched for it but can't find it.
>>> >> > Need Help.
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> > Rushikesh Ghatkar
>>> >> >
>>> >> > On Mon, Aug 16, 2021 at 6:32 PM Alan Carvalho de Assis <
>>> >> acas...@gmail.com>
>>> >> > wrote:
>>> >> >
>>> >> >> Did you look at /dev? I think the /dev/userleds is not created.
>>> >> >>
>>> >> >> Try to enable the DEBUG LED to see that is going on.
>>> >> >>
>>> >> >> BR,
>>> >> >>
>>> >> >> Alan
>>> >> >>
>>> >> >> On 8/16/21, rushi ghatkar wrote:
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > I have changed the declaration but it still gives some warning.
>>> >> >> > Please
>>> >> >> find
>>> >> >> > the attached image.
>>> >> >> >
>>> >> >> > and when I flash code and use picocom it still gives an error.
>>> >> >> > Please
>>> >> >> find
>>> >> >> > the attachment.
>>> >> >> >
>>> >> >> >
>>> >> >> > Regards,
>>> >> >> > Rushikesh Ghatkar
>>> >> >> >
>>> >> >> > On Mon, Aug 16, 2021 at 5:25 PM Alan Carvalho de Assis <
>>> >> >> acas...@gmail.com>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> You need to declare all LEDs, including GPIO_LED_BLUE
>>> >> >> >>
>>> >> >> >> This is the pin on your board used for each LED.
>>> >> >> >>
>>> >> >> >> Please look at stm32h747i-disco/src/stm32h747i-disco.h for
>>> >> >> >> reference.
>>> >> >> >>
>>> >> >> >> BR,
>>> >> >> >>
>>> >> >> >> Alan
>>> >> >> >>
>>> >> >> >> On 8/16/21, rushi ghatkar wrote:
>>> >> >> >> > Hi Alan sir,
>>> >> >> >> >
>>> >> >> >> > I have disabled the status/diagnostic LEDs compete for the
>>> >> >> >> > use
>>> of
>>> >> >> LEDs.
>>> >> >> >> > So disabled it:
>>> >> >> >> > Board Selection --->
>>> >> >> >> > [ ] Board LED Status support
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > Yes my board does support * userleds support*:
>>> >> >> >> > boards/arm/stm32h7/nucleo-h743zi2/src/stm32_userleds.c
>>> >> >> >> >
>>> >> >> >> > But still it gives error, please see the error image attached.
>>> >> >> >> >
>>> >> >> >> > AR (create): libbinfmt.a binfmt_globals.o
>>> >> >> >> > binfmt_initialize.o
>>> >> >> >> > binfmt_register.o binfmt_unregister.o binfmt_loadmodule.o
>>> >> >> >> > binfmt_unloadmodule.o binfmt_execmodule.o binfmt_exec.o
>>> >> >> >> > binfmt_copyargv.o binfmt_dumpmodule.o builti
nxfss on MT25Q nor flash
Does anyone have any pointers on how to setup nxfss (or any filesystem for that matter) on an MT25Q nor flash? I cannot find any code for any other boards that makes any sense to me and I feel this should be a pretty basic thing to want to do? I believe I have set up all the SPI stuff and now need to (auto)mount it in my bringup or app init code, but I'm stuck :( "CONFIG_HAVE_M25P" is as far as I have got. SAMA5D27 device. TIA, Tim.
RE: nxfss on MT25Q nor flash
>From: Alan Carvalho de Assis > >It seams like MT25Q uses the m25px.c driver, so I assume you are enabling the >CONFIG_MT25Q_MEMORY_TYPE right? Yes = my .config has CONFIG_MT25Q_MEMORY_TYPE set > >Next you need to configure our board SPI CS pin, please take a look >at: arm/stm32/mikroe-stm32f4/src/stm32_spi.c > Yes, I have defined the PIOs etc. >Then before try to setup the NXFFS you need to confirm that the Flash NOR was >detected correctly. How, in code or from the nsh, do I do that? I know the chip works as I've used it (for example) for u-boot environment variables with no issue, but I can't find the way to either mount it, or "probe" it, or anything, from nuttx. It doesn’t appear as a /dev. No doubt it's in some documentation somewhere > >On 8/24/21, Tim wrote: >> Does anyone have any pointers on how to setup nxfss (or any filesystem >> for that matter) on an MT25Q nor flash? >> >> >> >> I cannot find any code for any other boards that makes any sense to me >> and I feel this should be a pretty basic thing to want to do? I >> believe I have set up all the SPI stuff and now need to (auto)mount it >> in my bringup or app init code, but I'm stuck :(
RE: nxfss on MT25Q nor flash
Hi Alan, >Hi Tim, > >On 8/24/21, Tim wrote: >> >>>Then before try to setup the NXFFS you need to confirm that the Flash >>>NOR was detected correctly. >> >> How, in code or from the nsh, do I do that? I know the chip works as >> I've used it (for example) for u-boot environment variables with no >> issue, but I can't find the way to either mount it, or "probe" it, or >> anything, from nuttx. It doesn’t appear as a /dev. >> > >You can enable the CONFIG_DEBUG_FS_* to see the mtd debug messages. It will >tell you want is going on. > Yes, I have done that of course, but get no messages. I am sure this is simply because there is no code being called to register the driver as I can't find an example for any other boards that looks relevant :(
SPI EEPROM
The more time I spend with nuttx the more I think I just haven't found some treasure trove of documentation somewhere. All I seem to end up doing is searching every single file for some kind of clue as to what to do! I have an SPI EEPROM device. Menuconfig allows me to set it up, lovely! I end up with CONFIG_EEPROM=y CONFIG_SPI_EE_25XX=y (Also SPI mode and frequency). Now what.. If I search for either of those CONFIG parameters, the first is not referenced anywhere (apart from my .config), the second confirms that it will include spi_xx25xx.c as a source. Getting there.. It'll be ee25xx_initialize(FAR struct spi_dev_s *dev, FAR char *devname, int devtype, int readonly) I need to call - makes sense. Only there is no explanation, or examples of, how to make that call, and a Google search doesn't help either. Next step will be to look for examples of spi_dev_s and see if I can deduce it somehow. Just how am I supposed to know how to call that initialisation code? Which is why I started this question with the observation that surely I must be missing something somewhere!!?? Yes, it's a bit of a whinge, but also a request for help..please :)
RE: nxfss on MT25Q nor flash
No, it's not in the system map. Having now searched for it I see there's a possibly useful example in stm32_appinit.c so I will wade through that. How was I supposed to know what to look for!!?? >Ok, did you open your System.map and searched for m25p_initialize() ? > >Few days ago I gave someone else this same tip (and another) and he got things >working, please take a look on our email history. > >BR, > >Alan >
RE: nxfss on MT25Q nor flash
There is support for MT25Q128 and I have now added the MT25Q256 It is in nuttx/drivers/mtd/m25px.c and I will add to the list of PRs once I have everything sorted on my board. Subject: Re: nxfss on MT25Q nor flash BTW, do we have a driver for MT25Q? I can't see one. Is it compatible with the M25P series?
which filesystem?
I seem to have got over most of my SPI flash and EEPROM issues now and my
256Mb SPI flash is properly recognised.
I think I am at the last hurdle. Here is the console output, along with my
question of the day :)
Successfully initialized M25P SPI
m25p_initialize: dev: 0x2005b970
m25p_readid: priv: 0x2005b990
m25p_readid: manufacturer: 20 memory: ba capacity: 19
m25p_initialize: Return 0x2005b990
Successfully bound SPI0 CS1 to the SPI FLASH driver
m25p_ioctl: cmd: 1537
m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192
m25p_ioctl: return 0
m25p_bread: startblock: nblocks: 1
m25p_read: offset: nbytes: 256
m25p_waitwritecomplete: Complete
m25p_read: return nbytes: 256
nxffs_nextentry: No entry found
nxffs_limits: No inodes found
nxffs_limits: Free FLASH region begins at offset: 5
nxffs_limits: First inode at offset 5
Succesfully initialised NXFSS
nx_mount: ERROR: Failed to find block driver (null)
Failed to mount the NXFSS volume -15
I believe the block driver would be "/dev/M25P" (M25P, for example) but
there is no code I have found that specifies the block driver location. I
have:
ret = nxfss_initialize(mtd);
then
ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);
and that seems to be in common with other "bringup" code; using NULL rather
than "/dev/something".
Just need the last piece of this jigsaw if anyone could be so kind :)
RE: which filesystem?
Emails from Sara have not come through, or are garbled, I don't understand why. So I can't quote and have had to look at the archives. Mine get tagged as if my email is "INVALID", which it isn't. Sigh. But...I had a typo in the "mount" call and had "nxfss" rather than "nxffs" (I didn't copy/paste the lines of code yesterday but manually typed them...Linux dev machine, Win10 email machinebad bad bad move! Should know better. Go to the bottom of the class). This now works, with or without the FTL involved and I have a 32Mbyte mounted flash drive to play with :) Once again, thanks everyone.
SAMA5 flexcom SPI
Hi, Based on arch/arm/src/sama5/hardware/sam_flexcom_spi.h being devoid of any #defines for flexcom SPI registers (etc.) is it fair to assume this has not been done by anyone yet? Same applies for flexcom TWI (not that I actually need that right now). Don't want to spend time implementing this if I'm missing something! A search through all files suggests flexcom SPI has only been done for NXP LPC54x processors. Thanks, Tim.
RE: Custom audio capabilities
I appreciate no one may have any comments or suggestions but since I have had no replies to my last 2 or 3 questions, could someone kindly just reply with a "hello" or something, simply to confirm my emails are getting through OK? >-Original Message- >From: TimH >Sent: 21 November 2021 16:45 >To: dev@nuttx.apache.org >Subject: Re: Custom audio capabilities > >On 20/11/2021 13:40, TimH wrote: >> Hi, >> >> I'm adding arch support for the sama5d2 Class D audio peripheral. >> >> This has bass cut/boost and treble cut/boost capabilities which don't >> fit (as best as I can tell) with the current set of audio driver >> capabilities and are, quite probably, unique to this device and not >> applicable to others (right now at least). >> >> I don't think this a case where custom board_ioctl commands are >> relevant as it is chip specific not board specific. >> >> This could be a case of I'm the only one who ever wants to expose this >> so I could go down that route but assuming it's not technically the >> right approach, what is, please? >> >> Thanks, >> >> Tim. >> >Since "Feature Unit" controls has run out of bit positions for anything new, >how >about I add the new sama5d2 boost/cut modes into the Processing Unit >category? Not a great fit but perhaps acceptable?
RE: Custom audio capabilities
Thanks David - I saw that my emails are in the archive but since my email address always seems to get a .INVALID suffix applied in the From: field (really got no idea why!) I was not 100% sure they were being distributed/reflected reliably. >Hi Tim, > >Emails are getting to the list. > >David > > >I appreciate no one may have any comments or suggestions but since I have had >no replies to my last 2 or 3 questions, could someone kindly just reply with a >"hello" or something, simply to confirm my emails are getting through OK?
RE: Custom audio capabilities
Thanks Alan - I do agree it isn't a custom feature. The subsystem has "Feature Units" which includes "AUDIO_FU_EQUALIZER" as a control. This doesn't seem to be implemented for any processors or boards that I can see, nor is there any generic code for this; just the #define in include/audio.h. My thinking now is perhaps to add some sub-feature #defines (e.g. AUDIO_FU_SUBEQUALIZER_BASS_BOOST_PLUS6) to be used as subtypes when capabilities are queried for AUDIO_TYPE_FEATURE and for the audio_configure function to make use of. As far as I see no drivers or apps currently support AUDIO_FU_EQUALIZER so it's unlikely anything will get broken doing this, but it will allow me to make use it "properly". Something like that, anyway! Just need to get the Class D peripheral up and running in Nuttx first...driver struct and pointer initializations are doing my head in at the moment lol. >-Original Message- >From: Alan Carvalho de Assis >Sent: 22 November 2021 12:45 >To: dev@nuttx.apache.org >Subject: Re: Custom audio capabilities > >Hi Tim, > >Since some audio codec supports these features, I think the audio subsystem of >NuttX needs to be prepared to support it, doesn't seen to be like a "custom" >feature. > >But even on Linux these features seams a little hidden on ALSA and you need to >right tool to get access to it, see: > >https://askubuntu.com/questions/954601/how-to-get-bass-boost-in-ubuntu- >just-like-windows-has > >BR, > >Alan > >On 11/21/21, TimH wrote: >> On 20/11/2021 13:40, TimH wrote: >>> Hi, >>> >>> I'm adding arch support for the sama5d2 Class D audio peripheral. >>> >>> This has bass cut/boost and treble cut/boost capabilities which don't >>> fit (as best as I can tell) with the current set of audio driver >>> capabilities and are, quite probably, unique to this device and not >>> applicable to others (right now at least). >>> >>> I don't think this a case where custom board_ioctl commands are >>> relevant as it is chip specific not board specific. >>> >>> This could be a case of I'm the only one who ever wants to expose >>> this so I could go down that route but assuming it's not technically >>> the right approach, what is, please? >>> >>> Thanks, >>> >>> Tim. >>> >> Since "Feature Unit" controls has run out of bit positions for >> anything new, how about I add the new sama5d2 boost/cut modes into the >> Processing Unit category? Not a great fit but perhaps acceptable? >> >>
RE: Custom audio capabilities
>On 11/22/21 5:38 AM, Tim wrote: >> My thinking now is perhaps to add some sub-feature #defines (e.g. >>AUDIO_FU_SUBEQUALIZER_BASS_BOOST_PLUS6) to be used as subtypes when >>capabilities are queried for AUDIO_TYPE_FEATURE and for the audio_configure >>function to make use of. As far as I see no drivers or apps currently support >>AUDIO_FU_EQUALIZER so it's unlikely anything will get broken doing this, but >>it >>will allow me to make use it "properly". >> >> >Hey Tim, > >You are correct that AUDIO_FU_EQUALIZER feature is not implemented >anywhere. There are probably several other "features" that are also not >implmented. When I added the audio subsystem circa 2014, I defined the header >files and structures to be extensible even before implementing the first actual >audio device. That way I could determine if I had the needed control in the >structures for expandability. In creating those headers, I included audio >features >present in USB type audio devices (which I was using as a reference), and that >is >why the feature is present but not implemented. > Hi Ken, Thanks for the information and background. The sama5d2 I am working with doesn't have a parametric equaliser, which is possibly what AUDIO_FU_EQUALIZER was intended for? It just has bass/mid/treble boost and cuts, only one of which can be active at a time; but it is described as an equalizer in the datasheet. Is it OK with all for me to use AUDIO_FU_EQUALIZER for this (I need 14 states which pretty much eats up the bit-fields)? Then if someone wants or needs to add a full blown parametric equalizer in the future they can use a complete feature type, such as AUDIO_TYPE_PROCESSING with a new control such as AUDIO_PU_PARAMETRIC? If so, I might suggest making it a little more generic than the specific boost/cuts offered by the sama5d2 and just have #define AUDIO_FU_EQUALIZER_MODE00x #define AUDIO_FU_EQUALIZER_MODE10x0001 . . #define AUDIO_FU_EQUALIZER_MODE15 0x8000 The audio driver would then describe what those modes mean to the peripheral itself. Am I on the right track here?
FUSB302
There are some drivers for the OnSemo USB C FUSB301 and FUSB303 devices available in the NuttX tree, and they will make a good basis for me to create a driver for the FUSB302 device I chose to use. But there's a copyright notice in each saying: * Copyright (C) 2019 Haltian Ltd. All rights reserved. * Authors: Harri Luhtala *Juha Niskanen Also the usual requirement to include the exact same copyright notice in anything derived from them. Is that just out of date and it should have been replace by the usual ASF license boilerplate? Or OK to simply keep their notice? I don't want to plunder from these files if it is not correct to do so!
RE: FUSB302
OK, thanks - should have thought to check for any updates - sorry. Yes, still got the 10.1 tree I think it is, from 7 or 8 months. Will need to do whatever I need to do to get the latest but not a priority right now: GitHub still scares me! >-Original Message- >From: Abdelatif Guettouche >Sent: 01 December 2021 16:21 >To: dev@nuttx.apache.org >Subject: Re: FUSB302 > >Haltian has submitted an SGA and we can convert their license. You must have >an >old tree since all their code now has the ASF header. >https://github.com/apache/incubator-nuttx/pull/4831 >https://github.com/apache/incubator- >nuttx/blob/master/drivers/usbmisc/fusb301.c#L1-L19 > >On Wed, Dec 1, 2021 at 5:08 PM Tim wrote: >> >> There are some drivers for the OnSemo USB C FUSB301 and FUSB303 >> devices available in the NuttX tree, and they will make a good basis >> for me to create a driver for the FUSB302 device I chose to use. >> >> But there's a copyright notice in each saying: >> >> * Copyright (C) 2019 Haltian Ltd. All rights reserved. >> * Authors: Harri Luhtala >> *Juha Niskanen >> >> Also the usual requirement to include the exact same copyright notice >> in anything derived from them. >> >> Is that just out of date and it should have been replace by the usual >> ASF license boilerplate? Or OK to simply keep their notice? >> >> I don't want to plunder from these files if it is not correct to do so! >> >>
RE: Control Task #2 from Task #1
My POSIX knowledge is still somewhat limited, but I believe it's this: https://nuttx.apache.org/docs/latest/reference/user/07_signals.html >-Original Message- >From: Swapna Iyer >Sent: 09 December 2021 17:25 > >Is there any example I can look at? > >Swapna Iyer >swa...@lightmatter.co > > > >> On Dec 7, 2021, at 11:37 AM, Swapna Iyer wrote: >> >> Hi, >> >> How can I enable a Nuttx task (task #1) to control another Nuttx task (task #2)? >In FreeRTOS, I was able to use task_suspend(task_handle of task #2) and >task_resume(task_handle of task #2) from task #1 to control task #2. >> >> How can I best do this in Nuttx? >> >> Best, >> >> Swapna Iyer >> swa...@lightmatter.co >> >> >>
USB device detect
Hi, Usual USB connect would be via a VBUS interrupt I imagine, but I'm struggling to find the "hooks" in the code that react to this. It "just works" for eval boards but... ...in my case the detect is handled by a USB C FUSB302 device. The FUSB302 is detecting the connect and I can set it up as required but can't quite find how to call a "DEV_CONNECT" (or whatever it should be) - neither as a result of a traditional VCONN detect interrupt let alone as a software-initiated call. I will need to do the same for a host detect too (e.g. msd or keyboard attach). If anyone can point me in the right direction I'd appreciated it! Tim.
USB MSD problem
Hi, Having some grief getting USB MSD device to work, following some notes from Alan C. Assis from around 5 years ago. It is an MT25Q 32Mbyte spi nor flash device, registered as /dev/mtdblock0 and also mounted and initialised as an nxfss file system at /mnt/flash. I can read/write to it from nsh. If I run MSCONN, it crashes: nsh> msconn mcsonn_main: Creating block drivers find_blockdriver: pathname="/dev/mtdblock0" ftl_geometry: Entry ftl_geometry: available: true mediachanged: false writeenabled: true ftl_geometry: nsectors: 131072 sectorsize: 256 usbmsc_exportluns: Starting SCSI worker thread arm_dataabort: Data abort. PC: 2002f528 DFAR: e8bd8800 DFSR: 0005 up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 160 task: msco It seems to be somewhere in task_init and group_setuptaskfiles (duplicating files I think), but debugging deep inside NuttX is, um, scary! I'm hoping I've just not configured something else it needs; and I can't seem to find any relevant debug options to assist - USB MSC MM DEBUG seems to cause it all to hang up at a printf statement in the msconn app. Any thoughts, kind people? Thanks, Tim.
RE: USB MSD problem
Hi Alan, I am - right this minute - using GDB (well...VS Studio Code with Segger J-Link) and it falls over during the (second) call to file_dup2 in fs_files.c, on its second call (I believe related to usb_scsi_main), but not got further than that yet. Had no luck at all with other FS. FAT just results in: Nsh> mkfatfs -F 32 /dev/mtdblock0 mkfatfs_getgeometry: ERROR: Unsupported sector size: 256 nsh: mkfatfs: mkfatfs failed: 1 no -F or -r options make any difference Even tried a ramdisk: nsh> mkfats /dev/ram0 nsh: mkfats: command not found nsh> mkfatfs /dev/ram0 mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 29 < 254 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 1 sectors/cluster This suggests some fundamental - but obscure - CONFIG setting is enabled but who knows what! SmartFS fails too - just don't think it likes the size of the device - there are some variables as uint16_t's in the smartfs code and I think they need to be uint32_t's for this quite large device. Will try partitions at some point. Right now I am really regretting moving to NuttX as although I seem to be able to write drivers, fundamental stuff that, to me, just "should work" quite often doesn't :( Thanks, Tim. >-Original Message- >From: Alan Carvalho de Assis >Sent: 22 December 2021 12:22 >To: dev@nuttx.apache.org >Subject: Re: USB MSD problem > >Hi Tim, > >I don't know the root cause of the issue you are facing, but it could be some >memory misalignment. Try to use GDB to investigate where the crash is >happening. > >Also test using other File Systems, if you use USB MSD with FAT then your host OS >will show the content of the SPI Flash. > >BR, > >Alan > >On 12/21/21, Tim wrote: >> Hi, >> >> Having some grief getting USB MSD device to work, following some notes >> from Alan C. Assis from around 5 years ago. >> >> It is an MT25Q 32Mbyte spi nor flash device, registered as >> /dev/mtdblock0 and also mounted and initialised as an nxfss file >> system at /mnt/flash. I can read/write to it from nsh. >> >> If I run MSCONN, it crashes: >> >> nsh> msconn >> mcsonn_main: Creating block drivers >> find_blockdriver: pathname="/dev/mtdblock0" >> ftl_geometry: Entry >> ftl_geometry: available: true mediachanged: false writeenabled: true >> ftl_geometry: nsectors: 131072 sectorsize: 256 >> usbmsc_exportluns: Starting SCSI worker thread >> arm_dataabort: Data abort. PC: 2002f528 DFAR: e8bd8800 DFSR: 0005 >> up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 160 task: >> msco >> >> It seems to be somewhere in task_init and group_setuptaskfiles >> (duplicating files I think), but debugging deep inside NuttX is, um, scary! >> >> I'm hoping I've just not configured something else it needs; and I >> can't seem to find any relevant debug options to assist - USB MSC MM >> DEBUG seems to cause it all to hang up at a printf statement in the msconn app. >> >> Any thoughts, kind people? >> >> Thanks, Tim. >> >> >>
RE: USB MSD problem
>Here the issue is your ramdisk size. You need at least 64 sectors to be able to >format as FAT, try it: >https://acassis.wordpress.com/2020/08/23/how-to-use-ramdisk-as-filesystem- >on-nuttx/ That is the guide I followed Alan: nsh>mkrd 64 nsh>ls /dev /dev: console null ram0 ttyFC0 ttyFC1 ttyS0 ttyS1 zero nsh>mkfatfs /dev/ram0 mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 29 < 254 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 1 sectors/cluster nsh> Other variants of nsectors, that I've tried, give variations of the same error. This is why I still thingh there is a buried CONFIG setting I haven't enabled or have set wrong inadvertently. Most rocket ships have well written training manuals...this whole adventure is "let's have a guess what might work".
RE: USB MSD problem
> >Try to spot the exact place where it is happening, also enabling the DEBUG FS >could help to spot issues. Well, here's an odd thing. I already had FS debug on of course, but not the informational output. Turn that on, and I can now actually create a FAT volume on /dev/ram0. Cannot explain that (console output below). Tried running msconn with /dev/ram0 but it still crashes. It *seems* to be printf statements in the msconn system app itself!!?? nsh>mkrd 64 mkrd: RAMDISK at 0x20074cd0 ramdisk_register: buffer: 0x20074cd0 nsectors: 64 sectsize: 512 nsh>mkfatfs /dev/ram0 bchdev_register: blkdev="/dev/ram0" chardev="/dev/tmpc01" readonly=F find_blockdriver: pathname="/dev/ram0" rd_open: rd_crefs: 1 rd_geometry: Entry rd_geometry: available: true mediachanged: false writeenabled: true rd_geometry: nsectors: 64 sectorsize: 512 rd_geometry: Entry rd_geometry: available: true mediachanged: false writeenabled: true rd_geometry: nsectors: 64 sectorsize: 512 mkfatfs_clustersearch: Configuring with 1 sectors/cluster... mkfatfs_tryfat12: nfatsects=1 nclusters=29 (max=341) mkfatfs_tryfat16: nfatsects=1 nclusters=29 (min=4081 max=256) mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 29 < 254 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 1 sectors/cluster mkfatfs_selectfat: Selected FAT12 mkfatfs_configfatfs: Sector size: 512 bytes mkfatfs_configfatfs: Number of sectors:64 sectors mkfatfs_configfatfs: FAT size: 12 bits mkfatfs_configfatfs: Number FATs: 2 mkfatfs_configfatfs: Sectors per cluster: 1 sectors mkfatfs_configfatfs: FS size: 1 sectors mkfatfs_configfatfs: 29 clusters mkfatfs_configfatfs: Root directory slots: 512 mkfatfs_configfatfs: Volume ID: mkfatfs_configfatfs: Volume Label: " " /* lots of rd_write messages to the sectors. Deleted from this copy/paste */ rd_close: rd_crefs: 0 nsh>mount mount -t vfat /dev/ram0 /mnt find_blockdriver: pathname="/dev/ram0" rd_open: rd_crefs: 1 rd_geometry: Entry rd_geometry: available: true mediachanged: false writeenabled: true rd_geometry: nsectors: 64 sectorsize: 512 rd_read: sector: 0 nsectors: 1 sectorsize: 512 rd_read: Transfer 512 bytes from 0x20074cd0 fat_mount: FAT12: fat_mount: HW sector size: 512 fat_mount: sectors: 64 fat_mount: FAT reserved:1 fat_mount: sectors: 64 fat_mount: start sector:1 fat_mount: root sector: 3 fat_mount: root entries:512 fat_mount: data sector: 35 fat_mount: FSINFO sector: 0 fat_mount: Num FATs:2 fat_mount: FAT sectors: 1 fat_mount: sectors/cluster: 1 fat_mount: max clusters:29 fat_mount: FSI free count -1 fat_mount: next free0 nsh>
RE: USB MSD problem
>Tried running msconn with /dev/ram0 but it still crashes. > >It *seems* to be printf statements in the msconn system app itself!!?? > Comment all the printf statements out of msconn and it runs...but it now crashes during nxtask_exithook(). This SCREAMS of a basic nuttx RTOS/THREAD/SOMETHING config setting missing or invalid? >From: Alan Carvalho de Assis >Sent: 22 December 2021 13:54 >> Most rocket ships have well written training manuals...this whole >> adventure is "let's have a guess what might work". >> > >Yes, our is here: https://nuttx.apache.org/docs/latest/ and if you want to help >the project you can create about how to use Flash with USB MSD after you get >things fixed, deal? ;-) I refer to that all the time and it hasn't helped. The thing with documentation is it is often written by people who already know the system for people who already know the system. I am keeping notes of all the bugs, errors, and inconsistencies I find and hope to submit PRs one fine day - this is a commercial project and getting it working is priority #1. I have every desire to help the project in the fullness of time.
RE: USB MSD problem
Usb_msc_main.c If I add a "return OK" as the first line of main, msconn runs and returns. If I put a printf statement before it, I get a crash. If I do the same in an example app I've written, it is fine. If I put a breakpoint at the printf statement and step over it, into there it gets to "void exit(int status)", then nxtask_exithook(tcb, status, false), then group_leave(tcb). This is crazy...I just don't get this - surely a built in system app should not be crashing like this!!!
RE: USB MSD problem
Update on my issues. msconn crashing was, as suggested, inadequate stack size. Default was 768, and changing to 2048 and it no longer crashes. This was my first experience of stack issues with NuttX. I have now merged the 10.2 release and building and running OK. Msconn now allows my board to be seen as a USB device and Windows recognises the connection. Since I had formatted the flash with nxffs, Windows wouldn't mount it of course so I have moved on to use FAT instead. >On 12/22/21, Alan Carvalho de Assis wrote: Here the issue is because FAT sector is always 512 bytes, but your Flash is 256, >you can modify the menuconfig to let the MTD export/convert it as 512. > I found that just making the menuconfig change was not enough. There is a (seemingly) undocumented s512_initialize function I stumbled across: FAR struct spi_dev_s *spi; FAR struct mtd_dev_s *mtd_raw; FAR struct mtd_dev_s *mtd; mtd_raw = m25p_initialise(spi); mtd = s512_initialize(mtd_raw); Giving (from my bringup code): m25p_initialize: dev: 0x200773b0 m25p_readid: priv: 0x200773d0 m25p_readid: manufacturer: 20 memory: ba capacity: 19 m25p_initialize: Return 0x200773d0 Successfully bound SPI0 CS1 to the SPI FLASH driver s512_initialize: mtd: 0x200773d0 m25p_ioctl: cmd: 1537 m25p_ioctl: blocksize: 256 erasesize: 65536 neraseblocks: 512 m25p_ioctl: return 0 s512_initialize: Return 0x20077400 Successfully implemented 512 byte sector conversion ftl_initialize_by_path: path="/dev/mtdblock0" s512_ioctl: cmd: 1537 s512_ioctl: blocksize: 512 erasesize: 512 neraseblocks: 65536 s512_ioctl: return 0 Successfully initialised ftl layer This allows me to at least attempt to mkfatfs on my 32Mbyte flash device, but I am still hitting problems, so I worry I am not implementing 512 sector support properly? Or something else I yet again have missed? If I enable sub-sector erase (the memory supports 4k subsector erase) then mkfatfs crashes out: [lots of successful operations] m25p_pagewrite: page: 000f offset: 0f00 m25p_waitwritecomplete: Complete m25p_writeenable: Enabled m25p_pagewrite: Written arm_dataabort: Data abort. PC: 200316bc DFAR: 608b DFSR: 0005 up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 161 task: init If I disable sub-sector erase it behaves differently: [lots of successful operations] m25p_pagewrite: page: 00ff offset: ff00 m25p_waitwritecomplete: Complete m25p_writeenable: Enabled m25p_pagewrite: Written mkfatfs_devwrite: ERROR: write failed: size=512 pos=512 error=-13 arm_dataabort: Data abort. PC: 20032044 DFAR: 01b4f430 DFSR: 0005 up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 161 task: init The error looks to be no write permissions? Any thoughts, anyone?
RE: USB MSD problem
>Any thoughts, anyone? Stack again. Not enough for the main thread. Guess I need to go back to school to learn about stacks :(
FAT/MTD/USBMSD...still.
Yep, me again! USB device is working. I can create a ram disk, format it as FAT, set it as a LUN device and Windows and Linux see it as an MSD device. I can read and write to it, reliably. I have an MT25QL256A device (32Mbyte) which is correctly connected to the SAMA5D17 via SPI0, has a block driver, and I can format it as FAT nsh> df BlockNumber Size Blocks Used Available Mounted on 16384 2046 22044 /mnt/fs 1024 1004 21002 /mnt/ramfs 0 0 0 0 /proc When I run msconn it is pretty much always seen by Linux, but it's very unpredictable with Win10 (get the connection sound, device manager sees it as a drive, but doesn't reliably do the Windows equivalent of mounting it. Mostly. If I copy a 1Mbyte file to it (Ubuntu 20.04) it seems to write the file - it appears in "Files" in Ubuntu. But if I try and eject the MSD, it tells me one or more applications are keeping the device busy. Windows behaviour is much quirkier but similar. The file seems not to write, or Windows wants to fix errors, or just sits there. Eventually, if detected properly, the file appears not to write, but an msdis followed by msconn shows it is therebut it is corrupted if I compare to the original file written. The size is right but it is not the same contents. Go back to Linux, and it no longer wants to see the MSD, unless I reformat it via nsh. My belief is that the USB MSD, or FAT, or this flash device, is somehow not working right for me. Everything else has absolutely been me not setting up something right, or a stack issue, or not understanding dumb things, but I have eventually got there (with help from you guys...thanks!). Right now, though, this has me completely stumped again :( Anyone seen anything like this before and got any suggestions of things for me to look at or try tomorrow?
RE: FAT/MTD/USBMSD...still.
As I ponder this: 1) Is it possible Windows 10 (and possibly Linux these days) doesn't like FAT12? I can't find a definitive answer, but believe it should be OK 2) Is it reasonable for me to expect mkfatfs to be able to create FAT16 on a 32Mbyte flash device with 512byte sectors (and 64k erase sector/4k sub-sector erase)? mkfatfs will only ever format this flash device as FAT12 whatever I try, so I wanted to try FAT16 to eliminate 1) as a possibility nsh> mkfatfs -F 16 /dev/mtdblock0 mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 2046 < 2302 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 32 sectors/cluster mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 1023 < 1278 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 64 sectors/cluster mkfatfs_tryfat16: WARNING: Too few or too many clusters for FAT16: 4081 < 511 < 766 mkfatfs_clustersearch: WARNING: Cannot format FAT16 at 128 sectors/cluster mkfatfs_configfatfs: WARNING: Failed to set cluster size I believe that a 32Byte device should format as FAT16 with 4085 clusters, and 16*512 byte sectors, but mkfatfs is only attempting calculations for 32/64/128 sectors/cluster. If I make a change in "mkfatfs_clustersearchlimits" to allow 16 sectors/cluster to be tried for a device with 64k sectors, it will create FAT16... ...but the file (a 1Mbyte .wav file) is still corrupted and it is very slow to write a file (via USB) to the msd (gets to 99% quickly then takes minutes for the last 1%). A 24k jpg file gets corrupted similarly too. Windows still says there's a problem with the drive and wants to fix it, but Explorer will show the files that have been copied to this msd. The corruption is always after the first 16k boundary on the msd. I don't think this is FAT12 vs FAT16. Uboot tests show this memory is OK. I have ordered a 1Gbit device to try (in case the device on this board is damaged, or NuttX just doesn't like 256Mbit M25P devices for some reason!!). But still hopeful of some suggestions! >-Original Message- >From: Tim >Sent: 12 January 2022 17:42 >To: dev@nuttx.apache.org >Subject: FAT/MTD/USBMSD...still. > >Yep, me again! > >USB device is working. I can create a ram disk, format it as FAT, set it as a LUN >device and Windows and Linux see it as an MSD device. I can read and write to it, >reliably. > >I have an MT25QL256A device (32Mbyte) which is correctly connected to the >SAMA5D17 via SPI0, has a block driver, and I can format it as FAT > >nsh> df > BlockNumber >Size Blocks Used Available Mounted on >16384 2046 22044 /mnt/fs > 1024 1004 21002 /mnt/ramfs > 0 0 0 0 /proc > >When I run msconn it is pretty much always seen by Linux, but it's very >unpredictable with Win10 (get the connection sound, device manager sees it as a >drive, but doesn't reliably do the Windows equivalent of mounting it. >Mostly. > >If I copy a 1Mbyte file to it (Ubuntu 20.04) it seems to write the file - it appears in >"Files" in Ubuntu. But if I try and eject the MSD, it tells me one or more >applications are keeping the device busy. > >Windows behaviour is much quirkier but similar. The file seems not to write, or >Windows wants to fix errors, or just sits there. Eventually, if detected properly, >the file appears not to write, but an msdis followed by msconn shows it is >therebut it is corrupted if I compare to the original file written. The size is right >but it is not the same contents. > >Go back to Linux, and it no longer wants to see the MSD, unless I reformat it via >nsh. > >My belief is that the USB MSD, or FAT, or this flash device, is somehow not >working right for me. Everything else has absolutely been me not setting up >something right, or a stack issue, or not understanding dumb things, but I have >eventually got there (with help from you guys...thanks!). Right now, though, this >has me completely stumped again :( > >Anyone seen anything like this before and got any suggestions of things for me to >look at or try tomorrow? >
MT25P vs MT25Q bulk erase difference - how to fix?
As I still get deeper and deeper into why FAT doesn't work on my MT25Q NOR flash device, I have found a minor error in m25px.c The M25P devices have a bulk erase command (0xC7) but this is not supported by the MT25Q, which has a "die erase" command (0xC4) instead and 0xC7 is meaningless. There is a #define for this as expected: #define M25P_BE 0xc7 Adding #define M25Q_DE 0xc4 Make sense but... When the device manufacturer ID is read this is actually saved, so it can't be tested at runtime to choose the right command. The straightforward fix is to move the #define for M25_BE to within the code that tests the manufacturer ID (to ensure it's a valid device for these functions) but that is a bit messy and moves the #define away from all the other related #defines. Doesn't feel right. There is no unique CONFIG_ attribute that says whether it is or isn't expecting to find an M25P or M25Q (which is reasonable) so I can't use conditional #defines. And don't want to mess up other people's boards by changing Kconfig in any way that isn't backwards compatible, although the inviolable "Sometimes Code Duplication is OK" might suggest it would be better to copy out m25px.c as m25lx.c and make the change so that Kconfig demands you choose one or the other or both of the two types...and if I find more errors/differences that may ultimately make sense of course. Can anyone suggest the "NuttX way" to do this, assuming I don't find a myriad of other errors/differences that "force" duplication?
RE: Alternatives to FAT for msd
>-Original Message- >From: Arie de Muijnck >Sent: 19 January 2022 22:34 >> FAT seems broken for NOR flash devices. Spent days getting nowhere. >> >> Since FAT and flash devices don't really play well together anyway >> (already found s512 erases a flash sector at least 4 times when >> writing a cluster), so I'm wondering, in parallel, if NuttX has other >> tricks up its sleeve that might achieve the same end? I want t: >> >> - write to the flash, for logging, from the app running on the board. >> This can be done with any FS - or raw - as far as I'm concerned. Not >> the issue. >> >> - an external PC (ideally Linux, Windows and MAC) needs to be able >> "see" the data via USB (msd) and read/write to the memory (log data, >> config files, audio files, etc). Hence FAT. >> >> With a flash size of between 32 and 128Mbyte, I don't think a ramdisk >> formatted as FAT holding a copy of the flash data is really the way to >> go (board only has 64Mbyte RAM anyway). >> >> I'm guessing I'll have to keep up the battle - that NuttX is winning - >> of FAT vs. NOR flash until the bitter end, but if anyone does have >> other ideas I'm listening! >> > >Why the fixation for MSD mode and FAT? >Using a serial stream protocol also could access the files in a transparent >matter. >I remember the days of KERMIT, ZMODEM, CP, etc., over a serial link. >Making the device appear as an NDIS network adapter also allows e.g. FTP to >transfer files. > >Arie Reasonable question, and my thinking may be flawed - a little knowledge is a dangerous thing! In the past I have developed products with USB that then needed a dedicated PC app to be developed to transfer data and/or configure it. I wish to ensure that this device can be configured by any computing device (Windows, Linux, MAC) and USB+MSD seemed the lowest common denominator without the need to develop a cross-platform app. Ultimately I will need an Android/iOS app and Bluetooth LE connectivity but that's in the future. "Configuration" would be via files in industry standard format (e.g. CAN dbc files, or .wav files with "known" names - such as "startup.wav") or that can be readily created in a text editor or downloaded from our website (e.g. xml files or even a .ini type file). USB+MSD would allow these to be simply copied across to the embedded device. And FAT is what I understand to be the most portable FS. Likewise log files (up to 64Mbyte) would be in an industry-standard format allowing 3rd party viewers to be used (again, no need for a custom app) and USB+MSD+FAT seemed the best way to transfer these. RNDIS/USB or whatever is actually a very interesting idea though so I will look at that. I'm open to all suggestion and I'm listening :)
RE: Question about backtrace_malloc
>emails are not always coming through to the mailing list... So re-sending. > This happens a lot for me too. I always check https://www.mail-archive.com/dev@nuttx.apache.org/ to see if I've missed anything.
RNDIS
Following suggestions relating to FAT/MSD/USB I have been playing with RNDIS following the NuttX Channel video by Alan C. de Assis (thank you Alan - only just found all of your videos!!). It all builds OK and ifconfig suggests all is good: nsh> ifconfig lo Link encap:Local Loopback at UP inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0 eth0Link encap:Ethernet HWaddr e0:de:00:ad:be:ef at UP inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0 But Linux (Ubuntu 20.04) doesn't "see" it and I can't ping it. Connecting to Windows just results in loads of error messages in nsh to do with unrecognised rndis messages. Leave that for another day. If I try and do a local ping it suggests there's an error with sockets, or ping? nsh> ping 127.0.0.1 psock_socket: ERROR: socket address family unsupported: 2 socket: ERROR: psock_socket() failed: -106 ERROR: socket() failed: 106 nsh> 106 is endpoint already connected; it's the same whether the USB is connected to the Linux machine or not. As usual, any suggestions welcomed!!
RE: RNDIS
>From: Tim Hardisty >Sent: 21 January 2022 11:15 >[ 3399.339551] rndis_host 1-2:1.0: dev can't take 1558 byte packets (max >1364), adjusting MTU to 1306 Easily fixed: CONFIG_NET_ETH_PKT_SIZE=1518 But RNDIS still doesn't work, having checked every option I can find. Windows doesn't like it, with nsh reporting loads of unknown message types (e.g. 1162626371, 1030976101), and Bad packet size dropper (0). But it does show as a network adapter on the PC. Linux dmesg still shows the same: rndis_host 1-2:1.0: RNDIS_MSG_QUERY(0x01010101) failed, -32 CDC-ECM Ethernet-over-USB worked straight away, which is fine for Linux but not for Windows.
RE: RNDIS
Windows now working properly but not Linux. My board can be powered via the USB and I think it all got confused as I had been leaving the USB cable connected, coupled with not flashing code but using JTAG download for debugging, coupled with not repowering the board very often. I can now telnet from Windows. Linux remains an issue, but I'm looking at whether there are any RNDIS driver updates for Ubuntu or something like that. But, for once, I at least have *something* working :) >-Original Message- >From: Tim >Sent: 21 January 2022 14:14 >To: dev@nuttx.apache.org >Subject: RE: RNDIS > >>From: Tim Hardisty >>Sent: 21 January 2022 11:15 > >>[ 3399.339551] rndis_host 1-2:1.0: dev can't take 1558 byte packets >>(max 1364), adjusting MTU to 1306 > >Easily fixed: > >CONFIG_NET_ETH_PKT_SIZE=1518 > >But RNDIS still doesn't work, having checked every option I can find. > >Windows doesn't like it, with nsh reporting loads of unknown message types >(e.g. >1162626371, 1030976101), and Bad packet size dropper (0). But it does show as a >network adapter on the PC. > >Linux dmesg still shows the same: rndis_host 1-2:1.0: >RNDIS_MSG_QUERY(0x01010101) failed, -32 > >CDC-ECM Ethernet-over-USB worked straight away, which is fine for Linux but >not for Windows. > >
RE: Abstract "channels" driver model
Just a "thumbs up" from me if you do this (or find something that exists
that'll do it) - it's a perfect fit for my current project :)
>-Original Message-
>From: Matthew Trescott
>Sent: 17 March 2022 05:55
>To: dev@nuttx.apache.org
>Subject: Abstract "channels" driver model
>
>Hi everyone,
>
>I was thinking about how to implement the software for my project (control
>module for a Formula SAE car) and realized that the basic ADC driver model is
>a bit inconvenient and creates a lot of extra overhead in userspace threads
>when implementing advanced features. Some features I think would make
>sense in an abstract “channels” driver model that would benefit many controls
>applications:
>
>- Only wake up a thread when a value has changed "significantly."
>
>- Support channels generated from bilinear/bicubic interpolation using a table.
>
>- Share the same ADC values among multiple threads with different priorities,
>like a high-priority safing algorithm, a medium priority control algorithm,
>and a
>low-priority CAN broadcast thread.
>
>- Share the same ADC values among threads with different needs—the three
>listed above only care about the latest value, while a datalogging thread that
>saves to flash memory would want to save data in chunks.
>
>- Implement software filters and allow binding to userspace control algorithms
>for Kalman filtering.
>
>- Allow different threads to subscribe to epoll events at different rates.
>
>- Allow data received via an offboard, runtime-configurable serial bus like CAN
>or UART to be assigned a meaningful name and seamlessly used for userspace
>control functions just like ADC measurements, with a userspace helper thread
>de-serializing the messages as they arrive.
>
>- Allow the application to wait for two or more channels to be consistent.
>
>- Avoid unnecessary copies and support ADC DMA transfers.
>
>
>The model I have in mind is something like this:
>
>- Channels are char-devices; e.g. /dev/channels/throttle-position-1
>
>- A userspace application that only cares about the latest measurement would
>do something like this to get a pointer that always points to the latest
>channel
>value and avoid the overhead of read():
>
>uint32_t *throttle_position_1;
>int tps1_fd;
>tps1_fd = open("/dev/channels/throttle-position-1");
>ioctl(tps1_fd, CHANIOC_SUBSCRIBE, (unsigned long)&throttle_position_1);
>ioctl(tps1_fd, CHANIOC_SET_FILTER, ...);
>poll(...);
>// Do some calculations with *throttle_position_1
>// Drive some output
>
>- A periodic userspace task that works with bulk data would read() from the
>ring buffer, or get a pointer to the ring buffer with an ioctl (not sure which
>would be better)
>
>- New data is copied to the ring buffer in the low- or high-priority work
>queue.
>
>- Boardctl or board-init logic is responsible for setting up special ADC
>triggering
>(e.g. from a PWM module) and telling the ADC backend driver to register itself
>as a channel. DMA can be set up so that ADC measurements are directly
>copied to the "latest value" location if no filtering or conversion is needed.
>
>- Software-generated channels are created with a syscall; the userspace
>thread can write to the resulting char device and the data will be stored in
>the
>ring buffer and wake up any threads waiting on the software-defined
>channel.
>
>
>
>Looking for prior art, I noticed that there are the Common Sensor Register
>Interace and Sensor Cluster Driver Interface (drivers/sensors/README.txt).
>However, these don't cover ADCs or address the overhead of having a
>multiple-input control thread needing to use both epoll() and read(). Nor do
>they support filtering or multiple userspace threads accessing the same
>sensor in a convenient way.
>
>However, something like this might already exist, just not in mainline NuttX.
>If
>you know of such a thing or have feedback on this idea, please let me know.
>Otherwise, I'll move ahead with working on it.
>
>Best regards,
>Matt
tty philosophy
I am sorting out flexcom support for the SAMA5D2 as there are issues with the arch files as well as Kconfig. In doing so, I would like to do it “right”. If flexcoms are assigned as USARTs is the correct philosophy to register them sequentially or as per flexcom port number? For example, if (only) flexcoms 2 and 3 are configured as USARTs should they be ttyFC0 and ttyFC1, or ttyFC2 and ttyFC3?
Re: CAN example crashes
Thanks Alan - those are already set but don't seem to produce any output on the console so may be the error output itself isn't configured right. I'll take a look. On 07/05/2021, 18:49, "Alan Carvalho de Assis" wrote: >Hi Tim, >Try to enable the debug in the menuconfig: > Build Setup ---> > Debug Options ---> >[*] Enable Debug Features >[*] Enable Error Output >[*] Enable Warnings Output >[*] Enable Informational Debug Output > >[*] CAN Debug Features >[*] CAN Error Output >[*] CAN Warnings Output >[*] CAN Informational Output >>On 5/7/21, Tim wrote: >> Hi, >> >> >> >> SAMA5D27 (custom board) - trying to complete the port and also check that >> the CAN interface works on the board, so I'm trying to use the CAN example >> app. >> >> >> >> The drivers appear to be registered (I see /dev/can0 and /dev/can1) but >> the >> CAN example app crashes when trying to open /dev/can0 and I can't see why. >> > >> >> I am hindered in debugging this fully as yet since: >> >> >> >> a. I am new to Nuttx and haven't yet sussed how to enable any low level >> debug-type stuff (I have used menuconfig to enable anything that seems to >> be >> related but I'm sure I missed stuff) >> b. I haven't yet coerced my Eclipse IDE (under Windows 10, but code >> configured and compiled using Windows WSL) to "see" the source code >> properly >> to enable me to insert breakpoints (Segger J-link). Not wedded to Eclipse, >> but it is a known entity for me and at least downloads/runs/debugs the >> board!) >> >> >> >> Can anyone point me in the direction of why, or a way to find out why, the >> call to open the device would crash the board rather than return an error? >> Other devices (such as Flexcom USARTs open OK and work - well, after I >> fixed >> some arch issues for Flexcoms on the SAMA5 anyway!!). The board-specific >> code (sam_can.c) I am using is based on the code for the sama5d2-xult >> board >> and seems pretty trivial, and largely similar to many other architectures >> and boards.
Re: CAN example crashes
>> Is there any description somewhere about this example ? >> >There is some in apps/examples/README.md, but not a lot of info. Not much, no, but the example code is pretty self-explanatory!
Re: Dev environment
Thanks Alan. Compiling is no problem it is debugging that is my issue. I see
from your process that you copied the elf from the WSL environment to the
Windows /mnt/c ...I haven't tried that but I am not sure it will help eclipse
find the source code...unless I also replicate the source tree on the Windows
side perhaps. It is a few more things to try at least, so thank you.
>Hi Tim,
>
>I don't use Windows or MacOS, but some time ago just tested NuttX on
>WSL to help other to get started to NuttX on Windows, I documented the
>process here:
>
>https://acassis.wordpress.com/2018/01/10/how-to-build-nuttx-on-windows-10/
>
>I hope it helps you!
>> I need to debug it. I will need to get to that point regardless.
>>
Re: Dev environment
Thanks Flavio - I hadn't thought about using a VM; that would avoid yet another lump of PC hardware cluttering up the place if I can't get the WSL or MAC approach to work. I am really hating Window at the moment (1 machine can connect to my Mac, the other can't...many hours wasted NOT fixing it!) and I had thought it time to jump ship to Mac...but Linux seems even more appealing right now!! On 11/05/2021, 18:24, "Flavio Castro Alves Filho" wrote: Hello Tim, What I do here to implement a NuttX application is to use an Ubuntu Server VM (in my case, VMWare). In this VM, I map my Jlink (which is a nucleo board with changed firmware). I use Segger tools to load the firmware. To code, I use VSCode in Windows with SSH access to the VM (I set a host-only network). For the toolchain, I use x-pack arm-gcc. The toolchain provided by ubuntu does not provide gdb. You can use the VSCode extension with GDB and JLink to run. Hope it helps. Best regards, Flavio
Re: Dev environment
I have the board booting from AT91bootstrap and Uboot, from QSPI no problem. Downloading code using JLink from Windows/eclipse is fine, but the debugging is broken/mis-configured. I will probably have another go at a Windows-hosted development environment and have the arm cross compilers installed already: since it works for the Atmel "softpack" stuff from which I derived my initial board debugging code (before moving to NuttX) I see no reason why it shouldn't work for NuttX using tool chains, within Eclipse, once I finally get my head around it and find the magic trick! Seems I have a few things more to try now, at least. On 11/05/2021, 18:36, "Gregory Nutt" wrote: >> It seems that it is possible to run JLink from Windows in WSL. >I used J-Link under Windows to bring up the SAMA5Dx. The only tricky >thing was booting from an SD card with U-boot.
Re: Dev environment
Hmm...do need Windows for my schematic capture and 3D design applications, but Mac little used as yet...I'm thinking dual boot Mac/Ubuntu is probably the way to go! On 11/05/2021, 20:30, "Alan Carvalho de Assis" wrote: Also, if you are not dependent on Windows, just install Linux on your computer, it will avoid all those tricks to get the work done ;-)
Re: Dev environment
I see from https://www.mail-archive.com/dev@nuttx.apache.org/ that others have replied. These have not got through to me so apologies for not yet taking up the offers of assistance. I will try and sort whatever the email issue is and then reply!
RE: Dev environment
>From: Alan Carvalho de Assis > >Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig? > > │ -> Build Setup > │ > │ -> Debug Options > │ > │ -> Enable Debug Features (DEBUG_FEATURES [=y]) > │ > │ -> CAN Debug Features (DEBUG_CAN [=y]) > Indeed I did. And, anyway, even if I hadn't my debug message might appear but the system would keep running, but it doesn't: it crashes. I have inserted the while(1) to narrow it down to where it crashesit is the call to that debug message that does it :(
RE: Dev environment
>On 5/12/21, Tim Hardisty wrote: >>>From: Alan Carvalho de Assis >>> >>>Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig? >>> >>> │ -> Build Setup >>> │ >>> │ -> Debug Options >>> │ >>> │ -> Enable Debug Features (DEBUG_FEATURES [=y]) >>> │ >>> │ -> CAN Debug Features (DEBUG_CAN [=y]) >>> >> >> Indeed I did. And, anyway, even if I hadn't my debug message might >> appear but the system would keep running, but it doesn't: it crashes. >> I have inserted the while(1) to narrow it down to where it >> crashesit is the call to that debug message that does it :( >> > >Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the >caninfo() and the while(1); just for a double check ;-) > >By PIO_LED_YOURLED I mean the LED that is turning ON when your board >initializes. > >Talking about LEDs... other important thing: normally when NuttX crashes the >board LED start to blink to indicate an issue, is it blinking on your board? This is a custom board, and no LED such as that. I have removed any LED-related stuff from the board.h file...is that the issue? Maybe NuttX absolutely depends on some kind of LED?
RE: Assert and Debug issues
>>From: disruptivesolution...@gmail.com
>1) If I enable Debug Assertions the build will not run at all as it halts very
>very
>early on. Debugger suggests the system is in up_idle().
>> Mostly this is caused by a "fault" somewhere down the line.
>> Does it "print" ABCDE?
Nope, nothing. It simply appears to do nothing. Any messages are not
"escaping".
>>Did you enable "debug" in make menuconfig?
As in "Enable Debug Feature"? Yes. If there's something else I missed I can't
find it!
>2) Any (valid and enabled) call for a debug info/warn/error message produces
>no actual message on the console. Not just in the CAN example but others
>too. Console (and nsh) working fine. For example, the PWM example works
>just fine. If I enable debug messages for this it doesn't crash, still works as
>expected, but no debug message text. FYI I added this to the example to
>prove the point:
>
> #if defined CONFIG_DEBUG_PWM_INFO
> printf("PWM_WARN_PRINTF_DEBUG\n");
> pwmerr("PWMINFO: starting pwm example PWM\n");
> #else
>printf("JUST A PWM WARN PRINTF\n");
> #endif
>
>I get the "PWM_WARN_PRINTF_DEBUG" text on the console, but not the
>"PWMINFO:starting pwm example PWM" text.
>> pwmerr is only when the "error" on PWM occurs. Did you try _info? Or
>> caninfo?
Pwmerr will be called as per coding. I called it in the case of no error and it
should work. But even pwminfo and pwmwarn (or caninfo or canwarn) do not
produce text EVER. Nor do any other debug calls in any other place. Ever.
>But I am trying to continue to basically prove my board is actually OK from a
>hardware point of view.
>> Why should it not be? Does nsh work and USART? (basic functionality?). And
>> SPI?
Because it's a new board and a new port, and the first time NuttX has been run
on it. Nsh works, USART works, SPI - not tested yet. I can run built-in apps
from the nsh console...and it is running the CAN example this way that I see
the crash; and running the PWM example this way that I see no debug messages.
These things all work with my bare metal code derived from the Atmel "softpack"
except CAN because I think the softpack CAN code is buggy so I am not 100% sure
the CAN hardware works right yet. I would rather spend my time getting it
working under NuttX than bare metal as the bare metal route is not being
pursued now.
>
>Can anyone offer any insight into why Assert and debug info/warn/error
>messages are "misbehaving" like this? --> I tried to give you some heads up.
>>https://nuttx.apache.org/docs/latest/quickstart/debugging.html
Yes, I have followed that. I have read everything I can find, Googled for
hours, and no luck yet :(
I should have my full Linux dev environment up and running by Monday and I hope
I can then debug it properly. But in the mean time I still hope to get basic
assert and debug messages working!
Re: Dev environment
With thanks to Flavio's suggestion (and .json file to point me in the right direction) I now have VS Code running under Ubuntu as a full IDE - edit/build/debug with Segger jlink all from within VS Code Had to create custom scripts in the launch.json file to ensure no reset on download of nuttx to my sama5d27 otherwise it messed with the bootstrap+Uboot config of the processor. Also a bit of faffing to get the arm-none-eabi tools from ARM to work (lots of symbolic links needed). Is this worth documenting and sharing anything anywhere? I know the processor is perhaps a bit obscure, but it might help someone - if so, please let me know where/how to best share my information, otherwise I will simply document as part of my own project. Tomorrow will see the start of actually debugging the cause of the CANbus driver crashes, but I can now actually do this with proper tools at my disposal. And once fixed and proven I will then work out how to do pull requests to get the fixes made available...I'm nearly coding in the 21st century now lol. On 21/05/2021 20:51, Flavio Castro Alves Filho wrote: Hello Tim, I use VSCode with GDB and Segger. But Ubuntu does not come with GDB. So I use x-pack toolchain to build and debug. It works well. Best regards, Flavio Em sex., 21 de mai. de 2021 às 13:28, Tim escreveu: Eventually got a Linux dev environment up and running (first PC purchased failed after a few hours...grrr...now have an Intel i5 NUC for this). Amazed how darn fast compilation is compared to WSL (even on my 3.3GHz Zeon-based workstation with the -j6 make option) so that in itself means it was a great move! Always liked Linux anyway lol. Eclipse (latest version) still not playing ball - just won't debug. So I'm assuming a platform independent setup issue with it; aka finger trouble :( I am temporarily using Segger Ozone - worked first time and can finally debug. Not sure I like it but hey ho. As an aside, has anyone got a recommendation of a good, graphical, GDB debugger for Linux, that place nicely with NuttX? Not bothered about an IDE as such, and I'm 100% happy with building via terminal, but a feature rich and easy to use debugger that looks up the source code "thoroughly" is an essential. But, now I can set breakpoints, I found that lack of debug messages on the console was because the .config was sending them to RAM not CONSOLE, because that's what is in the sama5d2-xult defconfig file I based my custom config on. Simple explanation, but is this documented anywhere? Can't find that level of syslog stuff using make menuconfig? Also now, at least, I know that the board is crashing in can_hwinitialize when it calls can_putreg(priv, SAM_PMC_PCR, regval)...so next week's task is to find out what's up with this (it's not my code). On 5/12/21, Tim Hardisty wrote: From: Alan Carvalho de Assis Did you enable CONFIG_DEBUG_CAN_INFO in your menuconfig? │ -> Build Setup │ │ -> Debug Options │ │ -> Enable Debug Features (DEBUG_FEATURES [=y]) │ │ -> CAN Debug Features (DEBUG_CAN [=y]) Indeed I did. And, anyway, even if I hadn't my debug message might appear but the system would keep running, but it doesn't: it crashes. I have inserted the while(1) to narrow it down to where it crashesit is the call to that debug message that does it :( Try to put a sam_piowrite(PIO_LED_YOURLED, true/false); to between the caninfo() and the while(1); just for a double check ;-) By PIO_LED_YOURLED I mean the LED that is turning ON when your board initializes. Talking about LEDs... other important thing: normally when NuttX crashes the board LED start to blink to indicate an issue, is it blinking on your board? This is a custom board, and no LED such as that. I have removed any LED- related stuff from the board.h file...is that the issue? Maybe NuttX absolutely depends on some kind of LED?
Re: CAN example crashes
On 07/05/2021 17:48, Tim wrote: Hi, SAMA5D27 (custom board) - trying to complete the port and also check that the CAN interface works on the board, so I'm trying to use the CAN example app As per my other thread, Linux+VS Code+Segger all up and running so I can see what's going on now. Found an error in sam_can.c for sama5 which was why it was crashing - have fixed and will do the necessary PR in due course. However, the main problem is that the sama5 board files all use "can" but it should be "mcan"...so all the register addresses and possibly functions/methods are wrong :( Before I attempt to rework it to use mcan, has anyone actually got Nuttx+CAN working on a sama5? It could save me loads if work if so!!??
Re: Memory locations
On 07/06/2021 20:45, Gregory Nutt wrote: I will, I believe, need to declare - place - MCAN related structures such that they (or at least some elements of them) are in SRAM. You will need to exercise care. SRAM (called isram in the linker scripts) is already used for other things including the MMU page table: https://github.com/patacongo/incubator-nuttx/blob/master/boards/arm/sama5/sama5d2-xult/scripts/dramboot.ld#L21 The first 112Kb should be available, however, unless the board logic uses that too. Thanks Greg - needs no more than 4kbyte. Just got to understand linker scripts now lol and will check for any board logic usage there (there's none that I've set up for my board, at least)
Re: Memory locations
On 07/06/2021 19:06, Nathan Hartman wrote:
On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.
I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)
.isramdata :
{
} > isram
and declared
static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!
Re: Memory locations
Thanks, but still no cigar :(
I have tried:
.isramdata_reserve (NOLOAD) :
{
*(.isramdata)
. = ALIGN(4);
_isramdata_heap_start = ABSOLUTE(.);
} > isram
and also just
.isramdata(NOLOAD) :
{
*(.isramdata)
} > isram
along with trying
staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
aligned_data(MCAN_ALIGN) locate_data(".isramdata");
where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
((section (".isramdata")));
and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:
Here is a working example.
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Hartman wrote:
On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.
I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)
.isramdata :
{
} > isram
and declared
static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!
Re: Memory locations
Thanks, but still no cigar :(
I have tried:
.isramdata_reserve (NOLOAD) :
{
*(.isramdata)
. = ALIGN(4);
_isramdata_heap_start = ABSOLUTE(.);
} > isram
and also just
.isramdata(NOLOAD) :
{
*(.isramdata)
} > isram
along with trying
staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
aligned_data(MCAN_ALIGN) locate_data(".isramdata");
where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__
((section (".isramdata")));
and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:
Here is a working example.
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184
You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram
David
-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations
On 07/06/2021 19:06, Nathan Hartman wrote:
On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
I will, I believe, need to declare - place - MCAN related structures such
that they (or at least some elements of them) are in SRAM.
Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.
I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)
.isramdata :
{
} > isram
and declared
static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!
Re: Memory locations
On 08/06/2021 14:18, Sebastien Lorquet wrote: what I would check here (just a live thought process) * check that the ld file is actually used (ld file is pointed by main Make.defs IIRC) (easy: just add garbage in it and verify build actually breaks) You, sir, have earned the cigar! Garbage added, didn't complain...lulled into a false sense of security because VScode coloured it all so nicely as *it* had found the declarations in *a* linker script no problem at all, just not the right one. It's using uboot.ld not dramboot.ld and I was editing the latter. Doh! Complete idiot!!! Thank you all who helped me out for your patience!
Re: Lin
My custom board has a Lin/K-Line interface using a TJA1021 transceiver, but software support is low on the priority/roadmap at this time. Nevertheless, I would be happy to be involved in testing (I have a CAN/LIN analyzer/stream generator) if it helps. -Original Message- From: Pavel Pisa Hello Simon and others, On Friday 13 of August 2021 18:50:23 Frank-Christian Kruegel wrote: > Am 13.08.2021 um 16:50 schrieb Simon Filgis: > > has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART > > peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) > > would also be interesting! > > > > Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx > > in a separate file? > > Do you need LIN Master or LIN Slave? > > LIN Master is easy. It's standard serial. ... > LIN slave is much more complex, especially if you want to do autobauding > by measuring the SYNC byte after the break. You might end up with a > custom serial driver then. If a fixed bitrate is enough the only problem > is detecting the BREAK signal. A received break signal is basically a 0 > byte with a framing error added. You only need to detect and clear the > framing error. I am on the way to vacations now but I am interest in LIN interfacing discussion when I return. I do not have actual need for LIN support but getting some reasonable code upstream to NuttX and Linux. There is my latest version from 2019 https://github.com/ppisa/linux-lin and some docs https://github.com/ppisa/linux-lin/wiki Finite state machines and some other ideas from Linux kernel implementation can be reused on NuttX. As for the API, I think that to keep size of the applications low on the targets which do not use TCP or SocketCAN, NuttX API should be implemented through read, write (enough for the master) and IOCTLs to maintain slave responses cache. As for bitrate autodetection, there are special HW support in many UARTs for autodetect of the LIN bitrate. It would worth to add mechanism to setup it o NuttX. On GNU/Linux where sllin attempts to be compatible with all UARTs through generic API it is problematic. On NuttX we can define API, which can allow to implement LIN specific low level drivers for chips with special support ad for other map the API to generic UART low level part. Or we can conditionally extend low level API. By the way I return on Sunday August 22. It would be great if prof. Roberto Bucher's and followup Michal Lenc's presentation about PySimCoder on NuttX Workshop can be scheduled on Sunday that I can attend them. Best wishes Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://dce.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ company:https://www.pikron.com/
sama5D2 class D audio
Working through the remaining driver support I need for my custom board and I can’t find anything related to audio for the sama5d2 devices (they have Class D capability, with lots of modes). Before I dive in and find some time to create a driver from scratch, have I missed something? Documentation on audio support in general seems rather lacking so any pointers in the right direction would be appreciated (even just a suggestion of another processor with similar capability I can use as a reference). TIA, Tim.
Re: sama5D2 class D audio
Yes, I saw I2S support as well as for external audio codec chips, but nothing for the on-chip Class D. Are there any other supported processors that have on-board audio that I can use as a “template”? I’ve run out of ideas of what to search for! From: Gregory Nutt Reply to: Date: Thursday, 19 August 2021 at 21:38 To: Subject: Re: sama5D2 class D audio I implemented audo on the SAMA4D3 and D4: ./sama5d3x-ek/configs/nxplayer/defconfig:CONFIG_DRIVERS_AUDIO=y ./sama5d4-ek/configs/elf/defconfig:CONFIG_DRIVERS_AUDIO=y ./sama5d4-ek/configs/ipv6/defconfig:CONFIG_DRIVERS_AUDIO=y ./sama5d4-ek/configs/nsh/defconfig:CONFIG_DRIVERS_AUDIO=y ./sama5d4-ek/configs/nxwm/defconfig:CONFIG_DRIVERS_AUDIO=y These, however, used I2S for interface to an WM8904 DAC. On 8/19/2021 12:41 PM, Tim Hardisty wrote: Working through the remaining driver support I need for my custom board and I can’t find anything related to audio for the sama5d2 devices (they have Class D capability, with lots of modes). Before I dive in and find some time to create a driver from scratch, have I missed something? Documentation on audio support in general seems rather lacking so any pointers in the right direction would be appreciated (even just a suggestion of another processor with similar capability I can use as a reference). TIA, Tim.
Re: SPI EEPROM
That’s AT24 I2C not AT25 SPI EEPROM unfortunatel, and from a quick look it “just worked” ☹ From: Alan Carvalho de Assis Reply to: Date: Tuesday, 24 August 2021 at 18:01 To: Subject: Re: SPI EEPROM Hi Tim, You are right, Documentation is one of our "Achilles tendon". But, of course, some times it is also the user search fault, maybe they don't have the Google-fun skills yet (please don't take it as personal). If you search for NuttX EEPROM Tutorial It will returns this tutorial: https://www.youtube.com/watch?v=qzjf2JtgYN0 Please get us to improve this situation, write a tutorial at: nuttx/Documentation/guides/ about it. BR, Alan On 8/24/21, Tim wrote: The more time I spend with nuttx the more I think I just haven't found some treasure trove of documentation somewhere. All I seem to end up doing is searching every single file for some kind of clue as to what to do! I have an SPI EEPROM device. Menuconfig allows me to set it up, lovely! I end up with CONFIG_EEPROM=y CONFIG_SPI_EE_25XX=y (Also SPI mode and frequency). Now what.. If I search for either of those CONFIG parameters, the first is not referenced anywhere (apart from my .config), the second confirms that it will include spi_xx25xx.c as a source. Getting there.. It'll be ee25xx_initialize(FAR struct spi_dev_s *dev, FAR char *devname, int devtype, int readonly) I need to call - makes sense. Only there is no explanation, or examples of, how to make that call, and a Google search doesn't help either. Next step will be to look for examples of spi_dev_s and see if I can deduce it somehow. Just how am I supposed to know how to call that initialisation code? Which is why I started this question with the observation that surely I must be missing something somewhere!!?? Yes, it's a bit of a whinge, but also a request for help..please :)
Re: SPI EEPROM
I have 3 different SAMA5D2 eval board and have used them for years. I have had my custom board running “bare metal” code based on the Atmel code with no problems. Everything works, including the many many custom device on the board. I can swim. Using Lvgl too. I made the decision to move to NuttX as I hoped it would make it easier to write the final app as I need USB host, USB device, and a file system. It feels, right now, like it was a bad move as the documentation is seemingly incomplete. There is no point me getting yet another eval board just to prove that boards that are already supported work. Or should work - the SAMA5 eval boards are “supported” but are full of errors (e.g. flexcom is based on SAMA5D3 which is different; SAMA5D2 has MCAN but the D3 has CAN and needs a completely different driver; and so on. PRs to follow!!). As I have found, even basic devices such as nor flash or SPI EEPROM have only minimal support and, more importantly, no documentation that’s worth using. I will just have to keep struggling, googling, grepping, and hoping to hit lucky. I will add to the documentation once I have it working. If I get it working. And this is not aimed at you, Alan, as I know you are trying hard to help. From: Alan Carvalho de Assis Reply to: Date: Tuesday, 24 August 2021 at 19:42 To: Subject: Re: SPI EEPROM Hi Tim, The process to get AT25 SPI is similar, but for SPI you need to get the CS pin configure besides the other four SPI pins. Is this your first time using SPI on NuttX? There are some tutorials at NuttX Channel explaining how to use SPI on NuttX, like using SDCard over SPI. I suggest you to start with a board that has everything in place already, like the STM32F4Discovery or BluePill (stm32f103-minimum). Also the guys from MicroROS wrote a more technical tutorial about how SPI works on NuttX: https://github.com/micro-ROS/NuttX/issues/29 There is not theoretical class of swimming, you need to enter in the water, just start in the shallow place: stm32 + sdcard spi for example. BR, Alan On 8/24/21, Tim Hardisty wrote: That’s AT24 I2C not AT25 SPI EEPROM unfortunatel, and from a quick look it “just worked” ☹ From: Alan Carvalho de Assis Reply to: Date: Tuesday, 24 August 2021 at 18:01 To: Subject: Re: SPI EEPROM Hi Tim, You are right, Documentation is one of our "Achilles tendon". But, of course, some times it is also the user search fault, maybe they don't have the Google-fun skills yet (please don't take it as personal). If you search for NuttX EEPROM Tutorial It will returns this tutorial: https://www.youtube.com/watch?v=qzjf2JtgYN0 Please get us to improve this situation, write a tutorial at: nuttx/Documentation/guides/ about it. BR, Alan On 8/24/21, Tim wrote: The more time I spend with nuttx the more I think I just haven't found some treasure trove of documentation somewhere. All I seem to end up doing is searching every single file for some kind of clue as to what to do! I have an SPI EEPROM device. Menuconfig allows me to set it up, lovely! I end up with CONFIG_EEPROM=y CONFIG_SPI_EE_25XX=y (Also SPI mode and frequency). Now what.. If I search for either of those CONFIG parameters, the first is not referenced anywhere (apart from my .config), the second confirms that it will include spi_xx25xx.c as a source. Getting there.. It'll be ee25xx_initialize(FAR struct spi_dev_s *dev, FAR char *devname, int devtype, int readonly) I need to call - makes sense. Only there is no explanation, or examples of, how to make that call, and a Google search doesn't help either. Next step will be to look for examples of spi_dev_s and see if I can deduce it somehow. Just how am I supposed to know how to call that initialisation code? Which is why I started this question with the observation that surely I must be missing something somewhere!!?? Yes, it's a bit of a whinge, but also a request for help..please :)
Re: SPI EEPROM
AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I have (AT25128) and it is not well supported, with no example code or boards that support it (that I can find) From: Gregory Nutt Reply to: Date: Tuesday, 24 August 2021 at 20:11 To: Subject: Re: SPI EEPROM That’s AT24 I2C not AT25 SPI EEPROM unfortunatel, and from a quick look it “just worked” ☹ There is support for the AT24 in other SAM boards. Search for AT24 in defconfigs, I find boards/arm/samv7/same70-xplained/ boards/arm/samv7/samv71-xult/ boards/arm/xmc4/xmc4500-relax There is even simulated AT24 support: boars/sim/sim/sim You should be able to duplicate the logic from the samv7 boards.
Re: Re[2]: SPI EEPROM
Thanks Vadim – that’s pretty much the conclusion I had come to. Tim. Subject: Re[2]: SPI EEPROM Hi Tim, You could search for any spi device being initialized. Search for spi_dev_s being declared in boards folder for some board, use it as an example and do the same initialization.
Re: SPI EEPROM
Thanks Alan – all my SPI pins are configured. That was easy to work out :) I will follow this tomorrow and I’m sure it will all seem easier in the morning! From: Alan Carvalho de Assis Reply to: Date: Tuesday, 24 August 2021 at 20:59 To: Subject: Re: SPI EEPROM Hi Tim, It is very straightforward, basically you will replace: FAR struct i2c_master_s *i2c; i2c = stm32_i2cbus_initialize(AT24_I2C_BUS); mtd = at24c_initialize(i2c); WITH: FAR struct spi_dev_s *spi; spi = sam_spibus_initialize(AT25_SPI_PORTNO); mtd = at25_initialize(spi); But of course, if you don't know how to configure the SPI pins (including the GPIO pin CS), nothing will work. For Atmel/Microchip SAMxx family SPI, I think boards/arm/samv7/samv71-xult/src/sam_st7789.c could be a good reference. BR, Alan On 8/24/21, Tim Hardisty wrote: AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I have (AT25128) and it is not well supported, with no example code or boards that support it (that I can find) From: Gregory Nutt Reply to: Date: Tuesday, 24 August 2021 at 20:11 To: Subject: Re: SPI EEPROM That’s AT24 I2C not AT25 SPI EEPROM unfortunatel, and from a quick look it “just worked” ☹ There is support for the AT24 in other SAM boards. Search for AT24 in defconfigs, I find boards/arm/samv7/same70-xplained/ boards/arm/samv7/samv71-xult/ boards/arm/xmc4/xmc4500-relax There is even simulated AT24 support: boars/sim/sim/sim You should be able to duplicate the logic from the samv7 boards.
Re: SPI EEPROM
That isn't quite right, Alan, as the mtd at25_initialize routine is for SPI FLASH not SPI EEPROM - it tries to read an ID. I have replied to my other thread with the solution for AT25 SPI EEPROM, for others to refer to if they want On 24/08/2021 20:59, Alan Carvalho de Assis wrote: Hi Tim, It is very straightforward, basically you will replace: FAR struct i2c_master_s *i2c; i2c = stm32_i2cbus_initialize(AT24_I2C_BUS); mtd = at24c_initialize(i2c); WITH: FAR struct spi_dev_s *spi; spi = sam_spibus_initialize(AT25_SPI_PORTNO); mtd = at25_initialize(spi); But of course, if you don't know how to configure the SPI pins (including the GPIO pin CS), nothing will work. For Atmel/Microchip SAMxx family SPI, I think boards/arm/samv7/samv71-xult/src/sam_st7789.c could be a good reference. BR, Alan On 8/24/21, Tim Hardisty wrote: AT24 is I2C and this is well supported in NuttX. AT25 is SPI and is what I have (AT25128) and it is not well supported, with no example code or boards that support it (that I can find) From: Gregory Nutt Reply to: Date: Tuesday, 24 August 2021 at 20:11 To: Subject: Re: SPI EEPROM That’s AT24 I2C not AT25 SPI EEPROM unfortunatel, and from a quick look it “just worked” ☹ There is support for the AT24 in other SAM boards. Search for AT24 in defconfigs, I find boards/arm/samv7/same70-xplained/ boards/arm/samv7/samv71-xult/ boards/arm/xmc4/xmc4500-relax There is even simulated AT24 support: boars/sim/sim/sim You should be able to duplicate the logic from the samv7 boards.
Re: nxfss on MT25Q nor flash
My board is now correctly registering the SPI instance and binding the relevant SPI and CS to the SPI Flash driver. It was an uphill struggle, but thanks to all your various suggestions I have got there and learned more than I wanted to! Next hurdle is to trawl through other boards to learn how to "automount" my SPI flash as a file system - maybe SMART or maybe MXFSS; right now, any file system mounting from my board or app init function would be good :) On 24/08/2021 16:53, Alan Carvalho de Assis wrote: Hi Tim, It seams like MT25Q uses the m25px.c driver, so I assume you are enabling the CONFIG_MT25Q_MEMORY_TYPE right? Next you need to configure our board SPI CS pin, please take a look at: arm/stm32/mikroe-stm32f4/src/stm32_spi.c Then before try to setup the NXFFS you need to confirm that the Flash NOR was detected correctly. BR, Alan On 8/24/21, Tim wrote: Does anyone have any pointers on how to setup nxfss (or any filesystem for that matter) on an MT25Q nor flash? I cannot find any code for any other boards that makes any sense to me and I feel this should be a pretty basic thing to want to do? I believe I have set up all the SPI stuff and now need to (auto)mount it in my bringup or app init code, but I'm stuck :( "CONFIG_HAVE_M25P" is as far as I have got. SAMA5D27 device. TIA, Tim.
Re: which filesystem?
Hi Ken,
You fell for my 100% unintentional trap…thread title didn’t match content! I’d
started one message, saved it as a draft, then changed my mind on what to ask
but didn’t change the title. Doh!
I did try SmartFS and really like the sound of it, but it didn’t work “out of
the box”. I think it is because it can’t cope with 256Mbit devices; I got a
number of errors to do with sector sizes (from memory) and a quick debug
suggestion that perhaps some variables are defined as 16 bit: not sure, and
might return to it.
To answer your question – which was the original intent of this help request,
the aim is fundamentally data logging. Users will log data (at 20Hz, say;
multiple parameters) then occasionally pull them off for external analysis,
delete, and start again. So I don’t think wear levelling is actually an issue;
just speed and ease of pulling data off to spit out over USB or Bluetooth LE,
on an occasional basis.
One file open for write is fine with what I currently envision, but who knows.
SmartFS has much appeal as a “just in case”. I have more DRAM than I know what
to do with :)
Tim.
From: Ken Pettit
Reply to:
Date: Wednesday, 25 August 2021 at 18:12
To:
Subject: Re: which filesystem?
Hey Tim,
Selection of filesystem is kind of a personal choice. Each filesystem
has different features / benefits. I have never used NXFFS but I know
it absolutely works with the caveat that you can only have one file open
for writing at a time. Because of this, I wrote SmartFS, which doesn't
have this limitation, but also adds extra RAM usage for each open file.
So as you see, there are tradeoffs. There is also LittleFS and SPIFFS
to choose from to make it even more complicated.
So I guess you first should ask, what features do I need from the FS?
Directory support? Wear leveling? Multiple open files for write?
Maybe a list of the features needed from the FS will help.
Ken
On 8/25/21 10:04 AM, Tim wrote:
I seem to have got over most of my SPI flash and EEPROM issues now and my
256Mb SPI flash is properly recognised.
I think I am at the last hurdle. Here is the console output, along with my
question of the day :)
Successfully initialized M25P SPI
m25p_initialize: dev: 0x2005b970
m25p_readid: priv: 0x2005b990
m25p_readid: manufacturer: 20 memory: ba capacity: 19
m25p_initialize: Return 0x2005b990
Successfully bound SPI0 CS1 to the SPI FLASH driver
m25p_ioctl: cmd: 1537
m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192
m25p_ioctl: return 0
m25p_bread: startblock: nblocks: 1
m25p_read: offset: nbytes: 256
m25p_waitwritecomplete: Complete
m25p_read: return nbytes: 256
nxffs_nextentry: No entry found
nxffs_limits: No inodes found
nxffs_limits: Free FLASH region begins at offset: 5
nxffs_limits: First inode at offset 5
Succesfully initialised NXFSS
nx_mount: ERROR: Failed to find block driver (null)
Failed to mount the NXFSS volume -15
I believe the block driver would be "/dev/M25P" (M25P, for example) but
there is no code I have found that specifies the block driver location. I
have:
ret = nxfss_initialize(mtd);
then
ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);
and that seems to be in common with other "bringup" code; using NULL rather
than "/dev/something".
Just need the last piece of this jigsaw if anyone could be so kind :)
Re: which filesystem?
Thanks Greg – and apologies for the wrong thread subject.
I have seen references in the code to FTL but stupidly thought it was some
other kind of FS. A non-Linux/Posix/Unix background means I am not totally
across the mtd/block driver terminology etc. I did use Unix, but that was
around 45 years ago!.
You have provided the “magic bullet” I need, and I am confident I will now get
it working quickly in the morning.
Tim.
From: Gregory Nutt
Reply to:
Date: Wednesday, 25 August 2021 at 18:14
To:
Subject: Re: which filesystem?
m25p_initialize() does not generate a block driver. I creates an MTD
driver. To get a block driver, you have to wrap the MTD driver
instances in an FTL (FLASH Translation Layer) instance. These should be
examples:
$ find . -name "*.c" | xargs grep -l ftl_initialize | xargs grep -l
nxffs_initialize
./arm/cxd56xx/common/src/cxd56_flash.c
./arm/lpc43xx/bambino-200e/src/lpc43_appinit.c
./arm/lpc43xx/lpc4330-xplorer/src/lpc43_appinit.c
./arm/lpc43xx/lpc4357-evb/src/lpc43_appinit.c
./arm/sam34/sam4e-ek/src/sam_at25.c
./arm/sam34/sam4s-xplained-pro/src/sam_nandflash.c
./arm/sama5/sama5d2-xult/src/sam_at25.c
./arm/sama5/sama5d2-xult/src/sam_nandflash.c
./arm/sama5/sama5d3-xplained/src/sam_at25.c
./arm/sama5/sama5d3-xplained/src/sam_nandflash.c
./arm/sama5/sama5d3x-ek/src/sam_at24.c
./arm/sama5/sama5d3x-ek/src/sam_at25.c
./arm/sama5/sama5d3x-ek/src/sam_nandflash.c
./arm/sama5/sama5d4-ek/src/sam_at25.c
./arm/sama5/sama5d4-ek/src/sam_nandflash.c
./arm/samd5e5/metro-m4/src/sam_at24.c
./arm/samv7/samv71-xult/src/sam_bringup.c
./arm/stm32/cloudctrl/src/stm32_w25.c
./arm/stm32/fire-stm32v2/src/stm32_w25.c
./arm/stm32/shenzhou/src/stm32_w25.c
./arm/stm32/stm32f103-minimum/src/stm32_at24.c
./arm/stm32l4/stm32l476vg-disco/src/stm32_appinit.c
./arm/tiva/tm4c123g-launchpad/src/tm4c_at24.c
./mips/pic32mx/mirtoo/src/pic32_appinit.c
./xtensa/esp32/esp32-devkitc/src/esp32_spiflash.c
./xtensa/esp32/esp32-ethernet-kit/src/esp32_spiflash.c
./xtensa/esp32/esp32-wrover-kit/src/esp32_spiflash.c
The block driver should be called /dev/mtdblockN where N is the minor
device number passed as the first argument to ftl_initialize().
On 8/25/2021 11:04 AM, Tim wrote:
I seem to have got over most of my SPI flash and EEPROM issues now and my
256Mb SPI flash is properly recognised.
I think I am at the last hurdle. Here is the console output, along with my
question of the day :)
Successfully initialized M25P SPI
m25p_initialize: dev: 0x2005b970
m25p_readid: priv: 0x2005b990
m25p_readid: manufacturer: 20 memory: ba capacity: 19
m25p_initialize: Return 0x2005b990
Successfully bound SPI0 CS1 to the SPI FLASH driver
m25p_ioctl: cmd: 1537
m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192
m25p_ioctl: return 0
m25p_bread: startblock: nblocks: 1
m25p_read: offset: nbytes: 256
m25p_waitwritecomplete: Complete
m25p_read: return nbytes: 256
nxffs_nextentry: No entry found
nxffs_limits: No inodes found
nxffs_limits: Free FLASH region begins at offset: 5
nxffs_limits: First inode at offset 5
Succesfully initialised NXFSS
nx_mount: ERROR: Failed to find block driver (null)
Failed to mount the NXFSS volume -15
I believe the block driver would be "/dev/M25P" (M25P, for example) but
there is no code I have found that specifies the block driver location. I
have:
ret = nxfss_initialize(mtd);
then
ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);
and that seems to be in common with other "bringup" code; using NULL rather
than "/dev/something".
Just need the last piece of this jigsaw if anyone could be so kind :)
Re: which filesystem?
I am only just getting the point of having the luxury to think about what FS to use lol. My 1st thought was indeed FAT and USB MSD for sure…but I made the randome decision to put a USB-C connector and FUSB controller on the board and haven’t got that working yet. The beauty of NuttX is it gives me all these choices and, despite my “rants” of yesterday I still know it was the right choice for this board/product :) From: Gregory Nutt To answer your question – which was the original intent of this help request, the aim is fundamentally data logging. Users will log data (at 20Hz, say; multiple parameters) then occasionally pull them off for external analysis, delete, and start again. So I don’t think wear levelling is actually an issue; just speed and ease of pulling data off to spit out over USB or Bluetooth LE, on an occasional basis. Hmmm.. If you don't care about about wear-leveling but you want to get data from USB (via USB MSC?), then you should consider FAT. You can export and mount the SPI FLASH-based FAT file system on any host just as though it were a any other USB FLASH driver. FLASH file systems only exist to handle wear-leveling and bad block handling. (I think I do have some ancient FAT bad block logic somewhere that I never got merged upstream).
Re: which filesystem?
Thanks Sara – I’m having a problem with your emails…via my work server they are rejected, and my personal email marks them as spam, but delivers them and messes up the formatting. I can see you have some good suggestions so I will try and unravel it all and reply tomorrow. From: Sara da Cunha Monteiro de Souza Reply to: "dev@nuttx.apache.org" Date: Wednesday, 25 August 2021 at 19:15 To: "dev@nuttx.apache.org" Subject: Re: which filesystem? Em qua., 25 de ago. de 2021 às 15:12, Sara da Cunha Monteiro de Souza < saramonteirosouz...@gmail.com> escreveu: > Hy Tim, > > 1. PTAL at: > https://www.mail-archive.com/dev@nuttx.apache.org/msg06767.html and see > if the issues you found with SMARTFS > can be solved with the proper configurations and commands. > Just jump to the last message.
Naffs - format?
Today's dumb question! Having got a mounted nxffs spi flash "drive", I had a quick try earlier today to store some data. If I did: nsh> ls > /mnt/flash/file1.txt there was a major crash. If I enabled the startup scan it sat there for 20+ minutes before I gave up and halted it (it was still doing stuff via SPI to the memory, and info debug enabled showed lots going on)...but then the same nsh command worked and the file was created. This suggests to me the file system may need to be formatted or "created" maybe but...guess what...I can't find anything in any guides to suggest this is needed. SmartFS seems to need it - "nsh> mksmartfs /dev/smart0" for example - but not had time to play more with that yet). Or is it because the flash device is full of duff stuff from all my messing around and just needs to be erased and I start again (not thought of that until now). Be gentle... :)
Re: Naffs - format?
(no insult intended…naffs was a typo!) From: Tim Hardisty Today's dumb question! Having got a mounted nxffs spi flash "drive", I had a quick try earlier today to store some data. If I did: nsh> ls > /mnt/flash/file1.txt there was a major crash. If I enabled the startup scan it sat there for 20+ minutes before I gave up and halted it (it was still doing stuff via SPI to the memory, and info debug enabled showed lots going on)...but then the same nsh command worked and the file was created. This suggests to me the file system may need to be formatted or "created" maybe but...guess what...I can't find anything in any guides to suggest this is needed. SmartFS seems to need it - "nsh> mksmartfs /dev/smart0" for example - but not had time to play more with that yet). Or is it because the flash device is full of duff stuff from all my messing around and just needs to be erased and I start again (not thought of that until now). Be gentle... :)
Re: NuttX Monthly Meetup
What sort of agenda, or purpose, Alan? Sounds like a good idea but some suggestion of what to expect would be good :) On 22/09/2021, 18:20, "Alan Carvalho de Assis" wrote: Dear NuttXers, We want to do monthly meets with our developers and users. The first online meet will be this Friday (2021/09/24) at 18:00 GMT. Everybody can join using this link: https://meet.jit.si/NuttXMeetup BR, Alan
Re: Poll: Which OS are you using to compile NuttX?
Needs a LinkedIn login? From: Alan Carvalho de Assis Reply to: "dev@nuttx.apache.org" Date: Friday, 24 September 2021 at 20:20 To: dev Subject: Poll: Which OS are you using to compile NuttX? Hi Everyone, Please help us to discover which OS people are using most to compile NuttX: https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/ It will help us to decide how better support your host OS. BR, Alan
Re: Poll: Which OS are you using to compile NuttX?
Linux On 24/09/2021, 21:07, "Alan Carvalho de Assis" wrote: Sorry guys, I suppose you are using LinkedIn too. Yes, probably it will collect some data from you, but you are using a better MS gather: "Sent from Mail for Windows" So, if you are already in the hell, please give a warm hug in the Lucifer :-D Now, let be serious here: for those who don't have LinkedIn access, please reply this email with one of these options: 1) Linux 2) MacOS 3) Windows using Cygwin 4) Windows Native Thank you for the understanding. BR, Alan On 9/24/21, Russell Haley wrote: > The link gives me “This post cannot be displayed”. I am logged into the > Microsoft data collection site known as LinkedIn. > > Sent from Mail for Windows > > From: Tim Hardisty > Sent: Friday, September 24, 2021 12:54 PM > To: dev@nuttx.apache.org > Subject: Re: Poll: Which OS are you using to compile NuttX? > > Needs a LinkedIn login? > > > > From: Alan Carvalho de Assis > Reply to: "dev@nuttx.apache.org" > Date: Friday, 24 September 2021 at 20:20 > To: dev > Subject: Poll: Which OS are you using to compile NuttX? > > Hi Everyone, Please help us to discover which OS people are using most to > compile NuttX: > https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/ It > will help us to decide how better support your host OS. BR, Alan > >
Re: USB MSD problem
On 22/12/2021, 20:15, "Alan Carvalho de Assis" wrote: >On 12/22/21, TimH wrote: >> On 22/12/2021 15:55, Alan Carvalho de Assis wrote >> If I want to share what I'm doing with the details of the project etc, >> where might you suggest I do this? >If you want share your progress and findings, it is better to create a blog. Is there a specific NuttX blog site you were thinking of? Otherwise I'll do my own somewhere/somehow!
Re: USB MSD problem
Yes, I now think so. I know I looked at stack settings but (without benefit of access to my Linux work machine from home) if I recall they are spread around the place and I suspect - from other advise here - that it is the app stack size that is inadequate. Hopefully a break from it all will make it all seem simpler next week! On 26/12/2021, 21:38, "Jukka Laitinen" wrote: Could it simply be a stack overflow? Alan Carvalho de Assis kirjoitti keskiviikko 22. joulukuuta 2021: > Exactly, something is changing the memory layout and forcing the error > to happen.
Re: MT25P vs MT25Q bulk erase difference - how to fix?
Thanks - makes sense. I am still not 100% convinced the M25P code is
actually correct for the M25Q. It's a work-in-progress.
This is what I have added, and all other things being equal, I will use
it in the driver where there are subtle differences needed.
structm25p_dev_s
{
structmtd_dev_smtd; /* MTD interface */
FARstructspi_dev_s*dev; /* Saved SPI interface instance */
uint8_tsectorshift; /* 16 or 18 */
uint8_tpageshift; /* 8 */
uint16_tnsectors; /* 128 or 64 */
uint32_tnpages; /* 32,768 or 65,536 */
***uint16_tmanufacturer**; **/* detected manufacturer */*
***uint16_tmemory**; **/* detected memory type */*
#ifdefCONFIG_M25P_SUBSECTOR_ERASE
uint8_tsubsectorshift; /* 0, 12 or 13 (4K or 8K) */
#endif
};
and
SPI_SEND(priv->dev, M25P_RDID);
manufacturer= SPI_SEND(priv->dev, M25P_DUMMY);
memory= SPI_SEND(priv->dev, M25P_DUMMY);
capacity= SPI_SEND(priv->dev, M25P_DUMMY);
/* Deselect the FLASH and unlock the bus */
SPI_SELECT(priv->dev, SPIDEV_FLASH(0), false);
m25p_unlock(priv->dev);
/* save the manufacturer and memory type */
***priv**->**manufacturer**= **manufacturer**;*
***priv**->**memory**= **memory**;*
and in the erase function
/* Send the "Bulk Erase (BE)" instruction or "Die Erase" as appropriate*/
if(priv->manufacturer== M25P_MANUFACTURER&&
(priv->memory== MT25Q_MEMORY_TYPE|| priv->memory== MT25QU_MEMORY_TYPE))
{
SPI_SEND(priv->dev, M25Q_DE);
}
else
{
SPI_SEND(priv->dev, M25P_BE);
}
On 18/01/2022 16:36, Sebastien Lorquet wrote:
Hello,
If the Die Erase is similar in function to the bulk erase, then it can
be used instead, but this has to be done at runtime to support all the
chips in the same driver. So no @define or CONFIG_ option, because
choosing one would excude the others, and if you have both on a board
this would be bad.
The runtime fix is not heavy. My recommended way is:
-add a uint8_t device_manufacturer field in the m25px structure,
initialized when the JEDEC ID is obtained from the device (IIRC,
m25px_initialize or something like that)
-then, use this field in the m25px_erase method to choose the correct
command(, and parameters if needed).
I woud appreciate if you agreed to share your changes beforehand (eg
pull request) so I can review this simple change, because i'm using this
driver in a professional project and I would like to make sure there are
no regressions.
Thank you,
Sebastien
Le 18/01/2022 à 16:41, Tim a écrit :
As I still get deeper and deeper into why FAT doesn't work on my
MT25Q NOR
flash device, I have found a minor error in m25px.c
The M25P devices have a bulk erase command (0xC7) but this is not
supported
by the MT25Q, which has a "die erase" command (0xC4) instead and 0xC7 is
meaningless.
There is a #define for this as expected:
#define M25P_BE 0xc7
Adding
#define M25Q_DE 0xc4
Make sense but...
When the device manufacturer ID is read this is actually saved, so it
can't
be tested at runtime to choose the right command.
The straightforward fix is to move the #define for M25_BE to within
the code
that tests the manufacturer ID (to ensure it's a valid device for these
functions) but that is a bit messy and moves the #define away from
all the
other related #defines. Doesn't feel right.
There is no unique CONFIG_ attribute that says whether it is or isn't
expecting to find an M25P or M25Q (which is reasonable) so I can't use
conditional #defines.
And don't want to mess up other people's boards by changing Kconfig
in any
way that isn't backwards compatible, although the inviolable
"Sometimes Code
Duplication is OK" might suggest it would be better to copy out
m25px.c as
m25lx.c and make the change so that Kconfig demands you choose one or
the
other or both of the two types...and if I find more
errors/differences that
may ultimately make sense of course.
Can anyone suggest the "NuttX way" to do this, assuming I don't find a
myriad of other errors/differences that "force" duplication?
Re: RNDIS
Thanks Alanm - my lack on Linux knowledge failed me again. Never used dmesg...luckily I like learning lol. From Linux machine: [ 3399.181365] usb 1-2: new high-speed USB device number 21 using xhci_hcd [ 3399.337980] usb 1-2: New USB device found, idVendor=584e, idProduct=5342, bcdDevice= 0.01 [ 3399.337985] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3399.337987] usb 1-2: Product: RNDIS NuttX [ 3399.337988] usb 1-2: Manufacturer: NuttX [ 3399.337990] usb 1-2: SerialNumber: 1234 [ 3399.339311] rndis_host 1-2:1.0: skipping garbage [ 3399.339551] rndis_host 1-2:1.0: dev can't take 1558 byte packets (max 1364), adjusting MTU to 1306 [ 3399.339857] rndis_host 1-2:1.0: RNDIS_MSG_QUERY(0x01010101) failed, -32 [ 3399.339859] rndis_host 1-2:1.0: rndis get ethaddr, -32 [ 3399.339930] rndis_host: probe of 1-2:1.0 failed with error -32 [ 3399.339996] rndis_wlan 1-2:1.0: skipping garbage [ 3399.340140] rndis_wlan 1-2:1.0: dev can't take 1558 byte packets (max 1364), adjusting MTU to 1306 No debug warnings in nuttx for USB or network. So now hunting through the menuconfig to find relevant settings! On 20/01/2022 23:45, Alan Carvalho de Assis wrote: Please verify if dmesg can give use some hint about the issue. On 1/20/22, TimH wrote: Nope, doesn't show. So RNDIS is not working right on my board. What a surprise! On 20/01/2022 19:30, Alan Carvalho de Assis wrote: Exactly, knowing Unix/Linux makes your live easier with NuttX. Using "ip list" (or ifconfig) on Linux should display the new USB RNDIS interface. BR, Alan
Re: SPI problem
>From my own struggles to get a board (custom board as it happens, but like >others that were there) I found: Board support was often incomplete. Look at other boards to see where and how SPI is initialised and registered. You may find something basic is missing. Stack size. Random errors occur if there’s insufficient stack Just because a board is there, neither assume the support is complete nor correct! For example, for my SAMA5D27-based boards I found: Errors in PIO mapping (from memory, PIO C and D had incorrect addresses. PIOD was missing from Kconfig) CAN support had compile errors. It shouldn’t actually have used CAN as that A5D2 processor uses “mcan” needing a different set of drivers to the A5D3 or D4 processors in that family Other peripherals had no support at all – Flexcom and ClassD Audio, for example. I suppose that if a particular eval board has a set of specific peripherals actually used, then support has probably been tried – but if the eval board for yours doesn’t have anything connected to SPI then whoever ported the board would have nothing there to test it with. Bottom line – ASSUME NOTHING!! From: Roberto Bucher Reply to: Date: Sunday, 6 March 2022 at 08:54 To: Subject: SPI problem When I enable some dubug configs I get the following error by enter in the serial shell: sert: Assertion failed at file:spi/spi_driver.c line: 358 arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800 R3: 20010684 arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370 FP: 20010670 arm_registerdump: R8: SB: SL: R11: arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad PC: 0800648e arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: 0004 arm_registerdump: EXC_RETURN: ffe9 arm_dump_stack: User Stack: On the line 358 of spi_driver.c there is this assertion: /* Sanity check */ DEBUGASSERT(spi != NULL && (unsigned)bus < 1000); Any Idea? Best regards Roberto
Re: 10.3 merge issues
I realise, now, I compared mine against 10.2 variants not 10.3...not sure why,
but there you go. I'll give that a try tomorrow - thanks!
On 17/08/2022, 20:19, "Nathan Hartman" wrote:
On Wed, Aug 17, 2022 at 3:15 PM Nathan Hartman
wrote:
>
> On Wed, Aug 17, 2022 at 2:38 PM TimH wrote:
> > >> no rule to make target '-T/home/{rest of the path}'
>
> See commit:
https://github.com/apache/incubator-nuttx/commit/8defb843aa2e1d49b08b1cb7155aea97e1721b6c
>
> There have been some refactorings in the build system to reduce code
> duplication.
>
> So instead of writing all this:
>
> ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
> ARCHSCRIPT = -T "${shell cygpath -w
> $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
> else
> ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
> endif
>
> Now you only have to write:
> ARCHSCRIPT += $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
>
> I recommend to compare your Make.defs with that of the board you
> cloned and bring over all changes.
This is the PR: https://github.com/apache/incubator-nuttx/pull/5496
Cheers,
Nathan
Re: Driver for combined battery charger and regulator
>>> Please correct me if I'm still missing something, as there are zero >>> clues I can find as to what each ops function (for example) is >>> actually supposed to do. >> >> >> >>Here is two examples: >>https://github.com/apache/incubator- >>nuttx/blob/master/drivers/power/supply/regulator_gpio.c >>https://github.com/apache/incubator- >>nuttx/blob/master/drivers/power/supply/regulator_rpmsg.c >thank you for these, I will take a look and hopefully they will point me >in the right direction. Please: what are the purpose of: set_voltage_sel get_voltage_sel
Re: Driver for combined battery charger and regulator
>> Please: what are the purpose of: >> >> set_voltage_sel >> get_voltage_sel >> >FYI: https://www.kernel.org/doc/html/v4.12/driver-api/regulator.html Alan to the rescue again :-) Perhaps Nuttx needs a warning to newcomers: "enter without Linux knowledge at your peril" LOL
Re: Driver for combined battery charger and regulator
On Wed, Sep 7, 2022 at 1:03 PM Tim Hardisty wrote: >> >> >> >>> Please correct me if I'm still missing something, as there are zero >> >>> clues I can find as to what each ops function (for example) is >> >>> actually supposed to do. >> >> >> >> >> >> >> >>Here is two examples: >> >>https://github.com/apache/incubator- >> >>nuttx/blob/master/drivers/power/supply/regulator_gpio.c >> >>https://github.com/apache/incubator- >> >>nuttx/blob/master/drivers/power/supply/regulator_rpmsg.c >> >> >thank you for these, I will take a look and hopefully they will point me >> >in the right direction. >> > Please: what are the purpose of: >> >> set_voltage_sel >> get_voltage_sel >This really should be documented in the definition of struct >regulator_ops_s in include/nuttx/power/regulator.h, particularly what >is the difference between set_voltage and set_voltage_sel. I agree - this should be there as comments. I will eventually submit a PR for my driver and, if it's not done by then, I will add these in the same PR >That said, based on reading the code at _regulator_do_set_voltage() in >drivers/power/supply/regulator.c, it appears that: >1) set_voltage() is given a minimum and maximum desired voltage in >microvolts and sets (if possible) the regulator's voltage selector to >generate something between those bounds. It is up to the lower-half >driver to look at the desired min and max voltage and figure out what >the selector should be, whereas: >2) set_voltage_sel() is given the selector value itself and sets that. >The lower-half driver doesn't make decisions in this case; the >upper-half driver iterates through all available voltages to decide >which one is the "best" and then calls the lower-half driver with that >selector value. >The logic in _regulator_do_set_voltage() is such that if the >lower-half driver provides set_voltage(), it prefers to call that; if >not, then I assume it's a more "primitive" driver and therefore the >upper-half decides the selector value. This is a great help, Nathan: thank you. The ACT8945A only allows discrete voltages to be set (64 values) so the set_voltage_sel may one way to sort this, although I already have code to select the right register value by some mathematical shenigans so could put that in the lower half and make use of the min and max values. It is all making sense now: lack of comments, and no examples in 10.3, are what done me in.
Re: Driver for combined battery charger and regulator
On 08/09/2022, 18:07, "Xiang Xiao" wrote: On Fri, Sep 9, 2022 at 12:19 AM TimH wrote: >> unsigned int apply_uv;/* ?? SEE BELOW [1] */ >Yes, bool is more suitable than int for apply_uv. Thanks for confirming/agreeing - once 11.0 is released and I rebase my own work I'll do a PR to change this (and add comments to the driver files). >>[2] It is not clear, either in Linux or Nuttx, what the "constraint >>voltage" that is applied during init will be. Perhaps the NuttX intent is - >>or should be - to use an actual value here (hence the int?) which will be >>applied during init IF "boot_on" is set on (suggesting it is a parameter >>that should be passed TO the regulator register/init function not filled in >>BY it? > > > boot_on in NuttX is simple, the common code will enable the regulator if > boot_on is true otherwise disable it in regulaotr_register. OK, makes sense, thanks. > If this is all (nearly) correct, then I think the call to register a > regulator Yes, I think so. > If I'm nearly right I might add that I believe there are useful members of > the regulator_desc_s structure missing, such as "active_discharge" that's > useful for the ACT8945A. > The fields in regulator_desc_s are designed for the common regulator > framework code, so it's better to put a new field to this struct if the > common does the different action based on it. If the new info is only used > by a specific driver, regulator_dev_s::priv is a better place. The two I suggested are in the Linux spec and are common things for processor PMICs. These would be good candidates to add to the common code I think. >> Final observation - Linux documentation quite clearly states microvolts >> for all voltage parameters. > > > The initial design follows Linux convention, that's why the field ends with > _uv not _mv.. uint32_t can hold 4293.967295V with uV which is enough in > most case. OK I will use uv. Think it might mean the AXP202 driver needs fixing...it is using battery charger framework for regulator functions so someone probably needs to revisit it at some point.
