Dear Alan, > But again, I think we can avoid this tortuous path and fix the CMake or > Makefile to build on Windows.
Fully understand. > BTW, could you please submit a PR with yours CMakefiles to AVR32? I want to > test it here too. For sure. May I send them to you tomorrow? I wrote them on Windows. An invocation of cmake complained with errors on Windows like I mentioned. I will test the CMake files with GNU/Linux before I send them to you tomorrow. R On Mon, 20 Nov 2023 at 18:39, Alan C. Assis <acas...@gmail.com> wrote: > Hi Raman, > > On 11/20/23, Raman Gopalan <ramangopa...@gmail.com> wrote: > > Dear Alan, Greetings! > > > > Many thanks for your suggestions. > > > >> Note that I already adapted it to use your Atmel ICE Device S/N. I just > > use: $ > >> sudo openocd -f openocd.cfg > > > > Thank you Alan. I just pasted your openocd configuration and invoked > > openocd > > just like you suggested. Unfortunately, I still see the same problem I > had > > yesterday. Here is the output: > > > > raman@foo:~/Skullets$ sudo openocd -f openocd.cfg > > Open On-Chip Debugger 0.12.0+dev-00342-g21f17260d (2023-09-28-16:32) > > Licensed under GNU GPL v2 > > For bug reports, read > > http://openocd.org/doc/doxygen/bugs.html > > DEPRECATED! use 'adapter driver' not 'interface' > > DEPRECATED! use 'adapter serial' not 'cmsis_dap_serial' > > Info : auto-selecting first available session transport "swd". To > override > > use 'transport select <transport>'. > > DEPRECATED! use 'adapter srst delay' not 'adapter_nsrst_delay' > > DEPRECATED! use 'adapter srst pulse_width' not > 'adapter_nsrst_assert_width' > > adapter srst pulse_width: 100 > > Info : Listening on port 6666 for tcl connections > > Info : Listening on port 4444 for telnet connections > > Error: unable to find a matching CMSIS-DAP device > > > > raman@foo:~/Skullets$ > > > > But I also confirm that the Atmel ICE works fine with Microchip Studio OR > > `atprogram', the command line tool that comes with it. > > > > Do you see a similar "unable to find" error at your end? > > > > No, here OpenOCD is able to find my device, see log (without any board > connected to it) > > $ sudo openocd -f openocd.cfg > Open On-Chip Debugger 0.11.0+dev-00062-g6405d35f3 (2023-08-28-15:47) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > DEPRECATED! use 'adapter driver' not 'interface' > Info : auto-selecting first available session transport "swd". To > override use 'transport select <transport>'. > DEPRECATED! use 'adapter srst delay' not 'adapter_nsrst_delay' > DEPRECATED! use 'adapter srst pulse_width' not 'adapter_nsrst_assert_width' > adapter srst pulse_width: 100 > > Info : Listening on port 6666 for tcl connections > Info : Listening on port 4444 for telnet connections > Info : CMSIS-DAP: SWD Supported > Info : CMSIS-DAP: JTAG Supported > Info : CMSIS-DAP: FW Version = 01.27.0082 > Info : CMSIS-DAP: Serial# = J41800093472 > Info : CMSIS-DAP: Interface Initialised (SWD) > Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1 > Info : CMSIS-DAP: Interface ready > Info : clock speed 400 kHz > Error: Error connecting DP: cannot read IDR > > >> Ubuntu, like you are using. > > > > Perfect! Only I don't see what I'm getting wrong yet. > > > >> as said, Kevin Liu was able to integrate NuttX into Microchip Studio > > about 4 > >> years ago, but he compiled and exported NuttX as library, just like PX4 > > and > >> other projects are doing. > > > > That is so jolly good! Understand, Alan. > > > >> Raman, I think this hack approach it not easy to do with NuttX, because > >> different from other RTOS NuttX is very *very* customizable, that means > > you > >> can fine tune each internal bolts and nuts of it using some existent > >> CONFIG_something. So, besides selecting the right files, it also needs > >> the > >> right CONFIGs > > > > Understand. But is there a way to also get the config files onto > Microchip > > Studio? OR are these config files temporary (/tmp for example) and not > > physical > > config files. Just a quick workflow I imagine: configure the NuttX build > > for a > > specific target (say, avr32dev1) like we typically do on Cygwin. > > > > The ./tools/configure.sh -c avr32dev:nsh doesn't fail. Perhaps there's a > > way to > > employ a tool to recurse through the NuttX codebase and copy the C files > > and > > config files - assuming a default configuration? But if I have a rough > idea > > of > > the structure (and where to look for these file and their target > > destination for > > pickup), I can help whip up something quick and dirty as a proof of > > concept. > > > > At root of nuttx/ you will find a .config with all CONFIG_ selected. > > But again, I think we can avoid this tortuous path and fix the CMake > or Makefile to build on Windows. > > BTW, could you please submit a PR with yours CMakefiles to AVR32? I > want to test it here too. > > > I can also imagine this: I haven't tried this so far but I'm sure > Microchip > > Studio is powered by Visual Studio. Its project configuration is listed > > here > > [1], for example. I was just exploring to evaluate/gauge if we can > generate > > the > > cproj file at all. Just thoughts so far. > > > > In essence, I wanted to check with you if CMake/GNU Make do something > with > > the > > build that might otherwise be tricky to achieve using just Microchip > > Studio? > > Especially, on the Windows environment? > > > > Edit: I just ran `make -n' within nuttxspace/nuttx after configuring the > > build > > for avr32dev1. Oh, it such a long recipe! :) I understand it can be > tricky. > > I haven't read the echo to its entirely. > > > > You can run "make V=1" to see all files been compiled and flag parameters. > > >> Yes, you can git checkout an old version tag (i.e 7.x or 8.x) of nuttx > >> and > >> also the same version of apps. > > > > Understand. > > > >> Nice! Probably you will see something coming from serial. Also you can > > enable > >> the Debug to print the ABC... letter of each stage of the early boot > > process. > >> Similar to old days of LILO bootloader of Linux. > > > > Very nice. I will enable Debug to check this. > > > > Best Regards, > > Alan >
