[SOLVED] Arduino mZero clone RobotDyn SAMD21 M0 board with RFM69HW sending but not receiving parent response
-
Already running a sensor and a MQTT gateway successfully based on Arduino Uno's.
Running a MQTT gateway on Arduino Uno works, but is too light if you want to add encryption for example.
Because I had already an Arduino Zero clone board laying around, I used this one to build a second gateway with a RFM69HW and a W5500 ethernet board.
The radio and the ethernet board are using the same SPI header pins (no soft SPI).
W5500 is using the default D10 CS pin and the radio is using D7 as CS pin and default D2 as IRQ.The gateway is successfully communicating with the MQTT broker on TCP-IP. It receives an IP and can connect to the broker, so the W5500 ethernet module is correctly working.
The radio was doing something, but it was not a correct behaviour as gateway.To debug, I decided to download the mocksensor sketch to it and to test it as a normal sensor togeter with the working Arduino Uno based gateway.
The log of the Arduino Based gateway:
4504614 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0: 4504620 TSF:MSG:BC 4504622 TSF:MSG:FPAR REQ,ID=10 4504625 TSF:PNG:SEND,TO=0 4504627 TSF:CKU:OK 4504629 TSF:MSG:GWL OK 4508907 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 4512615 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0: 4512620 TSF:MSG:BC 4512622 TSF:MSG:FPAR REQ,ID=10 4512625 TSF:CKU:OK,FCTRL 4512627 TSF:MSG:GWL OKThe log of the M0 board:
26196 TSM:INIT 26207 TSM:INIT:TSP OK 26217 TSM:INIT:STATID=10 26228 TSF:SID:OK,ID=10 26238 TSM:FPAR 28249 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 30260 !TSM:FPAR:NO REPLY 30270 TSM:FPAR 32281 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 34292 !TSM:FPAR:NO REPLY 34302 TSM:FPAR 36313 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 38324 !TSM:FPAR:NO REPLY 38334 TSM:FPAR 40345 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 42356 !TSM:FPAR:FAIL 42366 TSM:FAIL:CNT=2 42376 TSM:FAIL:DIS 42386 TSF:TDI:TSLSo, the sensor is sending a parent request.
We see that the gateway is receiving the request and sends a parent response.
But the sensor never receives it...I replaced already the radio module by another one, but same result.
Anyone an idea what could be the reason?
-
You could try enabling the deeper radio debugging feature. I forget what it's called.
-
I activated these debug options:
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM69
#define MY_DEBUG_VERBOSE_RFM69_REGISTERS316261 TSM:FAIL:RE-INIT 316271 TSM:INIT 316281 RFM69:INIT 316291 RFM69:INIT:PIN,CS=7,IQP=2,IQN=2 316302 RFM69:PTX:LEVEL=5 dBm 316312 RFM69:DUMP:Registers Address | HEX value 316323 RFM69:DUMP:REG=0x01 Value=0x04 316333 RFM69:DUMP:REG=0x02 Value=0x00 316343 RFM69:DUMP:REG=0x03 Value=0x02 316353 RFM69:DUMP:REG=0x04 Value=0x40 316363 RFM69:DUMP:REG=0x05 Value=0x03 316374 RFM69:DUMP:REG=0x06 Value=0x33 316384 RFM69:DUMP:REG=0x07 Value=0xd9 316394 RFM69:DUMP:REG=0x08 Value=0x00 316404 RFM69:DUMP:REG=0x09 Value=0x00 316415 RFM69:DUMP:REG=0x0a Value=0x41 316425 RFM69:DUMP:REG=0x0b Value=0x00 316435 RFM69:DUMP:REG=0x0c Value=0x02 316445 RFM69:DUMP:REG=0x0d Value=0x92 316455 RFM69:DUMP:REG=0x0e Value=0xf5 316466 RFM69:DUMP:REG=0x0f Value=0x20 316476 RFM69:DUMP:REG=0x10 Value=0x24 316486 RFM69:DUMP:REG=0x11 Value=0x57 316496 RFM69:DUMP:REG=0x12 Value=0x09 316507 RFM69:DUMP:REG=0x13 Value=0x1a 316517 RFM69:DUMP:REG=0x14 Value=0x40 316527 RFM69:DUMP:REG=0x15 Value=0xb0 316537 RFM69:DUMP:REG=0x16 Value=0x7b 316547 RFM69:DUMP:REG=0x17 Value=0x9b 316558 RFM69:DUMP:REG=0x18 Value=0x88 316568 RFM69:DUMP:REG=0x19 Value=0xe2 316578 RFM69:DUMP:REG=0x1a Value=0xe2 316588 RFM69:DUMP:REG=0x1b Value=0x40 316599 RFM69:DUMP:REG=0x1c Value=0x80 316609 RFM69:DUMP:REG=0x1d Value=0x06 316619 RFM69:DUMP:REG=0x1e Value=0x10 316629 RFM69:DUMP:REG=0x1f Value=0x00 316640 RFM69:DUMP:REG=0x20 Value=0x00 316650 RFM69:DUMP:REG=0x21 Value=0x00 316660 RFM69:DUMP:REG=0x22 Value=0x00 316670 RFM69:DUMP:REG=0x23 Value=0x02 316680 RFM69:DUMP:REG=0x24 Value=0xff 316691 RFM69:DUMP:REG=0x25 Value=0x00 316701 RFM69:DUMP:REG=0x26 Value=0x07 316711 RFM69:DUMP:REG=0x27 Value=0x80 316721 RFM69:DUMP:REG=0x28 Value=0x00 316732 RFM69:DUMP:REG=0x29 Value=0xe4 316742 RFM69:DUMP:REG=0x2a Value=0x00 316752 RFM69:DUMP:REG=0x2b Value=0x00 316762 RFM69:DUMP:REG=0x2c Value=0x00 316772 RFM69:DUMP:REG=0x2d Value=0x03 316783 RFM69:DUMP:REG=0x2e Value=0x88 316793 RFM69:DUMP:REG=0x2f Value=0x2d 316803 RFM69:DUMP:REG=0x30 Value=0x64 316813 RFM69:DUMP:REG=0x31 Value=0x00 316823 RFM69:DUMP:REG=0x32 Value=0x00 316834 RFM69:DUMP:REG=0x33 Value=0x00 316844 RFM69:DUMP:REG=0x34 Value=0x00 316854 RFM69:DUMP:REG=0x35 Value=0x00 316864 RFM69:DUMP:REG=0x36 Value=0x00 316875 RFM69:DUMP:REG=0x37 Value=0xd4 316885 RFM69:DUMP:REG=0x38 Value=0x40 316895 RFM69:DUMP:REG=0x39 Value=0xff 316905 RFM69:DUMP:REG=0x3a Value=0xff 316916 RFM69:DUMP:REG=0x3b Value=0x00 316926 RFM69:DUMP:REG=0x3c Value=0x05 316936 RFM69:DUMP:REG=0x3d Value=0x10 316946 RFM69:DUMP:REG=0x3e Value=0x00 316957 RFM69:DUMP:REG=0x3f Value=0x00 316967 RFM69:DUMP:REG=0x40 Value=0x00 316977 RFM69:DUMP:REG=0x41 Value=0x00 316987 RFM69:DUMP:REG=0x42 Value=0x00 316998 RFM69:DUMP:REG=0x43 Value=0x00 317008 RFM69:DUMP:REG=0x44 Value=0x00 317018 RFM69:DUMP:REG=0x45 Value=0x00 317028 RFM69:DUMP:REG=0x46 Value=0x00 317038 RFM69:DUMP:REG=0x47 Value=0x00 317049 RFM69:DUMP:REG=0x48 Value=0x00 317059 RFM69:DUMP:REG=0x49 Value=0x00 317069 RFM69:DUMP:REG=0x4a Value=0x00 317079 RFM69:DUMP:REG=0x4b Value=0x00 317090 RFM69:DUMP:REG=0x4c Value=0x00 317100 RFM69:DUMP:REG=0x4d Value=0x00 317110 RFM69:DUMP:REG=0x4e Value=0x01 317120 RFM69:DUMP:REG=0x4f Value=0x00 317130 TSM:INIT:TSP OK 317141 TSM:INIT:STATID=10 317151 TSF:SID:OK,ID=10 317161 TSM:FPAR 317172 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0 317183 RFM69:CSMA:RSSI=-102 319193 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 321204 !TSM:FPAR:NO REPLY 321214 TSM:FPAR 321224 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0 321235 RFM69:CSMA:RSSI=-98 323246 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 325257 !TSM:FPAR:NO REPLY 325267 TSM:FPAR 325277 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0 325288 RFM69:CSMA:RSSI=-97 327299 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 329310 !TSM:FPAR:NO REPLY 329320 TSM:FPAR 329330 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0 329341 RFM69:CSMA:RSSI=-98 331352 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 333363 !TSM:FPAR:FAIL 333373 TSM:FAIL:CNT=7 333383 TSM:FAIL:DIS 333393 TSF:TDI:TSL 333403 RFM69:RSLI see now values in the registers, but now how to continue?
Meanwhile:
I had said that originally I did take the M0 board (by the way it is a RobotDyn SAMD21 M0 board) to build a more powerfull gateway, but because of the radio problems I was doing now tests with the M0 board as normal sensor and my working Arduino UNO as MQTT gateway to be able to see the interactions.
So today I desoldered the W5500 ethernet module from the M0 board to be sure that it was not causing a side effect.
No change in results, my M0 board sensor does send a parent request, I see in the gateway the reception and a send of the parent response, but the sensor doesn't receive anything.
Or is the sensor not waiting enough after the answer?
-
from your logs, it seems your SAMD21 board irq is not triggering, so Find parent fails.
it could be a very few things:- problem with irq signal mapping : IQP=2,IQN=2 does not seem ok I think, especially irq number, I would maybe expect IQN=14 for a regular arduino zero board.
- out of range
but I feel it could be 1).
It could be related to your defines, but you haven't posted your test sketches, so can't tell you..
Note: I don't remember though if 'virtual' eeprom is handled for SAMD in MySensors (HW support might be basic) as these mcu don't have integrated eeprom. so in case you need it in future, you could add one, could be handy for a gw.
-
That is something I have still problems with: what are the pinnumber to use if not an Arduino UNO?
#define MY_RFM69_IRQ_PIN
Define this to override the default RFM69 IRQ pin assignment.
#define MY_RFM69_IRQ_NUM digitalPinToInterrupt(MY_RFM69_IRQ_PIN)
Should I define here 14 (from the pin PA14)?EDIT: I tested it quickly by putting the define MY_RFM69_IRQ_NUM equal to 14, but no change in the result, same behaviour.
My hardware connections:
Samd31 M0 board --> RFM69HW
PA14/D2 --> DIO0
PA21/D7 --> NSS
MOSI/PB10(ISP header) --> MOSI
MISO/PB12(ISP header) --> MISO
SCK/PB11(ISP header) --> SCKAs test sketch I'm using the example pingpongsensor example adapted for the RF69 radio.
The IRQ pin is not defined, because I thought that mysensors lib takes pin D2 as the default.
Out of range is normally not the case, they are at 10 cm of each other.../* * The MySensors Arduino library handles the wireless radio link and protocol * between your home built sensors/actuators and HA controller of choice. * The sensors forms a self healing radio network with optional repeaters. Each * repeater and gateway builds a routing tables in EEPROM which keeps track of the * network topology allowing messages to be routed to nodes. * * Created by Henrik Ekblad <henrik.ekblad@mysensors.org> * Copyright (C) 2013-2018 Sensnology AB * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors * * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * ******************************* * * This is a simple sketch used to demonstrate and test node-to-node MySensors communication. * To use this sketch, assemble MySensors nodes - they need nothing more than a radio * 1. Flash each node with the same sketch, open the console and type either 0 or 1 to the respective nodes to set their ID * 2. You only need to set the node id once, and restart the nodes * 3. To being a ping-pong test, simply type T in the console for one of the nodes. * * 2015-05-25 Bruce Lacey v1.0 */ // Enable debug prints to serial monitor #define MY_DEBUG #define MY_DEBUG_VERBOSE_RFM69 #define MY_DEBUG_VERBOSE_RFM69_REGISTERS // Enable and select radio type attached #define MY_RADIO_RFM69 #define MY_RFM69_FREQUENCY RFM69_868MHZ // Set your frequency here #define MY_IS_RFM69HW // Omit if your RFM is not "H" #define MY_RFM69_NEW_DRIVER #define MY_RFM69_CS_PIN 7 #define MY_SECURITY_SIMPLE_PASSWORD "mysecretpassword" #define MY_NODE_ID 10 // https://forum.mysensors.org/topic/10548/sensbender-gateway-gives-a-lot-of-hu // temporary fix, can be deleted when Arduino SAMD board definitions will be corrected. #undef PRId8 #undef PRIi8 #undef PRIo8 #undef PRIu8 #undef PRIx8 #undef PRIX8 #undef PRIdLEAST8 #undef PRIiLEAST8 #undef PRIoLEAST8 #undef PRIuLEAST8 #undef PRIxLEAST8 #undef PRIXLEAST8 #undef PRIdFAST8 #undef PRIiFAST8 #undef PRIoFAST8 #undef PRIuFAST8 #undef PRIxFAST8 #undef PRIXFAST8 #define PRId8 "d" #define PRIi8 "i" #define PRIo8 "o" #define PRIu8 "u" #define PRIx8 "x" #define PRIX8 "X" #define PRIdLEAST8 "d" #define PRIiLEAST8 "i" #define PRIoLEAST8 "o" #define PRIuLEAST8 "u" #define PRIxLEAST8 "x" #define PRIXLEAST8 "X" #define PRIdFAST8 "d" #define PRIiFAST8 "i" #define PRIoFAST8 "o" #define PRIuFAST8 "u" #define PRIxFAST8 "x" #define PRIXFAST8 "X" #include <MySensors.h> #include "MYSLog.h" #define VSN "v1.0" // Define two generic nodes with a single child #define YING 200 #define YANG 201 #define CHILD 1 MyMessage mPing(CHILD, V_VAR1); //Ping message MyMessage mPong(CHILD, V_VAR2); //Pong message void setup() { } void presentation() { present(CHILD, S_CUSTOM); // sendSketchInfo( nodeTypeAsCharRepresentation( getNodeId() ), VSN ); LOG(F("\n%sReady.\n"), nodeTypeAsCharRepresentation(getNodeId())); } void loop() { // Interactive command and control // Entering a number from 0 or 1 will write the node 200 (YING) or 201 (YANG) to EEPROM // Entering T on either node will initiate a ping-pong test. if (Serial.available()) { byte inChar = Serial.read(); uint8_t node = getNodeId(); // Manual Test Mode if (inChar == 'T' || inChar == 't') { LOG(F("T received - starting test...\n")); MyMessage msg = mPong; msg.sender = (node == YING ? YANG : YING); sendPingOrPongResponse( msg ); } else if (inChar == '0' or inChar == '1') { byte nodeID = 200 + (inChar - '0'); setNodeId(nodeID); } else { LOG("Invalid input\n"); } } } void receive(const MyMessage &message) { LOG(F("Received %s from %s\n"), msgTypeAsCharRepresentation((mysensors_data_t)message.type), nodeTypeAsCharRepresentation(message.sender)); delay(250); sendPingOrPongResponse( message ); } void sendPingOrPongResponse( MyMessage msg ) { MyMessage response = (msg.type == V_VAR1 ? mPong : mPing); LOG(F("Sending %s to %s\n"), msgTypeAsCharRepresentation( (mysensors_data_t)response.type ), nodeTypeAsCharRepresentation(msg.sender)); // Set payload to current time in millis to ensure each message is unique response.set( (uint32_t)millis() ); response.setDestination(msg.sender); send(response); } void setNodeId(byte nodeID) { LOG(F("Setting node id to: %i.\n***Please restart the node for changes to take effect.\n"), nodeID); hwWriteConfig(EEPROM_NODE_ID_ADDRESS, (byte)nodeID); } const char * msgTypeAsCharRepresentation( mysensors_data_t mType ) { return mType == V_VAR1 ? "Ping" : "Pong"; } const char * nodeTypeAsCharRepresentation( uint8_t node ) { return node == YING ? "Ying Node" : "Yang Node"; }
-
@tbowmo
An old thread already : https://forum.mysensors.org/topic/5555/arduino-zero-supported/6
It should be possible to use the zero with mysensors library. And as @scalz mentions, the upcoming Sensebender GW is based on basically the same mcu, as used in the zero.
However you can't use the the gw files for the zero, as I use a couple of tricks, and use multiple spi ports, which isn't available on the zero, if I remember correctly.
Is this still true? What you mean by use multiple spi ports?
On the robotdyn samd21 M0 board there is only one SPI port, via the header.
-
@evb
samd21 can have a few independant spi bus (depends on the samd21 variant and pincount).
these spi bus needs to be defined in boards definition files.
the mcu on arduino zero is able to do that, but it is maybe used by some other stuff like the onboard debugger, can't tell you more about this because I always made custom board with all peripherals available (and no time to compare the Zero schematic vs datasheet).back to your problem, just to be sure did you try something like this:
#define MY_RFM69_IRQ_PIN 2 #define MY_RFM69_IRQ_NUM digitalPinToInterrupt(MY_RFM69_IRQ_PIN)or
#define MY_RFM69_IRQ_PIN 2 #define MY_RFM69_IRQ_NUM 14@evb said in Arduino Zero clone SAMD21 M0 board with RFM69HW sending but not receiving parent response:
As test sketch I'm using the example pingpongsensor example adapted for the RF69 radio.
The IRQ pin is not defined, because I thought that mysensors lib takes pin D2 as the default.
Out of range is normally not the case, they are at 10 cm of each other...not the case for ARM mcus which are very flexible, MySensors cannot cover all makers boards and their different mapping
That wasn't a problem with regular AVR8 328p which has fixed mapping but tends to become obsolete and limited imhoSo your sketch example is still missing the above defines..this is a mandatory for your board.
Could you show your logs with those defines enabled plzNote it could also be the range, if the antenna was not good, or wrong power settings etc. I even read once people forgot to add an antenna etc
but for the moment I think it's pin mapping, as there is no problem with MySensors SAMD afaik
-
@evb said in Arduino Zero clone SAMD21 M0 board with RFM69HW sending but not receiving parent response:
Out of range is normally not the case, they are at 10 cm of each other...
10cm can be too close. There should be at least a few wavelength's distance between the nodes, to be outside the near field. Within the near field, normal radio propagation calculations do not apply.
A few wavelength's distance might not be enough though, because the signal can be too strong and saturate (overpower) the receiver. It is like screaming a sentence into someone's ear - it will be too loud to hear the words.
Try to keep at least 1m distance between the nodes.
-
Apparently this day is my lucky day
@scalz , you did me think with your comment about the samd21 board not triggering the irq.
So I looked up where the pin layouts of all these 'arduino compatible' boards are defined.
My used board is a RobotDyn Samd21 M0 board and they claim compatible with a Arduino M0 and I did use the Arduino SAMD boards (32-bits ARM Cortex-M0+) by Arduino version 1.8.3.
The code you find at: https://github.com/arduino/ArduinoCore-samd
With some help of the google doctor, I did find that the pin layouts are defined in the Variants.cpp file in
https://github.com/arduino/ArduinoCore-samd/blob/master/variants/arduino_mzero/variant.cpp
(I'm using the Arduino M0 entry when selecting my board)
In this file/* * * + Pin number + ZERO Board pin | PIN | Label/Name | Comments (* is for default peripheral in use) * +------------+------------------+--------+-----------------+------------------------------ * | | Digital Low | | | * +------------+------------------+--------+-----------------+------------------------------ * | 0 | 0 -> RX | PA11 | | EIC/EXTINT[11] ADC/AIN[19] PTC/X[3] *SERCOM0/PAD[3] SERCOM2/PAD[3] TCC1/WO[1] TCC0/WO[3] * | 1 | 1 <- TX | PA10 | | EIC/EXTINT[10] ADC/AIN[18] PTC/X[2] *SERCOM0/PAD[2] TCC1/WO[0] TCC0/WO[2] * | 2 | ~2 | PA08 | | EIC/NMI ADC/AIN[16] PTC/X[0] SERCOM0/PAD[0] SERCOM2/PAD[0] *TCC0/WO[0] TCC1/WO[2] * | 3 | ~3 | PA09 | | EIC/EXTINT[9] ADC/AIN[17] PTC/X[1] SERCOM0/PAD[1] SERCOM2/PAD[1] *TCC0/WO[1] TCC1/WO[3] * | 4 | ~4 | PA14 | | EIC/EXTINT[14] SERCOM2/PAD[2] SERCOM4/PAD[2] TC3/WO[0] *TCC0/WO[4] * | 5 | ~5 | PA15 | | EIC/EXTINT[15] SERCOM2/PAD[3] SERCOM4/PAD[3] TC3/WO[1] *TCC0/WO[5] * | 6 | ~6 | PA20 | | EIC/EXTINT[4] PTC/X[8] SERCOM5/PAD[2] SERCOM3/PAD[2] TC7/WO[0] *TCC0/WO[6] * | 7 | ~7 | PA21 | | EIC/EXTINT[5] PTC/X[9] SERCOM5/PAD[3] SERCOM3/PAD[3] TC7/WO[1] *TCC0/WO[7] * +------------+------------------+--------+-----------------+------------------------------ * | | Digital High | | | * +------------+------------------+--------+-----------------+------------------------------ * | 8 | ~8 | PA06 | | EIC/EXTINT[6] PTC/Y[4] ADC/AIN[6] AC/AIN[2] SERCOM0/PAD[2] *TCC1/WO[0] * | 9 | ~9 | PA07 | | EIC/EXTINT[7] PTC/Y[5] DC/AIN[7] AC/AIN[3] SERCOM0/PAD[3] *TCC1/WO[1] * | 10 | ~10 | PA18 | | EIC/EXTINT[2] PTC/X[6] SERCOM1/PAD[2] SERCOM3/PAD[2] *TC3/WO[0] TCC0/WO[2] * | 11 | ~11 | PA16 | | EIC/EXTINT[0] PTC/X[4] SERCOM1/PAD[0] SERCOM3/PAD[0] *TCC2/WO[0] TCC0/WO[6] * | 12 | ~12 | PA19 | | EIC/EXTINT[3] PTC/X[7] SERCOM1/PAD[3] SERCOM3/PAD[3] *TC3/WO[1] TCC0/WO[3] * | 13 | ~13 | PA17 | LED | EIC/EXTINT[1] PTC/X[5] SERCOM1/PAD[1] SERCOM3/PAD[1] *TCC2/WO[1] TCC0/WO[7] * | 14 | GND | | | * | 15 | AREF | PA03 | | *DAC/VREFP PTC/Y[1] * | 16 | SDA | PA22 | | EIC/EXTINT[6] PTC/X[10] *SERCOM3/PAD[0] SERCOM5/PAD[0] TC4/WO[0] TCC0/WO[4] * | 17 | SCL | PA23 | | EIC/EXTINT[7] PTC/X[11] *SERCOM3/PAD[1] SERCOM5/PAD[1] TC4/WO[1] TCC0/WO[5]This is the defined pin mapping for a Arduino mZero. (I was using D2 as IRQ for the RFM69)
* | 2 | ~2 | PA08 |But on the pin layout of the RobotDyn board I saw:
* | 2 | ~2 | PA14 |On the RobotDyn the pin PA08 is mapped on the D4 arduino pin and not the D2 pin!
With the pins D2/D4, RobotDyn is following here the Arduino Zero layout and NOT the Arduino mZero layout!So, I verified the other mappings and found that following pins are different mapped on the Arduino mZero:
* | 2 | ~2 | PA08 | * | 4 | ~4 | PA14 |On the RobotDyn Samd21M0
* | 2 | ~2 | PA14 | * | 4 | ~4 | PA08 |So I changed the IRQ (DIO0) from the RF69 to the port D8 (PA06) and bingo it started to work
(did choose randomly D8)I saw also a difference in the SPI mapping
mZero* | 18 | 1 | PA12 | MISORobotDyn samd21 m0
* | not defined on their pin layout doc | 1 | PB12 | MISOBut it is working, so maybe an error on RobotDyn's documentation?
So if I resume the thing:
The RobotDyn SAMD21 M0 board is claimed compatible with the Arduino M0 (mZero). In the IDE you must also select the Arduino M0. (selecting Arduino/Genuino Zero xxx will not work)
But the RobotDyn used layout is compatible with the Arduino Zero, so pin D2 and D4 are reversed, making the code of the board Arduino M0 not working if you choose to use these pins in your design.So now we can continue to build our gateway, my originally goal.
Edit : my MQTT gateway with the RobotDyn Samd21 M0 board, a W5500 ethernet module and a radio RFM69HW is up and runningThanks for all comments that guided me to the solution
