support site difficulties

I can see that there are others that have had problems with finding SIMPLE information from this site....
I would like to get off on a better footing.

Here is the issue

1) Downloading and setting up the IDE (or IDEs as the case may be) is not logical nor is there any cohesive documentation on the procedure.
       Seems that I have had to jump through many different documents and sites to find the procedures and then guess the order of operation between them
       it has taken me 5 days just to get the "VS code" IDE to start and detect the nRF52833-DK.

2) What I need now is CLEAR and Concise instructions in using the IDK / Dev Tool to connect to an external target.
      i have found the connection diagram for debug out P19 and P20. I am using P20    - 
      should SW6 be set to nRF only or DEFAULT
      SW10 - correct setting I would like to power the external target from the DK - currently in Vext and 3.0 volts is on VDD-nRF on P19 - this is also shorted to VTG

3) I do see a connection in Visual Studio Code IDE with SW6 in DEFAULT mode
       How can I tell the part type (nRF52833) is the target
       If my external target is the nRF52840 - what do I need to do to validate I am correctly connected

4) I also downloaded the Seggar IDE but have no idea how to begin using
     What compiler to use
    how to get that compiler up and running
    Seems to need purchasing a licence
    I do not see any SIMPLE instructions on how to get the, as advertised, Free stuff running for your products.

Please note that I am basically a hardware design engineer with over 35 years experience in circuit design and PCB layout, Contract Manufacturing and regulatory experience. I am not an expert firmware developer but I am not a spring chicken either. I have to say that this product line is one of the most difficult to get started in that I have come across in a long time. NXP products come in a close second.

Thank you for your attention in this matter
D.

Parents
  • Things are really bad with nRF Connect for VS Code when you are interested in using the tool to view and correct warnings in C code. To see this, simply remove the -Wno-pointer-sign flag from the appropriate CMake file in zephyr (compiler_flags.cmake). That will give you some files that have warnings. If you do things correctly and the stars are aligned, you will see the warnings in those files after editing and regenerating the build configuration. Now fix an error in the editor window and try to get the yellow underline to go away. Oh yeah, and if you right click and Run Code Analysis on File, you will semi-permanently install the clang-tidy bugs dealing with system header files. At least until you re-edit the build configuration and regenerate the build. Whoever designed this monster should have located people who have done Eclipse and asked for instructions how to test an IDE before releasing it to the world. Yech!!!

  • Let me modify my statements to be more precise. Also, my apologies that I am focused on issues that occur AFTER initial VS Code installation and BEFORE trying to connect to devices. The situation with browsing code and fixing C code warnings: to my surprise, it pretty much "just works" on the Mac. On Linux, this is almost the case, but here the setting or not setting of warning flag -Wno-pointer-sign is ignored: warnings are shown regardless (and can be silenced by right clicking and selecting an appropriate option). It looks like the clang-tidy defaults override the -W flags on Linux. This is independent of whether you have only gcc installed or both clang and gcc on your Linux machine. And then there is Windows. On Windows, the product (Nordic extensions plus other extensions plus base VS Code) is just a large pile of horse doo doo, at this time. That's where one finds the problems I mention above. I try to speculate that it works on Mac because gcc and clang are kind of closely coupled on Mac. For example, if I issue the command "gcc --version" I see something about clang printed. On Linux this is not the case. On Windows, all I can say is that nobody ever did any serious, careful testing. That's bad for me as I like lounging around on the couch or even sitting on the bed with a laptop rather than sitting up straight at my desk to use my Linux desktop, and I only have one older Macbook Pro that I normally don't use too often. One other thing, it is often nice to enable clang-tidy to run automatically although that is not the default.

  • Hey there Burt,

    Thanks for the advice. I am not much of a soft/firmware guy so some of the details are above my pay grade so to speak.

    Anyway the problem appears to be more assembly related. We did some X-rays and found shorted balls under the part. So for my part the forensics is mostly over unless the replacement boards have problems.

    I am really beginning o warm up to Nordic support personnel and the help I have been getting.

    Thank you -
    Dante

Reply
  • Hey there Burt,

    Thanks for the advice. I am not much of a soft/firmware guy so some of the details are above my pay grade so to speak.

    Anyway the problem appears to be more assembly related. We did some X-rays and found shorted balls under the part. So for my part the forensics is mostly over unless the replacement boards have problems.

    I am really beginning o warm up to Nordic support personnel and the help I have been getting.

    Thank you -
    Dante

Children
No Data
Related