UCANS32K146-01 and KIT-UCANS32K146.

[iaingalloway]

Please ask questions about UCANS32K146 here.

[aka RDDRONE-UCANS32K146 CANNODE UAVCAN UAVCANNODE UCANS32K KIT-UCANS32K146 UCANS32K1SIC KIT-UCANS32K1SIC]

[Prince1]

Hi,

I recently bought UCANS32K1SIC kit to extract CAN messages from NXP RDdrone BMS772 using UAVCAN V1 as given in link below,

https://nxp.gitbook.io/rddrone-bms772/software-guide-nuttx/uavcan

The CAN port of UCAN device is connected to BMS and FTDI USB-TTL-3V3 cable shall be connected to UART port. There are two UART ports in UCANS32K1 board (P2 and P6). Can I use any of these two ports for SLCAN communication?

I tried with port P6 (connected to UART-TTL cable through DCD-LZ adapter), but the communication is not successful.

Also, is the UCANS32K1 evaluation board shipped ready to use or do we need to upload any software for it to work?

Please clarify.

Regards,

Prince

[Mike_Cruise]

Hi, 

We bought several UCANS32K1SIC EVM boards to test the max CAN speed (up to 8Mbps). (The board has TJA1463). Then we followed the EVM instructions to connect two of them, and tried to compile and download the SW from the example at https://nxp.gitbook.io/ucans32k1/s32k1-sdk/quick-start-demo . After downloading to node A and B successfully, but no traffic between the 2 nodes can be seen. If I probed the CAN P/N, no toggling. The green LED did not blink. Pushing the reset button did not help. Is this the correct FW example for this board? How to get them to show CAN traffic?

Thanks

Mike

[Iceme]

Hey,

the Board has already the UAVCAN v1, so cyphal right?

Is its also possible to use UAVCAN v0, so DroneCAN for it?

[Mike_Cruise]

When the boards come, they must be same. They will need to be configured as node A and B. Then CAN can be tested. How to do the configure with UAVCAN v0/1 or DroneCAN? Are there example projects? Thanks

[shiva_brane]

Hi , I recently brought this board for bare-metal programming. The documentation is very poor. I require assistance regarding 3 things.

1.I require access to page containing set of examples similar to this STMCubeF7 

2.How to power on the board via DCD-LZ-ADAPT+Jlink mini

3. print a simple hello world on ttl terminal.

[andrewstukey_mezmur]

In my case, I soldered header pins (2) to power the board while using the DCD-LZ Adapter (See image)  This will allow you to follow the flashing instructions.  Then once you've flashed the bootloader and firmware, you can serial connect with the FTDI cable, making sure you've installed the necessary (in my case, VCP) FTDI driver if you're on windows. 

The DCD-LZ adapter also incorporates the FTDI dupont connector pinout (if I remember correctly, it is the middle set of pins).  You need to use the adapter to connect in both cases, and in both cases, it seems you need to provide power externally.  The only case where you don't need external power is when you are connecting via CAN.

Afaik, recent versions of linux are installed with the driver included.  Not certain about MacOS.

[shiva_brane]

Hi ! How to power using CAN ? I am supplying power to one board and a CAN cable is connected between first and second board. I have also added jumper at P11 to acquire supply 5v from board. I am not able to get the second board turned on. I did measure the voltages at CAN it show 1.9v.

[coryjfowler]

I have not been able to find the kit anywhere and contacting NXP chat claims I can get it through the normal distributors even though NXP's product page lists absolutely no distributors for it.  I am still waiting for Mouser to contact me about it.

[iaingalloway]

@coryjfowler 

Let me see if I can help with this situation. I will contact you directly.

See the explanation below. 

Note we should have a resolution to this security classification problem soon, but it will still take a bit more time.

[maxe]

@iaingalloway @petervdperk 

Just in case you are not aware of this: I tried purchasing the UCANS32K146 over here in Germany and it was nearly impossible. None of the NXP distributors had the product available. I eventually managed to get hold of a kit, but only due to the amazing support of Eva L. (NXP tech support EMEA). It almost felt like NXP generally doesn't want to sell this product.

[iaingalloway]

Hello @maxe 
Thank you for your feedback. If you would allow me to explain the unusual situation we find ourselves in , it should be clearer why you currently experienced this issue.

NXP is very serious about and carefully complies with all global trade requirements. All items shipped need to include export control codes that represent the security classification of a product. The previous US administration surprised everyone with a new ruling. Now new circuit boards containing more than one "uncontrolled" security products need to submit for a new classification for the *board* itself. Previously you could use the chip security classification for the board classifications. This is even though the components on board already have classifications and are "uncontrolled" clear to ship worldwide.

As a result of this, there are long delays in getting this new classification code as many other companies find themselves in the same situation. We submitted our paperwork for this board (and similar boards) many months ago, and continue to follow-up to determine when the classification will be issued.
Meanwhile what this means is that boards cannot ship out of the USA without violating the rules. Boards made and warehoused outside the US are unencumbered.

There are several consequences to this new requirement that remain in effect until we get the new classification number back:
- very long delays in getting new classifications for boards

- boards needed to be fabricated and assembled outside the US in order to ship globally

- boards needed to be warehoused outside the US in order to ship globally

- distributors run the risk of accidentally holding/moving stock to a US warehouse that cannot be moved to their other locations globally.

As a result, distributors have not stocked this board yet, and each order needs to be managed manually in an ad-hoc manner. So a distributor will show no stock, but we would fulfill the order and ship to them as the request came in. I appreciate this is less than ideal.

We remain committed to the UCAN board and other new Mobile Robotics boards that may fall under these trade rules. This issue goes away when the new export code for the board is issued by the US government.

I hope this explains the current situation as to why you don't see stock at distribution for the UCAN board. Orders can still be taken by distribution and fulfilled. We will expedite any shipping on our end for these orders. 

[maxe]

Thanks a lot for this extensive answer. I didn't know any of that.

[petervdperk]

Hi Maxe,

It seems that gitbook link has been moved to this new url https://nxp.gitbook.io/ucans32k146/px4-autopilot/building-and-flashing-px4 

Furthermore the target name has been renamed from `make nxp_rddrone-uavcan146`, to `make nxp_ucans32k146_default`

We're still developing in the pr-uavcan-v1_bms_minimal branch so for testing please use that branch, we're working together with PX4 to get this into upstream as soon as possible.

[maxe]

@petervdperkJust a quick ping, in case you forgot about this

[maxe]

Thank you very much for your answer, @petervdperk ! This definitely helps.

And yes, I saw that you are actively working on the integration, I saw the PR in PX4's github repo. Hopefully this is gonna be resolved quite soon.

I have another question related to this. As I mentioned I want to control my servos/actuators with the board. Do you provide an example on how to that, too, or is it just the GPS that you provide? If you don't provide an example: What would I have to do to get it running with a servo? Would I "only" have to change the "canard_main.c" file in the uavcannode_gps_demo directory or what else would I have to do? Would you consider it somewhat easy to get this running (I got quite a bit of experience with C++, but not really any experience in the embedded domain....)?

EDIT: I just realized you actually are the guy that was explaining the whole thing in the video. So thanks for the talk! In this case I have another question to you. In the video you mentioning something about DS-015 not yet supporting GPS messages. I can't really find good information on the current state of DS-015, so can you tell me if they now do support GPS messages and even more importantly (for me) do they also support the messages that I would need to control a servo?

[petervdperk]

Hi Maxe,

You can control PWM on the UCANS32K146 through the NuttX PWM interface or the PX4 PWM interface.

An example for the PX4 interface is

pwm arm
pwm test -a -p 2000

Regarding the UAVCAN implementation in PX4, it's currently work-in-progress. Currently we're focusing on GPS as you pointed out by the uavcannode_gps_demo application. This application will be converted C++ as well, should be easily extendable to other peripherals such as Servo/ESC and more.

Regarding the protocol spec, there's none currently. Thus for development we use the internal PX4 uORB message structure for example for GPS we use the sensor_gps message (https://github.com/PX4/PX4-Autopilot/blob/master/msg/sensor_gps.msg)

[maxe]

I'm not sure if I understand you correctly. So I will try to express my question more precisely:

I want my servos to receive the MAIN flight control signals. I don't want to connect the servos directly by PWM to the FMU, because that would result in a lot of cables (as I have 6 Servos). What I want to do is to connect my servos to the PWM interface of UCANS32K146. Then I want to connect the CAN ports of my Pixhawk FMU to the CAN interface of UCANS32K146. Then I want to change the example code of uavcannode_gps_demo to output the MAIN flight controls as PWM signals to my servo. Does this work?

[petervdperk]

Yes, so the UCANS32K146 also runs PX4 software, more specifically the cannode variant not the flight control variant but it shares the same code base, this allows for re-use of code and easier integration into the PX4 platform, so that might be the confusing part.

But yes, you can control a servo from the UCANS32K146 by connecting them to the the "P12 RCM PWM out" port.

To output the MAIN flight controls as PWM signal to your servo, you've to modify both the uavcan_v1 application running on the FMU to expose the MAIN flight control channels over CAN, and modify the uavcannode_gps_demo to parse the data and control the PWM port.

Regarding UAVCAN itself, PX4 is giving a call today about the PX4 UAVCAN v0/v1 roadmap, you might want to join that. https://discuss.px4.io/t/hardware-call-uavcan-jan-26-2021/20575

[maxe]

Thanks a lot for your help and patience. In this case I'm definitely going to order the Dev Kit. Not least because of this great support.

And also thanks a lot for the hint on this call, I was completely unaware of this event even though I knew that UAVCAN v1 is a topic that is currently being discussed. I am curious for this talk and I am going to join it.

[iaingalloway]

I'd like to state this for the sake of clarity:

*AT THE MOMENT*
- UAVCANv1 is new and the device protocols are new to PX4

- PWM controls over UAVCANv1 to the UCAN board has not been implemented yet in a "turn key" manner

- The UCAN board itself does support PWM output, and since it also runs PX4 internally the NuttX/PX4 shell command "pwm test -c12 -p1500" can be easily used to demonstrate this.

- More software work is necessary to have an FMU send messages to a remote UCAN board to extend PWM outputs over CAN. It is one of the use cases being planned by the PX4 community overall.

- I will add that you don't *have* to use UAVCAN, and if you have the programming resources could leverage the code provided to quickly create a custom protocol or simple CAN messages. (3rd parties have implemented ARINC standards for example.)

-Check the date of this post. If you are reading this post in the future, this issue may be resolved in PX4 by now.