This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

actinius icarus only registers as ftdi serial device (vendorid 0403, productid 6015)

I just bought an actinius icarus board, and am trying to connect to it on linux (or windows),

The problem is that when I plug in the board in the usb, it will only appear as a ftdi serial port

lsusb mentions:

Bus 001 Device 029: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)

I was actually expecting jlink interfaces with sometthing like:

Bus ... Device ..: ID 1366:.... SEGGER 

The same happens when I check the port in a windows vm (and on another windows computer): no jlink ports are appearing under the COM ports.

Furthermore:

I can flash a prebuild app from the windows vm (but not from linux, as the device is not recognized), but only using mcuboot, so I don't see a way to change the mcuboot itself.

I  managed to build a few sample apps for the board and tried flashing them through the windows vm version of "actinius programmer", but none of them seems to work.

Any hints of where to start?

Parents
  • gnssr-dev said:
    Thanks, I think I'm starting to get the idea now

    Thanks a lot for your feedback!

    gnssr-dev said:
    so the device will only expose a jlink port after flashing an appropriate system through the jtag pins?

    Yes, that is correct.

    gnssr-dev said:

    Flashing a prebuilt image works (and the app works) through "actinius programmer" via windows VM. I still need to  figure out how to get this working in linux as nrfconnect doesn't recognize the board there.

    Is there a way to flash the prebuilt hex files from the command line in linux? Mcumgr seems to work in linux but I only have the hex versions of the prebuilt applications.

    Well, you can use the nRF Connect for Desktop on Linux as well. To do so, please download this AppImage, which you can run via a terminal like this:

    user@user-ubu:~$ chmod +x <path_to_image>/nrfconnect-3.10.0-x86_64.AppImage 
    user@user-ubu:~$ ./<path_to_image>/nrfconnect-3.10.0-x86_64.AppImage 

    You can then add the Actinius Programmer in the same way as you have done on Windows. I’m using an Ubuntu distribution myself and tried this. It appears to work fine :-)

    A second alternative would be to build an application in the nRF Connect SDK, as described in this chapter. I’m a little bit confused by the documentation myself, as it says:

    "An app_signed.hex file will be generated in your build folder. This is the application update and is compatible with MCUBoot. You can upload this file to your device."

    While on the other hand it points to the usage of mcumgr as following:

    mcumgr image upload <path to app_update.bin> --conntype=serial –connstring='dev=<port>,baud=<baud_rate>'

    But anyway, the app_update.bin is available after building an application with MCUBoot enabled in the nRF Connect SDK.

    : Do you have any comments/input here?

    Regards,

    Markus

Reply
  • gnssr-dev said:
    Thanks, I think I'm starting to get the idea now

    Thanks a lot for your feedback!

    gnssr-dev said:
    so the device will only expose a jlink port after flashing an appropriate system through the jtag pins?

    Yes, that is correct.

    gnssr-dev said:

    Flashing a prebuilt image works (and the app works) through "actinius programmer" via windows VM. I still need to  figure out how to get this working in linux as nrfconnect doesn't recognize the board there.

    Is there a way to flash the prebuilt hex files from the command line in linux? Mcumgr seems to work in linux but I only have the hex versions of the prebuilt applications.

    Well, you can use the nRF Connect for Desktop on Linux as well. To do so, please download this AppImage, which you can run via a terminal like this:

    user@user-ubu:~$ chmod +x <path_to_image>/nrfconnect-3.10.0-x86_64.AppImage 
    user@user-ubu:~$ ./<path_to_image>/nrfconnect-3.10.0-x86_64.AppImage 

    You can then add the Actinius Programmer in the same way as you have done on Windows. I’m using an Ubuntu distribution myself and tried this. It appears to work fine :-)

    A second alternative would be to build an application in the nRF Connect SDK, as described in this chapter. I’m a little bit confused by the documentation myself, as it says:

    "An app_signed.hex file will be generated in your build folder. This is the application update and is compatible with MCUBoot. You can upload this file to your device."

    While on the other hand it points to the usage of mcumgr as following:

    mcumgr image upload <path to app_update.bin> --conntype=serial –connstring='dev=<port>,baud=<baud_rate>'

    But anyway, the app_update.bin is available after building an application with MCUBoot enabled in the nRF Connect SDK.

    : Do you have any comments/input here?

    Regards,

    Markus

Children
  • Update: I managed to build an app, have it flashed with mcumgr and it's now running as expected.

    For completeness sake: some things I learned

    I noticed that the hex file of the prebuilt images (downloaded with nrfconnect) had a different (smaller) offset (0xC000) compared to those of my own build (0x18200). So they were flashing but didn't start as they landed to far in the partition. I had to change

    (1): the partition setup as described here docs.actinius.com/.../zephyr

    (2) build with the non-secure target actinius_icarus_ns (so no space for the SPM is reserved before the app)

    (3) flash the app_update.bin with mcumgr

    Now it's working and I can start doing some actual coding!

    I still don't know why the device is not recognized in actinius programmer on my (Arch) linux. The hardware info strings can be seen from lshw, so maybe it's a permission problem of nrfconnect that it can't access this information. This is not a major problem though, as I now have workarounds.

    Thanks for your help.

Related