Sketch works on nano but not uno r4?

Hi All,

I have a strange one...(to me anyway)

I have sketch that works perfectly on a nano, however I want to upload to a uno r4 and I need the speed, however the compile fails, I can get it to load but the crc check is incorrect and the canbus code does not work correctly (incorrect crc on send message), Ive spent a bit of time and cant see it... (im not a coder tbh, just having a go).

The canbus message MUST start (f0) with the 0xd8 checksum, (it does on the nano), but not uno.

Any help would be great, TIA.

#include <mcp_can.h>
#include <SPI.h>
#define CAN_INT 2 // INT pin
MCP_CAN CAN(10); // CS pin

const uint8_t crc8_lut[] = {
    0x00, 0x1d, 0x3a, 0x27, 0x74, 0x69, 0x4e, 0x53, 0xe8, 0xf5, 0xd2, 0xcf,
    0x9c, 0x81, 0xa6, 0xbb, 0xcd, 0xd0, 0xf7, 0xea, 0xb9, 0xa4, 0x83, 0x9e,
    0x25, 0x38, 0x1f, 0x02, 0x51, 0x4c, 0x6b, 0x76, 0x87, 0x9a, 0xbd, 0xa0,
    0xf3, 0xee, 0xc9, 0xd4, 0x6f, 0x72, 0x55, 0x48, 0x1b, 0x06, 0x21, 0x3c,
    0x4a, 0x57, 0x70, 0x6d, 0x3e, 0x23, 0x04, 0x19, 0xa2, 0xbf, 0x98, 0x85,
    0xd6, 0xcb, 0xec, 0xf1, 0x13, 0x0e, 0x29, 0x34, 0x67, 0x7a, 0x5d, 0x40,
    0xfb, 0xe6, 0xc1, 0xdc, 0x8f, 0x92, 0xb5, 0xa8, 0xde, 0xc3, 0xe4, 0xf9,
    0xaa, 0xb7, 0x90, 0x8d, 0x36, 0x2b, 0x0c, 0x11, 0x42, 0x5f, 0x78, 0x65,
    0x94, 0x89, 0xae, 0xb3, 0xe0, 0xfd, 0xda, 0xc7, 0x7c, 0x61, 0x46, 0x5b,
    0x08, 0x15, 0x32, 0x2f, 0x59, 0x44, 0x63, 0x7e, 0x2d, 0x30, 0x17, 0x0a,
    0xb1, 0xac, 0x8b, 0x96, 0xc5, 0xd8, 0xff, 0xe2, 0x26, 0x3b, 0x1c, 0x01,
    0x52, 0x4f, 0x68, 0x75, 0xce, 0xd3, 0xf4, 0xe9, 0xba, 0xa7, 0x80, 0x9d,
    0xeb, 0xf6, 0xd1, 0xcc, 0x9f, 0x82, 0xa5, 0xb8, 0x03, 0x1e, 0x39, 0x24,
    0x77, 0x6a, 0x4d, 0x50, 0xa1, 0xbc, 0x9b, 0x86, 0xd5, 0xc8, 0xef, 0xf2,
    0x49, 0x54, 0x73, 0x6e, 0x3d, 0x20, 0x07, 0x1a, 0x6c, 0x71, 0x56, 0x4b,
    0x18, 0x05, 0x22, 0x3f, 0x84, 0x99, 0xbe, 0xa3, 0xf0, 0xed, 0xca, 0xd7,
    0x35, 0x28, 0x0f, 0x12, 0x41, 0x5c, 0x7b, 0x66, 0xdd, 0xc0, 0xe7, 0xfa,
    0xa9, 0xb4, 0x93, 0x8e, 0xf8, 0xe5, 0xc2, 0xdf, 0x8c, 0x91, 0xb6, 0xab,
    0x10, 0x0d, 0x2a, 0x37, 0x64, 0x79, 0x5e, 0x43, 0xb2, 0xaf, 0x88, 0x95,
    0xc6, 0xdb, 0xfc, 0xe1, 0x5a, 0x47, 0x60, 0x7d, 0x2e, 0x33, 0x14, 0x09,
    0x7f, 0x62, 0x45, 0x58, 0x0b, 0x16, 0x31, 0x2c, 0x97, 0x8a, 0xad, 0xb0,
    0xe3, 0xfe, 0xd9, 0xc4
};

// CAN message
long unsigned int rxId;
unsigned char len = 0;
unsigned char rxBuf[8];
//
int counter4Bit = 0xf0;
//
//
uint8_t crc8(byte crc, byte const *buf, byte len) {
    for (uint32_t i = 0; i < len; i++) {
        byte data = buf[i] ^ crc;
        crc = crc8_lut[data] ^ (crc << 8);
    }
    return crc ^ 0x70;
}
void Test(){
  if (counter4Bit >= 0xff) { counter4Bit = 0xf0; }
  byte BufWithoutCRC[] = { 0xf0|counter4Bit, 0xFE, 0xFF, 0x15 };
  byte BufWithCRC[] = { crc8(BufWithoutCRC, 4, 0xd8), 0xf0|counter4Bit, 0xFE, 0xFF, 0x15};
  CAN.sendMsgBuf(0x36E, 0, 5, BufWithCRC);

  counter4Bit++;
}
//
void setup(){
  Serial.begin(115200);
  Serial.println("MCP2515 Initializing at 500kb/s");
  CAN.begin(MCP_ANY, CAN_500KBPS, MCP_8MHZ);
  CAN.setMode(MCP_NORMAL);
}
//
void loop(){
  Test();
}

Okay, I don't know much at all but I'll throw this on here before the ones who know stuff show up and give a far better answer.

If the code works and produces expected computational output on the Nano but not on the Uno R4 it could be some internal difference in how memory alloc or calcs are done but they're both ATMega328P boards, right? So, that shouldn't be it. Still...

I had a problem a few days back where my code kept crashing in the weirdest ways on a Nano. After too much time trying to understand why, I switched to another Nano and it worked properly. To be honest, these are Elegoo Amazon specials. The first "Nano" has a problem.

Is the Uno R4 genuine (less likely to be trash like my Elegoo Nano)? Have you verified it's working properly with another/other sketch(es)?

--HC

If the compile fails how were you able to upload?
Are you using the Arduino IDE?

Sorry, too busy to read and understand all the code, but using int on a 32 bit processor and 16 bit processor could be an issue. You are better to use the int16_t or uint16_t that way both the 16 bit NANO and 32 bit UNO R4 will compile the same code.

No, one is AVR, the other one Renesas.

The compile is ok, but there are warnings. The warnings are the kind that explain your problem.

Pay attention to the warnings and fix them by casting to appropriate data types.

genuine r4

i changed

byte BufWithCRC[] = { crc8(BufWithoutCRC, 4, 0xd8), 0xf0|counter4Bit, 0xFE, 0xFF, 0x15};

to

byte BufWithCRC[] = { crc8(0xd8, BufWithoutCRC, 4), 0xf0|counter4Bit, 0xFE, 0xFF, 0x15};

and it compiles and loads, but does not give same result (on canbus).

Just tried that and same result.

different error code
exit status 1

from
invalid conversion from 'byte* {aka unsigned char*}' to 'uint8_t {aka unsigned char}' [-fpermissive]

to

exit status 1
invalid conversion from 'uint16_t* {aka short unsigned int*}' to 'uint16_t {aka short unsigned int}' [-fpermissive]

thnaks for the help guys, its helping :slight_smile:

Here is the differences. I compiled with ALL warnings

Nano UNO R4 WiFi
48 - W - W
49 - E - W
39 - note - note
49 - E - W
39 - note - note
49 - W - W

thanks, I get that, but havent been coding long enough to work out the correct fix.

appreciate the help.

You need to correctly and in a way that is uderstood by both processors declare your vars. So char or unsigned char must be int8_t and uint8_t and so on. ANY calculation with an intermediate result must be explicitly cast.
Bottom line is every specified var and intermediate result must be declared or cast in a unambiguous way and in a way that gives the same result on both architectures.

sorry its not the wifi, its an uno r4 miniva (if thats makes a difference).

Line numbers and error code?

Ok, I thought I had, but obvioulsy missed something.

UNO R4 wifi or minima is same for this exercise.
Yes, line # and error.

What is important is that the 16 bit NANO gives different errors than the 32 bit UNO.

This code will be difficult to code correctly.

Ah ok, thats annoying.... I'll keep at it

My mistake...R4, not R3.

--HC

Just concentrate on this line to start. Fix it so that there are NO errors for that line, then apply the same fix logic to any others of the same type.
HINT, the target BufWithoutCRC can only hold 8 bits but the counter4Bit is declared int.

It does NOT compile!!!