Dear All, >> I read [2]. It wasn't very helpful in my case. Could the problem with ICE be >> about [2]?
Sorry, just an observation: I just plugged-in my FTDI breakout. It works fine. So, I conclude [2] works fine. Here is the log of dmesg. [16504.718633] ftdi_sio 1-2.3:1.0: FTDI USB Serial Device converter detected [16504.718683] usb 1-2.3: Detected FT232R [16504.719438] usb 1-2.3: FTDI USB Serial Device converter now attached to ttyUSB0 [16510.470240] usb 1-2.2: new high-speed USB device number 16 using xhci_hcd [16510.571215] usb 1-2.2: New USB device found, idVendor=03eb, idProduct=2141, bcdDevice= 1.01 [16510.571233] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Not sure why not avr32dev1 OR Mizar32 yet. R On Sun, 19 Nov 2023 at 19:22, 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. > > 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. > > 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. > > 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. > > 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? > > I am yet to connect the FTDI dongle to see if I can see nsh. I will write > back > in an hour OR so. > > Highest regards, > > R > > 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 >>> >> >>> > >>> >>
