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?

> 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.

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.

> 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.

R

References:
[1]:
https://github.com/ramangopalan/rtthread_mizar32b_sample/blob/master/rtthread_mizar32b_sample/rtthread_mizar32b_sample
.cproj

On Sun, 19 Nov 2023 at 20:05, Alan C. Assis <acas...@gmail.com> wrote:

> Hi Raman,
>
> On 11/19/23, Raman Gopalan <ramangopa...@gmail.com> wrote:
> > Dear All,
> >
> > I just plugged in the Atmel ICE programmer. I am currently working with
> my
> > Ubuntu GNU/Linux machine. Here are the version details:
> >
> > raman@foo:~/Skullets$ uname -a
> > Linux foo 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon
> Oct 9
> > 15:34:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
> >
> > I invoked `dmesg' to check if the Atmel ICE is getting enumerated. Here
> is
> > the
> > output of dmesg.
> >
> > [10286.164950] usb 1-2: USB disconnect, device number 11
> > [10289.787841] usb 1-2: new high-speed USB device number 12 using
> xhci_hcd
> > [10289.936757] usb 1-2: New USB device found, idVendor=03eb,
> > idProduct=2141, bcdDevice= 1.01
> > [10289.936773] usb 1-2: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=3
> > [10289.936779] usb 1-2: Product: Atmel-ICE CMSIS-DAP
> > [10289.936785] usb 1-2: Manufacturer: Atmel Corp.
> > [10289.936790] usb 1-2: SerialNumber: J42700053627
> > [10289.941501] hid-generic 0003:03EB:2141.000A: hiddev0,hidraw2: USB HID
> > v1.11 Device [Atmel Corp. Atmel-ICE CMSIS-DAP] on
> usb-0000:00:14.0-2/input0
> >
> > I had to create a quick configuration file for OpenOCD. Before jumping
> into
> > the
> > AVR32 hacks, I wanted to make sure the ICE works at all for a known
> target.
> > I
> > picked the SAMD21 target. I read about it here [1]. On invocation, I get
> > this
> > output:
> >
> > raman@foo:~/Skullets$ sudo openocd
> > 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
> > Info : auto-selecting first available session transport "swd". To
> override
> > use 'transport select <transport>'.
> > 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
> >
> > Am I missing something? The vendor and product IDs match.
> >
>
> I used this openocd.cfg in the past with Atmel ICE on Ubuntu:
>
> $ cat openocd.cfg
> # Atmel-ICE JTAG/SWD in-circuit debugger.
> interface cmsis-dap
> cmsis_dap_vid_pid 0x03eb 0x2141
> cmsis_dap_serial J42700053627
>
> # My board contains Atmel SAMD21G18 MCU.
> set CHIPNAME SAMD21G18A
> source [find target/at91samdXX.cfg]
>
> # Don't use srst, it will not work
> reset_config  srst_nogate
>
> adapter_nsrst_delay 100
> adapter_nsrst_assert_width 100
>
> Note that I already adapted it to use your Atmel ICE Device S/N.
>
> I just use:
>
> $ sudo openocd -f openocd.cfg
>
> > Reflections from a couple of months ago: On Ubuntu 22.04.3 LTS (the one
> I'm
> > running on this machine), I wasn't able to get the AVR32DEV1 OR Mizar32
> to
> > show
> > up on /dev as an ACM device - like it normally would.
> >
> > I read [2]. It wasn't very helpful in my case. Could the problem with ICE
> > be
> > about [2]? I would assume that they are somehow connected. Alan, have you
> > seen
> > this before?
> >
> > Just thoughts: I wanted to seek your opinion:
> >
> > 1) Alan, which GNU/Linux distro do you use? I am willing to move to
> > another/
> > switch GNU/Linux distribution if that is what it takes to solve the Atmel
> > ICE
> > problem - OR just the debug problem in general on GNU/Linux for AVR32 on
> > NuttX.
> >
>
> Ubuntu, like you are using.
>
> > 2) Just as an example: to inform you of my approach to a similar
> problem: I
> > hacked RT-Thread recently for the Mizar32 platform. I had build problems
> > with
> > it as well.
> > I worked with Microchip Studio for the entirety of the hack. To get
> things
> > to
> > work (debug, see if the chip boots at all, hard-faults), I bypassed the
> > (scons) build system and moved only what was necessary into Microchip
> > Studio.
> > Just C files and the toolchain configuration. Simply minimal.
> >
>
> Yes, they are most focused on IDE integration, NuttX is mostly
> standalone and the integration to people/companies willing to do it. I
> 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.
>
> > Assuming I keep the bare minimum requirement - for example UART, GPIO for
> > debug and the boilerplate (interrupts, exceptions, context switching,
> stack
> > for example) for NuttX to boot, is there a list of files I can move into
> > Microchip Studio? i.e. without going to Make OR CMake. No file system,
> mkfs
> > OR
> > other luxuries. Just wondering: Can I get CMake OR Make to list the files
> > it
> > is about to compile? i.e. given its target BSP.
> >
>
> 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.
>
> > 3) Can I try this hack with an older version of NuttX? I would assume an
> > older
> > (yet stable) version of NuttX still supports AVR32. Assuming I get the
> bare
> > minimum port to work with Microchip Studio for avr32dev1 OR Mizar32, I am
> > sure
> > there's a way (with git perhaps) to "sort of" cherry-pick the newer
> awesome
> > features of NuttX. OR would this approach be tricky?
> >
>
> 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.
>
> > I am yet to connect the FTDI dongle to see if I can see nsh. I will write
> > back
> > in an hour OR so.
> >
>
> 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.
>
> Best Regards,
>
> Alan
>
> > References:
> > [1]:
> >
> https://www.omzlo.com/articles/programming-samd21-using-atmel-ice-with-openocd
> > [2]: https://askubuntu
> > .com/questions/1410062/installed-arduino-cant-find-dev-usb0-or-dev-acm0
> >
> >
> >
> > On Sun, 19 Nov 2023 at 11:57, Raman Gopalan <ramangopa...@gmail.com>
> wrote:
> >
> >>
> >> Dear Alan, Dear Gregory, Greetings!
> >>
> >> Hello Kevin and Zou Boan!
> >>
> >> Many thanks for your suggestions. I will write in detail in a bit but
> >> before, I was too excited about Alan's suggestion.
> >>
> >> > Other option could be extend the CMake support to AVR32 boards.
> >>
> >> I quickly glanced through boards/arm/stm32 to see how the CMake files
> >> work. I put in place the CMakeLists files (similar to stm32f103, Blue
> >> Pill) for avr32dev1.
> >>
> >> I then ran cmake seeking help from the instructions here [1]. It
> >> initially asked me to pip install kconfiglib. Here's the volley I had
> >> with the Cygwin terminal.
> >>
> >> raman@foobar ~/nuttxspace/nuttx
> >> $ cmake -B build -DBOARD_CONFIG=avr32dev1:nsh -GNinja
> >> CMake Error at CMakeLists.txt:82 (message):
> >>   Kconfig environment depends on kconfiglib, Please install:
> >>
> >>     $ pip install kconfiglib
> >>
> >>
> >> -- Configuring incomplete, errors occurred!
> >>
> >> raman@foobar ~/nuttxspace/nuttx
> >> $ pip install kconfiglib
> >> Collecting kconfiglib
> >>   Using cached kconfiglib-14.1.0-py2.py3-none-any.whl (145 kB)
> >> Installing collected packages: kconfiglib
> >> Successfully installed kconfiglib-14.1.0
> >>
> >> Post this, I ran into another CMake error:
> >>
> >> raman@foobar ~/nuttxspace/nuttx
> >> $ cmake -B build -DBOARD_CONFIG=avr32dev1:nsh -GNinja
> >> -- Initializing NuttX
> >> CMake Warning at CMakeLists.txt:348 (message):
> >>   Kconfig Configuration Error:
> >> C:\Users\raman\anaconda3\Scripts\olddefconfig:
> >>   arch/Kconfig:252:
> >> '/home/raman/nuttxspace/nuttx/build/arch/dummy/Kconfig'
> >>   not found (in 'source "$BINDIR/arch/dummy/Kconfig"').  Check that
> >>   environment variables are set correctly (e.g.  $srctree, which is
> unset
> >> or
> >>   blank).  Also note that unset environment variables expand to the
> empty
> >>   string.
> >>
> >>
> >> CMake Error at CMakeLists.txt:353 (message):
> >>   Failed to initialize Kconfig configuration:
> >>
> >>
> >> -- Configuring incomplete, errors occurred!
> >>
> >> I initially wanted to check if the case is the same for other
> >> targets. CMake throws the same response for stm32f103-minimum too. I
> >> checked what the programs olddefconfig and defconfig did. Simply
> >> invoking the programs olddefconfig.exe (OR defconfig) echo this for a
> >> response:
> >>
> >> raman@foobar ~/nuttxspace/nuttx
> >> $ oldconfig
> >> Kconfig:10: warning: APPSDIR has 'option env="APPSDIR"', but the
> >> environment variable APPSDIR is not set
> >> Kconfig:14: warning: APPSBINDIR has 'option env="APPSBINDIR"', but the
> >> environment variable APPSBINDIR is not set
> >> Kconfig:22: warning: BINDIR has 'option env="BINDIR"', but the
> >> environment
> >> variable BINDIR is not set
> >> Kconfig:278: warning: the 'modules' option is not supported. Let me know
> >> if this is a problem for you, as it wouldn't be that hard to implement.
> >> Note that modules are supported -- Kconfiglib just assumes the sy
> >> mbol name MODULES, like older versions of the C implementation did when
> >> 'option modules' wasn't used.
> >> C:\Users\raman\anaconda3\Scripts\oldconfig: arch/Kconfig:252:
> >> '$BINDIR/arch/dummy/Kconfig' not found (in 'source
> >> "$BINDIR/arch/dummy/Kconfig"'). Check that environment variables are set
> >> correctly (e.g. $srctree
> >> , which is unset or blank). Also note that unset environment variables
> >> expand to the empty string.
> >>
> >> Perhaps I am missing yet another terminal configuration? I will write
> >> back in a couple of hours with the results of the minicom session with
> >> AVR32DEV1.
> >>
> >> Many thanks.
> >>
> >> References:
> >> [1]:
> https://nuttx.apache.org/docs/latest/quickstart/compiling_cmake.html
> >>
> >>
> >> On Sun, 19 Nov 2023 at 04:03, Alan C. Assis <acas...@gmail.com> wrote:
> >>
> >>> Hi Raman,
> >>>
> >>> I'm CC Kevin Liu, he integrated NuttX into Microchip Studio in the
> >>> past (although I thing he used the "make export" and imported the
> >>> library on it).
> >>>
> >>> On 11/18/23, Raman Gopalan <ramangopa...@gmail.com> wrote:
> >>> > Dear Alan, Greetings!
> >>> >
> >>> > Many thanks for your message. I am sorry about the slight delay in
> >>> > response.
> >>> >
> >>>
> >>> No problem, great to see you are trying to find a way!
> >>>
> >>> >> Thank you for reviving this discussing (I'm CC NuttX mailing list
> >>> >> because it could interest one person or two).
> >>> >
> >>> > Perfect!
> >>> >
> >>> >> $ ./tools/configure.sh avr32dev1:nsh
> >>> >
> >>> > I encountered the same problems you mention with the GNU/Linux build
> >>> > last week. I remember checking the Generate Debug Symbols options too
> >>> > on menuconfig. The avr32-gcc for GNU/Linux was able to generate the
> >>> > elf file. No problem at all.
> >>> >
> >>>
> >>> Maybe we will need a more up to date avr32-gcc version to compile
> >>> without those issues.
> >>>
> >>> >>> I wasn't sure if I had missed any references while mapping the
> >>> >>> source files. I can't trigger a breakpoint yet with this approach.
> >>> >
> >>> > I took the elf file onto the Windows machine to see if I can debug
> the
> >>> > code using Microchip Studio. File -> Open -> Open Object File For
> >>> > Debugging. Post the loading of the elf, I had to map the location of
> >>> > the build files.
> >>> >
> >>>
> >>> Some years ago I used ASF (Atmel Studio Framework) to compile a code
> >>> with debug symbols that I was able to debug on Linux (oposite
> >>> direction you want), but to get the ELF binary working on Linux I had
> >>> to replace the "C:\blablabla\AtmelStudioFramework\path" with something
> >>> like "/home/alan/longpathmatchingwindowspath/" and put the source
> >>> files on that long directory name. Then GDB was able to find it.
> >>>
> >>> Maybe you need to do something similar to let the GDB on Windows IDE
> >>> to find the source files.
> >>>
> >>> > I replicated the NuttX codebase on Windows and for every Linux (NuttX
> >>> > C file) path the elf reported, I replaced it with the local Windows
> >>> > path to check if the debug session works. But still, no luck. I think
> >>> > this still has something to do with the forward and backward path
> >>> > slashes.
> >>> >
> >>>
> >>> Did you match the path base directory lenght? If your build path on
> >>> Linux had 45 characters, the equivalent path on Windows needs to have
> >>> 45 chars as well, otherwise it will fail.
> >>>
> >>> >> I don't use Windows, but yes I think the issue is related to
> >>> >> Unix/Windows directories delimitator: "\" vs "/", etc.  I think
> >>> >> there is some configuration on Cygwin to improve Linux/Unix
> >>> >> compatibility.
> >>> >
> >>> > Understand, Alan.
> >>> >
> >>> > I did explore a bit further. First, I invoked make with V=1. This was
> >>> > very helpful. I tried to check where the build process broke. The
> >>> > build doesn't proceed after the invocation of mkwindeps.sh.
> >>> > Specifically, this line:
> >>> >
> >>> > ${MKDEPS} ${DEBUG} --winpath $* > ${TMPFILE} || { echo "# ERROR:
> >>> > mkdeps.exe failed"; exit 1; }
> >>> >
> >>> > It writes "mkdeps.exe failed" into the TMP file. I configured the
> >>> > build with the Cygwin flag:
> >>> >
> >>>
> >>> Maybe someone with more Windows/Cygwin background could help!
> >>>
> >>> > $ make distclean
> >>> > $ ./tools/configure.sh -c avr32dev1:nsh
> >>> >
> >>> > My experience with Cygwin is that it is very slow. It takes too long
> >>> > to even distclean. Because it took too long, I decided to put this
> >>> > approach on the back burner for now.
> >>> >
> >>>
> >>> Yes, maybe as an alternative we could try to get WSL or WSL2 working
> >>> to build the AVR32 boards.
> >>>
> >>> Other option could be extend the CMake support to AVR32 boards.
> >>>
> >>> > I drew inspiration from your very helpful video tutorial on
> >>> > "Code::Blocks IDE integration to compile and debug NuttX". I tried to
> >>> > check if I can import NuttX into Microchip Studio post the BSP
> >>> > configure.sh invocation.
> >>> >
> >>> > I waited for a significantly long time (on a reasonably fast work
> >>> > machine) before Microchip Studio was able to import the codebase. I
> >>> > configured the project to use the "external" Makefile. The build
> fails
> >>> > with the following output.
> >>> >
> >>> > ------ Build started: Project: avr32dev1_nuttx_sample, Configuration:
> >>> Debug
> >>> > AVR ------
> >>> > Build started.
> >>> > Project "avr32dev1_nuttx_sample.cproj" (default targets):
> >>> > Target "PreBuildEvent" skipped, due to false condition;
> >>> > ('$(PreBuildEvent)'!='') was evaluated as (''!='').
> >>> > Target "CoreBuild" in file "C:\Program Files
> >>> > (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project
> >>> > "C:\Users\raman\Documents\Atmel
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample.
> >>> > cproj" (target "Build" depends on it):
> >>> > Task "RunCompilerTask"
> >>> > Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
> >>> > C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe -C
> >>> > "C:\Users\raman\Documents\Atmel
> >>> > Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx" -f
> >>> > "Makefile" all
> >>> > make: Entering directory 'C:/Users/raman/Documents/Atmel
> >>> > Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx'
> >>> > C:\Users\raman\Documents\Atmel
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Makefile.host(23,1):
> >>> > error: C:/Users/raman/Documents/Atmel: No such file or directory
> >>> > C:\Users\raman\Documents\Atmel
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Makefile.host(23,1):
> >>> > error:
> >>> >
> >>>
> Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx/tools/../tools/Config.mk:
> >>> > No such file or directory
> >>> > make: *** No rule to make target
> >>> >
> >>>
> 'Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx/tools/../tools/Config.mk'.
> >>> > Stop.
> >>> > C:\Users\raman\Documents\Atmel
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\tools\Win.mk(36,1):
> >>> > error: C:\Users\raman\Documents\Atmel: No such file or directory
> >>> > C:\Users\raman\Documents\Atmel
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\tools\Win.mk(36,1):
> >>> > error:
> >>> >
> >>>
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Make.defs:
> >>> > No such file or directory
> >>> > echo CONFIG_VERSION_STRING="0" > .version
> >>> > echo CONFIG_VERSION_MAJOR=0 >> .version
> >>> > echo CONFIG_VERSION_MINOR=0 >> .version
> >>> > echo CONFIG_VERSION_PATCH=0 >> .version
> >>> > echo CONFIG_VERSION_BUILD="0" >> .version
> >>> > echo CONFIG_VERSION_STRING="0" > .version
> >>> > echo CONFIG_VERSION_MAJOR=0 >> .version
> >>> > echo CONFIG_VERSION_MINOR=0 >> .version
> >>> > echo CONFIG_VERSION_PATCH=0 >> .version
> >>> > echo CONFIG_VERSION_BUILD="0" >> .version
> >>> > make: *** No rule to make target
> >>> >
> >>>
> 'Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Make.defs'.
> >>> > Stop.
> >>> > make: Leaving directory 'C:/Users/raman/Documents/Atmel
> >>> > Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx'
> >>> > Done executing task "RunCompilerTask" -- FAILED.
> >>> > Done building target "CoreBuild" in project
> >>> "avr32dev1_nuttx_sample.cproj"
> >>> > -- FAILED.
> >>> > Done building project "avr32dev1_nuttx_sample.cproj" -- FAILED.
> >>> >
> >>> > Build FAILED.
> >>> > ========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped
> >>> ==========
> >>> >
> >>> > I am not really sure why Makefile.host can't see the entire
> >>> > path. Looking at the build output, it doesn't parse "Atmel Studio"
> >>> > correctly. It just picks up "Studio" instead. I visited Win.mk to
> >>> > check if the TOPDIR path is valid. It is. I wrote some debug
> >>> > statements within Win.mk to confirm.
> >>> >
> >>>
> >>> Maybe because the space in the name "Atmel Studio", do you think it is
> >>> possible to install it using a simple name? Many just ASF.
> >>>
> >>> > I am not sure if the following line is the culprit:
> >>> >
> >>> > DUMMY := ${shell $(MAKE) -C tools -f Makefile.host incdir \
> >>> >           INCDIR="${TOPDIR}\tools\incdir.bat"}
> >>> >
> >>> > Has anyone seen this before? Can you please give me a few tips to
> >>> > tackle this problem?
> >>> >
> >>>
> >>> No, maybe Greg or Zou Boan who were using Windows + Cygwin in the past.
> >>>
> >>> >> BTW, if you saw the LED turned ON, it means that probably the NSH is
> >>> >> starting (otherwise you should see the LED blinking).
> >>> >
> >>> > Understand Alan. The LEDs are lit. I will confirm if I can see the
> >>> > shell. I need to hook up a couple of jumper wires. I will certainly
> >>> > report my findings.
> >>> >
> >>>
> >>> Yes, please verify which pins are used as serial console and try to
> >>> use teraterm or other terminal to see the console.
> >>>
> >>> >> Do you think it is possible to gdb OpenOCD + GDB working for this
> >>> >> MCU?
> >>> >
> >>> > I haven't tried OpenOCD with AVR32 yet. I must explore. I understand
> >>> > this approach will be ideal for NuttX.
> >>> >
> >>>
> >>> I think if we get OpenOCD working it will be easier to debug.
> >>>
> >>> > Have a great weekend! Regards,
> >>> >
> >>>
> >>> Thank you, have a great weekend too!
> >>>
> >>> Best Regards,
> >>>
> >>> Alan
> >>>
> >>> >
> >>> > On Wed, 15 Nov 2023 at 03:40, Alan C. Assis <acas...@gmail.com>
> wrote:
> >>> >
> >>> >> Hi Raman,
> >>> >>
> >>> >> Thank you for reviving this discussing (I'm CC NuttX mailing list
> >>> >> because it could interest one person or two).
> >>> >>
> >>> >> On 11/14/23, Raman Gopalan <ramangopa...@gmail.com> wrote:
> >>> >> > Dear Alan, Greetings!
> >>> >> >
> >>> >> > I trust you're doing so well. I am so sorry about the long pause.
> I
> >>> >> > revisited NuttX again a couple of days ago. Many things have
> >>> >> > changed
> >>> >> > in the codebase. I had much trouble with AVR32 - and specifically,
> >>> >> > Mizar32 OR MCUZone's development kit in the context of NuttX. I
> >>> >> > will
> >>> >> > list my thoughts.
> >>> >> >
> >>> >> >   1) Initially, I tried GNU/Linux (Ubuntu - the latest); With the
> >>> >> > GNU
> >>> >> >   box, I changed parts of the build to a point where it compiles
> >>> >> >   without errors for AVR32. I had to transfer the built elf onto
> my
> >>> >> >   Windows machine to program the target with Atmel ICE. I am using
> >>> >> >   Microchip Studio.
> >>> >> >
> >>> >>
> >>> >> Nice, I duplicated it here and confirmed it "works"
> >>> >>
> >>> >> I cloned your repo [2] and copied it to /opt/avr32 and setup my PATH
> >>> with
> >>> >> it.
> >>> >>
> >>> >> Then I run:
> >>> >>
> >>> >> $ ./tools/configure.sh avr32dev1:nsh
> >>> >>
> >>> >> And:
> >>> >>
> >>> >> $ make
> >>> >> Create version.h
> >>> >> LN: platform/board to /home/alan/nuttxspace/apps/platform/dummy
> >>> >> Register: nsh
> >>> >> Register: sh
> >>> >> In file included from
> >>> >> /home/alan/nuttxspace/nuttx/include/nuttx/sched_note.h:36,
> >>> >>                  from
> >>> >> /home/alan/nuttxspace/nuttx/include/nuttx/trace.h:28,
> >>> >>                  from ./clock/clock_initialize.c:39:
> >>> >> /home/alan/nuttxspace/nuttx/include/nuttx/spinlock.h:36:23: error:
> >>> >> stdatomic.h: No such file or directory
> >>> >> ERROR: avr32-gcc failed: 1
> >>> >>        command: avr32-gcc -MT ./clock_initialize.o  -M '-fno-pic'
> >>> >> '-muse-rodata-section' '-fno-strict-aliasing' '-fomit-frame-pointer'
> >>> >> '-mpart=uc3b0256' '-isystem' '/home/alan/nuttxspace/nuttx/include'
> >>> >> '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> '/home/alan/nuttxspace/nuttx/sched' ./clock/clock_initialize.c
> >>> >> make[2]: *** [/home/alan/nuttxspace/nuttx/tools/Config.mk:228:
> >>> >> clock_initialize.ddc] Error 1
> >>> >> make[1]: *** [Makefile:70: .depend] Error 2
> >>> >> make: *** [tools/Unix.mk:611: pass2dep] Error 2
> >>> >>
> >>> >> Solution: disabled RW_SPINLOCK:
> >>> >> # CONFIG_RW_SPINLOCK is not set
> >>> >>
> >>> >> Alternatively if we get GCC >= 4.9 we could use stdatomic.h as well
> >>> >>
> >>> >>
> >>>
> -----------------------------------------------------------------------------------------------------------------
> >>> >>
> >>> >> $ make
> >>> >> LN: platform/board to /home/alan/nuttxspace/apps/platform/dummy
> >>> >> Register: nsh
> >>> >> Register: sh
> >>> >> CC:  clock/clock.c as: loadlocale.c:130: _nl_intern_locale_data:
> >>> >> Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof
> >>> >> (_nl_value_type_LC_TIME[0]))' failed.
> >>> >> avr32-gcc: Internal error: Aborted (program as)
> >>> >> Please submit a full bug report.
> >>> >> See <http://www.atmel.com/avr> for instructions.
> >>> >> make[1]: *** [Makefile:60: clock.o] Error 1
> >>> >> make: *** [tools/LibTargets.mk:65: sched/libsched.a] Error 2
> >>> >>
> >>> >> Solution: export LC_ALL=C
> >>> >>
> >>> >>
> >>>
> -----------------------------------------------------------------------------------------------------------------
> >>> >>
> >>> >> $ make
> >>> >> CC:  assert/lib_assert.c cc1: error: unrecognized command line
> option
> >>> >> "-fno-lto"
> >>> >> make[1]: *** [Makefile:153: bin/lib_assert.o] Error 1
> >>> >> make: *** [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2
> >>> >>
> >>> >> Solution: edited libs/libc/assert/Make.defs and removed no-lto
> >>> >>
> >>> >>
> >>>
> -----------------------------------------------------------------------------------------------------------------
> >>> >>
> >>> >> $ make
> >>> >> Create version.h
> >>> >> CC:  stdlib/lib_strtold.c In file included from
> >>> >>
> >>> >>
> >>>
> /opt/avr32/bin/../lib/gcc/avr32/4.4.7/../../../../avr32/include/sys/reent.h:14,
> >>> >>                  from
> >>> >>
> >>>
> /opt/avr32/bin/../lib/gcc/avr32/4.4.7/../../../../avr32/include/math.h:5,
> >>> >>                  from stdlib/lib_strtold.c:44:
> >>> >>
> >>> >>
> >>>
> /opt/avr32/bin/../lib/gcc/avr32/4.4.7/../../../../avr32/include/sys/_types.h:56:
> >>> >> error: conflicting types for '_ssize_t'
> >>> >> /home/alan/nuttxspace/nuttx/include/arch/avr32/types.h:82: note:
> >>> >> previous declaration of '_ssize_t' was here
> >>> >> make[1]: *** [Makefile:153: bin/lib_strtold.o] Error 1
> >>> >> make: *** [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2
> >>> >>
> >>> >>
> >>> >>
> >>>
> -----------------------------------------------------------------------------------------------------------------
> >>> >>
> >>> >> And finally:
> >>> >>
> >>> >> $ make
> >>> >> CC:  stdlib/lib_strtol.c stdlib/lib_strtol.c: In function 'strtol':
> >>> >> stdlib/lib_strtol.c:83: warning: integer overflow in expression
> >>> >> CC:  stdlib/lib_strtoll.c stdlib/lib_strtoll.c: In function
> >>> >> 'strtoll':
> >>> >> stdlib/lib_strtoll.c:86: warning: integer overflow in expression
> >>> >> CC:  avr32/avr_doirq.c avr32/avr_doirq.c: In function 'avr_doirq':
> >>> >> avr32/avr_doirq.c:117: warning: assignment discards qualifiers from
> >>> >> pointer target type
> >>> >> CC:  avr32_bringup.c avr32_bringup.c:54:4: warning: #warning "Not
> >>> >> Implemented"
> >>> >> LD: nuttx
> >>> >> CP: nuttx.hex
> >>> >>
> >>> >> >   The debug symbols (references) were missing. I had to map them
> in
> >>> >> >   Microchip Studio. So painful. The LEDs on the MCUZone's AVR32
> >>> >> >   (at32uc3b0256) light up but I can't figure out what is
> happening.
> >>> >> > I
> >>> >> >   wasn't sure if I had missed any references while mapping the
> >>> >> > source
> >>> >> >   files. I can't trigger a breakpoint yet with this approach.
> >>> >> >
> >>> >>
> >>> >> Oh, I think you missed to enable CONFIG_DEBUG_SYMBOLS at menuconfig:
> >>> >>
> >>> >> Build Setup  --->
> >>> >>     Debug Options  --->
> >>> >>         [*] Generate Debug Symbols
> >>> >>
> >>> >> Then I can see the debug_info are included:
> >>> >>
> >>> >> $ file nuttx
> >>> >> nuttx: ELF 32-bit MSB executable, Atmel 32-bit family, version 1
> >>> >> (SYSV), statically linked, with debug_info, not stripped
> >>> >>
> >>> >>
> >>> >> >   2) I tried WSL for Windows. No luck. The problems take me back
> to
> >>> >> >   many issues on WSL's github. In the context of AVR32, I won't
> WSL
> >>> >> >   anymore. It is rather tricky to work with WSL in the context of
> >>> >> >   AVR32. I thought this path was less efficient. Win-10 + WSL-2.
> >>> >> >   It works great with STM32 targets though. :)
> >>> >> >
> >>> >>
> >>> >> Yes, I used WSL in the past with STM32, ESP32 and XMC4, etc and it
> >>> >> worked.
> >>> >>
> >>> >> >   3) I finally got Cygwin; It is so pleasant! I am so happy with
> >>> >> > this
> >>> >> >   choice. I had to `Make' kconfig-frontend. I sought help from
> >>> >> >   [1]. It was very helpful. All perfect! :) But, I had a few more
> >>> >> >   problems: Can you please help here? I am just pasting the logs
> >>> >> > from
> >>> >> >   the Cygwin session from my machine:
> >>> >> >
> >>> >> > raman@foobar ~/nuttxspace/nuttx
> >>> >> > $ ./tools/configure.sh -c avr32dev1:nsh
> >>> >> >   Copy files
> >>> >> >   Select CONFIG_HOST_WINDOWS=y
> >>> >> >   Select CONFIG_WINDOWS_CYGWIN=y
> >>> >> >   Refreshing...
> >>> >> > CP: arch/dummy/Kconfig to
> >>> >> > /home/raman/nuttxspace/nuttx/arch/dummy/dummy_kconfig
> >>> >> > CP: boards/dummy/Kconfig to
> >>> >> > /home/raman/nuttxspace/nuttx/boards/dummy/dummy_kconfig
> >>> >> > LN: platform/board to /home/raman/nuttxspace/apps/platform/dummy
> >>> >> > LN: include/arch to arch/avr/include
> >>> >> > LN: include/arch/board to
> >>> >> > /home/raman/nuttxspace/nuttx/boards/avr/at32uc3/avr32dev1/include
> >>> >> > LN: drivers/platform to /home/raman/nuttxspace/nuttx/drivers/dummy
> >>> >> > LN: include/arch/chip to
> >>> >> > /home/raman/nuttxspace/nuttx/arch/avr/include/at32uc3
> >>> >> > LN: arch/avr/src/chip to
> >>> >> /home/raman/nuttxspace/nuttx/arch/avr/src/at32uc3
> >>> >> > LN: arch/avr/src/board to
> >>> >> > /home/raman/nuttxspace/nuttx/boards/avr/at32uc3/avr32dev1/src
> >>> >> > #
> >>> >> > # configuration written to .config
> >>> >> > #
> >>> >> >
> >>> >> > raman@foobar ~/nuttxspace/nuttx
> >>> >> > $ make
> >>> >> > Create version.h
> >>> >> > LN: platform/board to /home/raman/nuttxspace/apps/platform/dummy
> >>> >> > Register: nsh
> >>> >> > Register: sh
> >>> >> > .\mkfatfs.c:25:26: error: nuttx/config.h: No such file or
> directory
> >>> >> > .\mkfatfs.c:27:23: error: sys/ioctl.h: No such file or directory
> >>> >> > .\mkfatfs.c:32:19: error: debug.h: No such file or directory
> >>> >> > .\mkfatfs.c:36:25: error: nuttx/fs/fs.h: No such file or directory
> >>> >> > .\mkfatfs.c:38:29: error: fsutils/mkfatfs.h: No such file or
> >>> directory
> >>> >> > In file included from .\mkfatfs.c:39:
> >>> >> > .\/fat32.h:33:23: error: semaphore.h: No such file or directory
> >>> >> > .\/fat32.h:36:27: error: nuttx/kmalloc.h: No such file or
> directory
> >>> >> > ERROR: avr32-gcc failed: 1
> >>> >> >        command: avr32-gcc -MT
> >>> >> > .\\mkfatfs.c.home.raman.nuttxspace.apps.fsutils.mkfatfs.o  -M
> >>> >> > '-fno-pic'
> >>> >> > '-muse-rodata-section' '-fno-strict-aliasing'
> >>> >> > '-fomit-frame-pointer'
> >>> >> > '-mpart=uc3b0256' '-isystem'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/include'
> >>> >> > '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/apps/include'
> >>> >> > .\\mkfatfs.c
> >>> >> > .\nsh_init.c:25:26: error: nuttx/config.h: No such file or
> >>> >> > directory
> >>> >> > .\nsh_init.c:27:26: error: sys/boardctl.h: No such file or
> >>> >> > directory
> >>> >> > .\nsh_init.c:28:26: error: nuttx/symtab.h: No such file or
> >>> >> > directory
> >>> >> > .\nsh_init.c:30:29: error: system/readline.h: No such file or
> >>> directory
> >>> >> > .\nsh_init.c:31:27: error: nshlib/nshlib.h: No such file or
> >>> >> > directory
> >>> >> > In file included from .\nsh_init.c:33:
> >>> >> > .\/nsh.h:41:36: error: nuttx/usb/usbdev_trace.h: No such file or
> >>> >> directory
> >>> >> > .\/nsh.h:122:4: error: #error "No NSH front end defined"
> >>> >> > In file included from .\nsh_init.c:34:
> >>> >> > .\/nsh_console.h:36:25: error: nuttx/queue.h: No such file or
> >>> directory
> >>> >> > ERROR: avr32-gcc failed: 1
> >>> >> >        command: avr32-gcc -MT
> >>> >> > .\\nsh_init.c.home.raman.nuttxspace.apps.nshlib.o  -M '-fno-pic'
> >>> >> > '-muse-rodata-section' '-fno-strict-aliasing'
> >>> >> > '-fomit-frame-pointer'
> >>> >> > '-mpart=uc3b0256' '-isystem'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/include'
> >>> >> > '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/apps/include'
> >>> >> > .\\nsh_init.c
> >>> >> > .\nsh_main.c:25:26: error: nuttx/config.h: No such file or
> >>> >> > directory
> >>> >> > .\nsh_main.c:31:26: error: sys/boardctl.h: No such file or
> >>> >> > directory
> >>> >> > .\nsh_main.c:35:27: error: nshlib/nshlib.h: No such file or
> >>> >> > directory
> >>> >> > ERROR: avr32-gcc failed: 1
> >>> >> >        command: avr32-gcc -MT
> >>> >> > .\\nsh_main.c.home.raman.nuttxspace.apps.system.nsh.o  -M
> >>> >> > '-fno-pic'
> >>> >> > '-muse-rodata-section' '-fno-strict-aliasing'
> >>> >> > '-fomit-frame-pointer'
> >>> >> > '-mpart=uc3b0256' '-isystem'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/include'
> >>> >> > '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/apps/include'
> >>> >> > .\\nsh_main.c
> >>> >> > .\readline.c:25:26: error: nuttx/config.h: No such file or
> >>> >> > directory
> >>> >> > .\readline.c:30:29: error: system/readline.h: No such file or
> >>> directory
> >>> >> > ERROR: avr32-gcc failed: 1
> >>> >> >        command: avr32-gcc -MT
> >>> >> > .\\readline.c.home.raman.nuttxspace.apps.system.readline.o  -M
> >>> >> > '-fno-pic'
> >>> >> > '-muse-rodata-section' '-fno-strict-aliasing'
> >>> >> > '-fomit-frame-pointer'
> >>> >> > '-mpart=uc3b0256' '-isystem'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/include'
> >>> >> > '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/apps/include'
> >>> >> > .\\readline.c
> >>> >> > .\clock/clock_gettime.c:25:26: error: nuttx/config.h: No such file
> >>> >> > or
> >>> >> > directory
> >>> >> > .\clock/clock_gettime.c:31:19: error: debug.h: No such file or
> >>> >> > directory
> >>> >> > .\clock/clock_gettime.c:33:24: error: nuttx/arch.h: No such file
> or
> >>> >> > directory
> >>> >> > .\clock/clock_gettime.c:34:25: error: nuttx/sched.h: No such file
> >>> >> > or
> >>> >> > directory
> >>> >> > .\clock/clock_gettime.c:35:28: error: nuttx/spinlock.h: No such
> >>> >> > file
> >>> or
> >>> >> > directory
> >>> >> > .\clock/clock_gettime.c:37:25: error: clock/clock.h: No such file
> >>> >> > or
> >>> >> > directory
> >>> >> > ERROR: avr32-gcc failed: 1
> >>> >> >        command: avr32-gcc -MT .\\clock_gettime.o  -M '-fno-pic'
> >>> >> > '-muse-rodata-section' '-fno-strict-aliasing'
> >>> >> > '-fomit-frame-pointer'
> >>> >> > '-mpart=uc3b0256' '-isystem'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/include'
> >>> >> > '-D__NuttX__' '-DNDEBUG' '-D__KERNEL__' '-pipe' '-I'
> >>> >> >
> >>> >>
> >>>
> 'C:\\cygwin64\\home\\raman\\nuttxspace\\nuttx\\X/home/raman/nuttxspace/nuttx/sched'
> >>> >> > .\\clock/clock_gettime.c
> >>> >> > make[2]: *** [/home/raman/nuttxspace/nuttx/tools/Config.mk:228:
> >>> >> > clock_gettime.ddc] Error 1
> >>> >> > make[1]: *** [Makefile:70: .depend] Error 2
> >>> >> > make: *** [tools/Unix.mk:611: pass2dep] Error 2
> >>> >> >
> >>> >> >   Have you seen this before? Can you please give me your thoughts
> >>> >> > on
> >>> >> >   this? Has it to do with Unix/Windows paths?
> >>> >> >
> >>> >>
> >>> >> I don't use Windows, but yes I think the issue is related to
> >>> >> Unix/Windows directories delimitator: "\" vs "/", etc.
> >>> >> I think there is some configuration on Cygwin to improve Linux/Unix
> >>> >> compatibility.
> >>> >>
> >>> >> >   4) About support for AVR32 in the context of NuttX, I would
> >>> >> > really
> >>> >> >   love to help. I have the 32-bit (and 64-bit) toolchain ready for
> >>> >> >   CI. How may I help further? For now, I have put them here [2]. I
> >>> >> >   have tried this toolchain with eLua and RT-Thread.
> >>> >> >
> >>> >>
> >>> >> I think adding the AVR32 support to CI will be very good to keep the
> >>> >> platform supported in the future.
> >>> >>
> >>> >> BTW, if you saw the LED turned ON, it means that probably the NSH is
> >>> >> starting (otherwise you should see the LED blinking).
> >>> >>
> >>> >> Do you think it is possible to gdb OpenOCD + GDB working for this
> >>> >> MCU?
> >>> >>
> >>> >> BR,
> >>> >>
> >>> >> Alan
> >>> >>
> >>> >
> >>>
> >>
> >
>

Reply via email to