I have only an counter running on my water node increasing with each pulse. When counter changed, sending value to controller. Controller evaluates delta between current and last receive and adds delta to "water meter". No problem if either controller or sensor looses power.

No. For RFM69 you need Sensbender bootloader and external flash. Then it works.

After a bit more searching in the forum a came across this topic:
https://forum.mysensors.org/post/106056
Which mentioned
https://github.com/mysensors/MySensors/pull/1422
and finally found this
https://github.com/WhiskyDelta/MySensors/tree/stm32_cores,
which compiles fine for me. :+1: :blush:

Hello,
I tried to do some modifications on a project from 2 years ago, which is using STM32F411. During that time everything was fine. No issue to compile for STM32F1/F4 controllers.
Now computer has changed and software was updated and I'm not able to compile STM32F4xx controller any more, STM32F1 is still ok.
I always get:

 #error Hardware abstraction not defined (unsupported platform)
  ^

Is there anything I forgot tho change or update for using F4 controllers?

@virtualmkr thanks for pointing to _serialProcess(). This help to understand a little more how it works.
I finally found the issue: bias resistors (10k) at A and B lost connection, so during bus idle RX was low and not high. For AVR this was not a problem, but STM32 did not synchronize right to the frame.

I try to get a node based on STM32 to work with RS485. No success. Mysensors does send on RS485, but does not receive anything. I checked the signals with scope. Physically TX signals go out and reply from gateway goes into RX pin, but is not read by mysensors lib. I tried all UARTs. Apart from mysensors lib, I'm able to do serial communication with other UARTs than the one used for RS485.
I used F103 and F401/411 with both STM libs (maple, ST) when possible.

If I just change the ST chip to AVR it works instantly. So network and GW are not the issue.

Any suggestions what to measure/change?

Node:

898097 TSM:FAIL:RE-INIT
898097 TSM:INIT
900098 THA:INIT
900098 TSM:INIT:TSP OK
900098 TSM:INIT:STATID=100
900100 THA:SAD:ADDR=100
900101 TSF:SID:OK,ID=100
900102 TSM:FPAR
900102 THA:SND:MSG=6464FF020307FF
900133 THA:SND:MSG LEN=7,RES=1
900133 ?TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
904134 !TSM:FPAR:NO REPLY
904134 TSM:FPAR
904134 THA:SND:MSG=6464FF020307FF
904153 THA:SND:MSG LEN=7,RES=1
904153 ?TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
908153 !TSM:FPAR:NO REPLY
908153 TSM:FPAR
908153 THA:SND:MSG=6464FF020307FF
908172 THA:SND:MSG LEN=7,RES=1
908172 ?TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
912173 !TSM:FPAR:NO REPLY
912173 TSM:FPAR
912173 THA:SND:MSG=6464FF020307FF
912191 THA:SND:MSG LEN=7,RES=1
912192 ?TSF:MSG:SEND,100-100-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
916192 !TSM:FPAR:FAIL
916192 TSM:FAIL:CNT=7
916192 TSM:FAIL:DIS
916193 TSF:TDI:TSL

gateway

0;255;3;0;9;26409142 TSF:MSG:READ,100-100-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;26409149 TSF:MSG:BC
0;255;3;0;9;26409152 TSF:MSG:FPAR REQ,ID=100
0;255;3;0;9;26409155 TSF:PNG:SEND,TO=0
0;255;3;0;9;26409159 TSF:CKU:OK
0;255;3;0;9;26409162 TSF:MSG:GWL OK
0;255;3;0;9;26409388 TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;26413162 TSF:MSG:READ,100-100-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;26413168 TSF:MSG:BC
0;255;3;0;9;26413171 TSF:MSG:FPAR REQ,ID=100
0;255;3;0;9;26413175 TSF:CKU:OK,FCTRL
0;255;3;0;9;26413178 TSF:MSG:GWL OK
0;255;3;0;9;26413325 TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;26417182 TSF:MSG:READ,100-100-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;26417188 TSF:MSG:BC
0;255;3;0;9;26417191 TSF:MSG:FPAR REQ,ID=100
0;255;3;0;9;26417196 TSF:CKU:OK,FCTRL
0;255;3;0;9;26417199 TSF:MSG:GWL OK
0;255;3;0;9;26417269 TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;26421201 TSF:MSG:READ,100-100-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;26421209 TSF:MSG:BC
0;255;3;0;9;26421211 TSF:MSG:FPAR REQ,ID=100
0;255;3;0;9;26421215 TSF:CKU:OK,FCTRL
0;255;3;0;9;26421219 TSF:MSG:GWL OK
0;255;3;0;9;26422238 TSF:MSG:SEND,0-0-100-100,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0

RS485 data is different to serial api. Serial api is only from gateway to controller.
Please check links in 1st post.
https://forum.mysensors.org/topic/1947/rs485-rs232-serial-transport-class-for-mysensors-org

Yes, no real EERPOM, but emulation in flash. EEPROM failure was the first finding when checking for this error message. Maybe somthing else...
Now complete sketch is ported from AVR ProMini to STM32 and is runnig fine :+1:

This helped a lot! Got the serial to work. But...

13:29:37.828 ->  __  __       ____
13:29:37.828 -> |  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
13:29:37.862 -> | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
13:29:37.862 -> | |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
13:29:37.862 -> |_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
13:29:37.862 ->         |___/                      2.4.0-alpha
13:29:37.862 -> 
13:29:37.862 -> 18 MCO:BGN:INIT NODE,CP=RNNNM---,FQ=72,REL=0,VER=2.4.0-alpha
13:29:37.862 -> 29 !MCO:BGN:HW ERR

Looks like these cheap blue pills have some issue with EEPROM?

I later connected a Maple Mini board, which goes straight to "loop" as expected.

I struggle since 2 days to get a node based on STM32 to run. It is my first test with STM32. I installed the arduino libs. I can upload "blink" and this works, serial output also.
But when I include <MySensors.h> the STM seems not to start/run. LED doesn't blink, no output on serial. I would expect some some lib prints on serial, but nothing.
Compile and upload is with no error.
It doesn't matter if radio is connected or not.
Any special things need to be considered for STM32?

#define MY_DEBUG            //MYSENSOR Lib

#define   MY_TRANSPORT_WAIT_READY_MS   100

#define MY_NODE_ID 49 // id of the node
//#define MY_PARENT_NODE_ID 55
//#define MY_PARENT_NODE_IS_STATIC



// ++++++++++++++ NRF24 +++++++++++++++++
#define MY_RADIO_NRF24

// This is needed if you use an STM32 board:
#define MY_RF24_CE_PIN PB0


#define MY_DEBUGDEVICE Serial1

#include "MySensors.h"
#include <SPI.h>


/////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////// BEFORE ////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

void before()
{
  Serial1.begin(115200);
  Serial1.print("before");
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////// SETUP ///////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

void setup()
{
  Serial1.begin(115200);
  Serial1.print("setup");
  
  pinMode(PC13, OUTPUT);
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////// LOOP ////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

void loop()
{

  digitalWrite(PC13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(PC13, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second


}

I've opened an issue for that.
https://github.com/mysensors/MySensors/issues/1452

According to API payload is same on ECHO message.
I feel this should be handled/fixed in lib, but I have no idea how to do...
If it is not possible to fix in lib, it shall not be allowed to send message with no payload anymore, which controller has to make sure then.
@rejoe2
Regarding FHEM, at the moment we should keep it as it is. No payload is not the normal use case.
I flashed gateway with 2.2.0 and this fixed the problem for me.

All tests are done with nRF24 radio only.

Same with ethernet gateway (UNO, W5100)

gateway 2.2.0

10:25:06.047 -> 73634 GWT:RFC:MSG=70;0;1;1;47;
10:25:06.047 -> 73639 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:
10:25:06.088 -> 73652 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=0,sg=0:
10:25:06.088 -> 73657 TSF:MSG:ACK

MYSController

13.11.2020 10:25:06	TX	70;0;1;1;47;
13.11.2020 10:25:06	RX	70;0;1;1;47;

gateway 2.3.2

10:30:45.718 -> 22546 GWT:RFC:MSG=70;0;1;1;47;
10:30:45.718 -> 22550 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
10:30:45.718 -> 22561 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
10:30:45.718 -> 22566 TSF:MSG:ECHO

MYSController

13.11.2020 10:30:45	TX	70;0;1;1;47;
13.11.2020 10:30:45	RX	70;0;1;1;47;0

Now I have to look for some ESP board...

I again checked with latest 2.3.2 development lib. Same, ECHO does not work.
You use ethernet gateway, my is serial. This might be the difference...

13.11.2020 09:17:20	TX	70;0;1;1;47;
13.11.2020 09:17:20	RX	0;255;3;0;9;10969 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
13.11.2020 09:17:20	RX	0;255;3;0;9;10989 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
13.11.2020 09:17:20	RX	0;255;3;0;9;11008 TSF:MSG:ECHO
13.11.2020 09:17:20	RX	70;0;1;1;47;0

I now try to setup an ethernet gateway just for test.

Is 2.3.2 running on your GW?
I see different behaviour between 2.3.2 and old 2.2.0.
With 2.3.2 on GW I see ECHO problems, with 2.0.0 everything is fine.
First running a 2.3.2 GW, then switch to a 2.2.0 GW.
The 2.3.2 version is adding a "0", which causes problems.

12.11.2020 22:24:11	TX	70;0;1;1;47;
12.11.2020 22:24:11	RX	0;255;3;0;9;41152 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
12.11.2020 22:24:11	RX	0;255;3;0;9;41174 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
12.11.2020 22:24:11	RX	0;255;3;0;9;41192 TSF:MSG:ECHO
12.11.2020 22:24:11	RX	70;0;1;1;47;0
12.11.2020 22:25:10	INFO	Disconnected
12.11.2020 22:25:24	INFO	Flushing FIFO
12.11.2020 22:25:24	INFO	Connected to COM4
12.11.2020 22:25:29	TX	70;0;1;1;47;
12.11.2020 22:25:29	RX	0;255;3;0;9;192065 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:
12.11.2020 22:25:29	RX	0;255;3;0;9;192088 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=0,sg=0:
12.11.2020 22:25:29	RX	0;255;3;0;9;192106 TSF:MSG:ACK
12.11.2020 22:25:29	RX	70;0;1;1;47;

@frits, can you please check, if MySController reads correct ECHO from a no payload message? I have some ECHO problems, when sending with no payload. But maybe FHEM related...

@frits thanks for supporting. This works.

Debug does not help. According to debug payload is empty "" (or space). When I get the payload in receive() it reads "]".

I have this LED matrix to display time and text https://forum.mysensors.org/post/102819.
Text is sent from controller (fhem), time is only requested once from node and the runs only on node.
To switch from text to time, controller sends "" (no text). Node checks received data for NULL.

strcpy(tempMessage, message.getString());        // copy it in
      if (tempMessage[0] == NULL) {                    //time

I didn't use the text option for a long time. Now it does not work anymore.
If controller sends "", node receives "]" and this does not work with NULL.
Did anything change in MySensors?
How can I debug what raw data is received? Maybe some changes on controller side...

@sundberg84 - yes, it's just a 16bit incrementing counter. It counts all NACKs as long as the node is not reset.
Before node goes to sleep, node sends the total number of NACKs. I'm using V_ID for that. Controller (FHEM) calculates then delta NACKs between two sends -> "lost messages". The lost messages are counted day by day separately. So I can easily see when during the day the lost messages rise and can also compare values day by day.
I'm not using presentation that much. For most nodes I configure the controller manually. So I'm more flexible in which variables I can use in which context.