I have been converting a Panda II project to Panda III. I have been through a lot of simple name replacements, but have a couple of queries I cannot find the answers to in the documentation or the forums. I am hoping someone can point me to the answers.
When starting a CAN bus, I used to use the constructor with receiveBufferSize as a third argument due to the speed of the CAN buses I am on. 4.3 does not have the same option, but it does have a ReceiveBufferSize property now. Is this the same internal buffer?
In certain modes, I use the USB client interface for a serial port or to expose the SD card as USB MSC to a connected PC. However, I cannot find the equivalent of the Configuration.DebugInterface.Set command to let me redirect the debug interface to serial. Where is that for the Panda III? Does it still have the StartCDC_WithDebugging() option to let me debug it during development?
Has anyone tried in-field update with Panda III? I know the website says it is not supported but some of the earlier documentation had it listed (I can’t find it right now though). My Panda II update code is commented out for now, but I can try it once I get the rest all working well.
@ HalfGeek - ReceiveBufferSize is the same internal buffer. StartCDC_WithDebugging does not exist anymore in 4.3. To use CDC over the USB port you need to be in serial debug mode. IFU is not supported on the G80, which the FEZ Panda III is based on.
On Panda II, I used Configuration.DebugInterface to check and set the debug interface programmatically during development (as well as the MOD pin). Is there an equivalent of Configuration.DebugInterface, or can I only set the debug to serial via the MOD pin?
I have my application compiling and running on Panda III now. I2C display, buttons and SD card reading all working fine But, I am having teething troubles with CAN.
I am using the same code I used on Panda II, just converted to the new NETMF, so mainly just name changes. But, CAN sending seems to fail after sending 3 CAN messages. Using the simplest part of my code, I have a self-test routine for the box, that simply sends 100 messages from CAN 1 to CAN 2 (with a simple external link lead) to check the transceivers and wiring are all okay.
I initialise the CAN with the following (old Panda II code commented out
// Initialise CAN buses
//CANbus = new CAN(CAN.Channel.Channel_1, (uint)(((CANT2 - 1) << 20) | ((CANT1 - 1) << 16) | ((CANBRP - 1) << 0)), 3);
CANbus = new ControllerAreaNetwork(ControllerAreaNetwork.Channel.One, ControllerAreaNetwork.Speed.Kbps500); //500kbps on CAN1.
CANbus.ReceiveBufferSize = 3; // Set HW buffer to 3
CANbus.Enabled = true;
//CANbus_2 = new CAN(CAN.Channel.Channel_2, (uint)(((CANT2_2 - 1) << 20) | ((CANT1_2 - 1) << 16) | ((CANBRP_2 - 1) << 0)), 3);
CANbus_2 = new ControllerAreaNetwork(ControllerAreaNetwork.Channel.Two, ControllerAreaNetwork.Speed.Kbps500); //500kbps on CAN1.
CANbus_2.ReceiveBufferSize = 3; // Set HW buffer to 3
CANbus_2.Enabled = true;
And then, I simply send the same message 100 times with :
However, after sending 3 messages, I always get a System.Exception.
[em]Start of Main: Mem=111120
1 CAN messages sent
1 CAN messages sent
1 CAN messages sent
A first chance exception of type 'System.Exception' occurred in GHI.Hardware.dll
An unhandled exception of type 'System.Exception' occurred in GHI.Hardware.dll
The message I am sending is identical every time, so that should not be it. I assume it is in the SendMessages method itself, but the error gives no clues!
I have tried it with different receive buffer sizes (just because it was coincidentally set to 3 for the self-test) but it makes no difference.
I checked the same hardware with a Panda II board, and it works fine.
I know I had to add a CAN.Enabled with Panda III. Has anyone found any other settings needed in Panda III that were not needed on Panda II?
I plan to make some simpler HW with a single CAN channel connected to some CAN analysis tools to see if I can work out what is happening, but maybe someone has a quick answer and I have missed something obvious :)
Thanks in advance
In case it helps anyone, I found out (at least partially) why my CAN SendMessages was failing with a System.Exception.
With a valid CAN network attached to the controller (transceiver and fully-functioning receiving node) it all works fine. I was just testing with a transceiver attached, but no receiving node.
That does highlight one difference between Panda II and III. With Panda II, SendMessages does not cause an exception if the CAN network is missing/broken in some way - it just carries on working, even with no transceivers attached. This was very helpful, as this project does not always have both CAN channels connected at all times, depending on the configuration it is running in.
I was expecting SendMessages to respond with FALSE, if there was a problem with the CAN network, rather than cause an exception.
The error I get is “An unhandled exception of type ‘System.Exception’ occurred in GHI.Hardware.dll”, and only happens on the third message attempted. Is there any trick to avoid this? I can catch the exception, but I would prefer to understand why it is different in case there is a cleaner way to do it.
I am using SDK 2015 R1 - I see the pre-release of SDK 2016 R1 mentions a couple of CAN fixes, although none are exactly what I am getting. Is it possible to install both SDKs concurrently, so I can see if it fixes this? Or do I have to replace 2015 R1 with 2016 R1 (which is maybe not ready for a production environment yet)?
Unfortunately you must pick one or the other. You can however uninstall 2015 R1, install the beta of 2016 R1, test it, then uninstall and reinstall 2015 R1. But it’s some effort required on your part if you want to test it or not.
The one thing to remember in your “Panda” conversion, is that these two platforms are wildly different, in fact the only similarity is the name and the header layouts. The Original Panda and Panda2 used a USBizi100 processor with a netmf 4.1 port; the Panda3 uses the G80 which has a new 4.3 port - certainly the hardware changes alone may have a different handling of error states that needs different handling in your code, but there may have also been changes in the way the framework works with CAN that you’re seeing as well.
Thanks Brett, I will install 2016 R1 and give it a go!
For now (proper programmers look away now), I have put a Try/Catch around every SendMessages and that keeps it all going for now, albeit clumsily and stuttering if only one channel is connected. Browsing the API, I can see there is a “CanSend” property (and a couple of CAN transmission related counts), so I will investigate what that reports in different scenarios (the API does not give a lot of details), and see if I can use that. Even if it was not ready to send, I would expect to see a False response from SendMessages rather than an exception.
I was aware that the 2 platforms are very different - I have actually been pleasantly surprised how easy it has been to convert, and the speed ! I have held off converting to Panda III as I knew there would be many tweaks needed, but Panda IIs are getting harder to come by, so I had to bite the bullet. The lack of in-field update was a major reason for holding off, so I need to re-think the update strategy for that as well.
Catching the exception is fine in my view. But I think I also remember, an unterminated CAN bus doesn’t meet CAN specs, so it’s probably expected at some level to generate a failure rather than fail gracefully. Gus might chime in and comment, he knows a bit of CAN off the top of his head.
I need to look more closely at the Cobra III and G120. You spoilt us with Panda II as it has everything we need (2x CAN, uSD, IFU etc) :).
I am having trouble finding the input voltage range for the Cobra/Panda IIIs on the website though - an automotive-tolerant 6-20V like an Arduino would be just lovely
You are right that a CAN bus needs to be terminated, but I don’t think that an un-terminated CANbus should break the controller. There are many scenarios where a module may be required to work with CAN disconnected or with wiring faults. It may well be that the new properties I can see in the API (CANSend etc) will allow me to check the CAN state before I send it, so I will test those as well as rolling forward to 2016 R1 beta release (as it feels like I should just be able to check the return value of SendMessages rather than check for an exception). Hopefully, the G80 platform is sensing levels from the transceiver chip to determine the CAN state, and that is what I can use to state-check before sending… Exception handling seems much more CPU-time-consuming, limiting my CAN timing accuracy, although that may be because I am printing to debug when it happens.
This failure is not related to termination though, as I still get the failure even with fully-terminated buses connected and a receiving node HW in place (I am currently using Vector CANCase and similar tools to check it). It only works when the receiving node is actively taking messages off the bus.
In case it helps anyone, I will post what I find in this thread.
“breaking” your controller when the bus is off is a coding issue nothing more In the past the hardware might have been more tolerant of bus off errors, not so now, it’s just another case you need to handle (I don’t see any of these “issues” as issues, just something a coding change will deal with).
As for power input. The Cobra3 has the regular GHI switching power supply, so 7-30v input range (as noted on silkscreen at the barrel jack). The Panda3 has LDO linear regulators only, so only states 6-9v
The Cobra III schematic shows they are using a MIC4680 switching supply and if you check out it’s datasheet you will see that is can take up to 34V input so will be fine for automative use although I would add a front end to the power supply to suppress the noise you can get from automative power.
The Panda III uses a linear low voltage dropout regulator. It can handle up to 15V so should be OK for automative use but it will run very HOT due to the 14V to 5V drop you can expect on a car. GHI mark the Panda III as 6 to 9V which I presume is to keep this drop as low as possible to reduce the heat build up on the regulator so use caution if you want to power direct from the car. For ultimate reliability I would use one of those low cost DC-DC modules to drop the 12-15V to 6V and then power the board from this.
I notice on the Panda III design there is a resistor R20 connected from the VIN (12V) to the 5V output on the regulator. This might be for options or testing and is marked as DNP (Do Not Populate) so should not be fitted on production boards but I’d do a quick check to make sure this is not fitted before powering up the board.
This is quite normal for CAN bus. If there is no receiving device, the controller will be getting many errors and will eventually go OFF BUS. You need to detect this and reset the controller. You need a min of 2 devices so the the transmitting device gets the ACK from at least one device. That devices doesn’t have to process the message, it just has to ACK it so that the controller knows the message was broadcast and received by all nodes. No ACK is an error and the device tries again and once the max tries are reached, it goes off bus.
Good to know the Cobra is capable of a wider range. We already step down for the Panda, to keep it within spec, so that would be nice to avoid.
I will check R20 on a Panda III before I start destroying them!!
On the CAN error behaviour, I need to investigate the available CAN properties more to see what I can sense and what I can’t on the G80 platform. Without another node connected, I expected to at least get a ControllerAreaNetwork.Error triggered rather than an exception if I try to send (either an ACK error, or eventually a BusOff notification of some sort). I have already got an error handler including BusOff which simply resets it, but that is not being triggered either - it just fails within the messages sending and hangs, so I don’t get a chance to reset it. I haven’t tried monitoring the TransmitErrorCount yet to see if that is getting up to 255 which is when I would expect to go BusOff. I am not sending messages in to the module so there will be no mitigation for the Tx error count.
Hopefully I will get some time tonight to monitor all these properties as I plug/unplug the different parts of the network! Sometimes things not working can be just as interesting and educational as things working!
I still need to try a temporary install of 2016 R1 as well
Thanks for all the suggestions so far - all very much appreciated!
2016 R1 does not throw any exceptions, with or without HW connected. So, that seems to be the “fix”. I will probably stick with that release for now, and hope all the other bits I use are stable
I did check all the properties, and, apart from the exception, 2015 and 2016 behave the same. With or without a receiving node connected, powered and ACKing, the CANsend, Enabled and IsTransmitBufferEmpty all stay true. The only property that changes is TransmitErrorCount, which jumps up very quickly as soon as I try to send to a non-existent node (as expected with the ACK errors and retries). It tops out at 128 (Error Passive bus state), so will not reach 255 and then trigger the BusOff. As soon as I connect a real receiving node (I was using CANalyzer in receive-only, so I can see any low-level CAN errors received), I can see the TransmitErrorCount reduce to zero as the successful transmissions reduce it. That all seems to be working as expected. I have not yet bombarded it with error frames to see if it reaches BusOff as expected.