Hello hello, I believe this is my first post here!
I am having an issue with a complete system we are working on. We are in the stages of trying to debug everything but it is a bit hard at this point to separate a possible firmware issue from a hardware issue due to our lack of some test equipment so I am hoping to get some feedback on a few questions about the code first here.
I am working with a MCP2515 TJ1A050 CANBus Transeiver (using a pre-made board like this) and the boron LTE, and utilizing the dependencies.MCP_CAN_RK=1.5.1 library.
For a while I was generally seeing CAN data arrive, much like the example, the code has a form like this:
#include <mcp_can.h>
#include <SPI.h>
// CANBUS Shield pins
#define CAN0_INT D6 // Set INT to pin 9
MCP_CAN CAN0(A5); // Set CS to pin A5
// MCP_CAN DATA
long unsigned int rxId;
unsigned char len = 0;
unsigned char rxBuf[8];
setup() {
// ... other things
CAN0.begin(MCP_ANY, CAN_250KBPS, MCP_8MHZ) == CAN_OK)
CAN0.setMode(MCP_NORMAL);
pinMode(CAN0_INT, INPUT);
// ... other things
}
// ... etc
loop {
// ...etc other things
if(!digitalRead(CAN0_INT)) {
CAN0.readMsgBuf(&rxId, &len, rxBuf);
// Call other function that does things with this data based on the rxId
}
// ...etc other things
}
// ... etc
And we are having an issue where the CAN data is more likely to be read right after pushing a new firmware or potentially power cycling the device, and then at some point it stops receiving sometimes. What I have done in the meantime is add a counter variable within the if(!digitalRead(CAN0_INT)) and print that out along with our usual 1-second debug serial print logic. But of course, we have not been able to replicate the issue since we started observing it more so I cannot say if that data is coming in over CAN and is just “corrupt” or if it is missing. And I have no real way to analyse this data until we sort out a PC based adapter solution.
We do know that the device continues to be responsive, even when not responding to assumed data on the CAN bus from the BMS system, and even when not connected to the USB serial monitor, as we do see the particle publish send out bogus data.
My basic question is: does it make sense that if the INT pin is an “interrupt” that we should just be monitoring for it in the loop? Or should we be attaching an interrupt to this pin?
Also, does anyone have any resources for debugging something like this WITHOUT using the microUSB cable. I do have the particle JTAG debugger on my desk and have still not been able to use it. It would be wonderful to be able to add breakpoints and see what is going on with the hardware but I am a bit lost when it comes to how that integrates with the VS code ecosystem, if at all. I have never done debugging outside of an IDE running code on my local machine.
Another related question for the Boron, The main difference now that we are not seeing the issue is that we are delivering power over the USB port of our computers vs the voltage pin. Maybe the issue is in the power delivery is the issue here anyways. Is there any reason we could not snip the 5V wire in the USB and still be able to talk to the Boron without providing a different means of power?
Thanks for any assistance, I hope to be able to update the thread once we are again able to replicate the issue, or try to eliminate any potential hardware problems.
I know there is a lot going on in this post but I think a couple extra eyes particularly with experience either debugging with breakpoints or with specific experience in this MCP_CAN stuff would get us out of this black hole where we are having a hard time eliminating variables.
- Mark Amber
