Freezing at boot

[HamzaHajeir]

Hi there,

I'm trying to port the H4Plugins system into RP2040, however, it went successfully for most of the stack, including H4AsyncTCP and H4AsyncMQTT, but not for the H4Plugins, which have some issues in running constructors.

The behavior goes the Serial device not shown up after flashing, should be something related to an exception/error in running constructors.

At constructors, I've noticed two sources of issues: platform-specific, and general C++ code.

• The platform-specifics being two commands run at global constructor:
  • digitalRead().
  • WiFi.macAddress().

This MCVE confirms that, as any invokation of one of the two commands result in the failure:

#include <Arduino>
#include <WiFi.h>
struct S{
    S() {
		Serial.begin(115200);
		Serial.println(WiFi.macAddress());
		Serial.printf("%d\n", digitalRead(D12));
	}
} s;

void setup() {}
void loop() {}

• Some complex C++ data structures APIs.

This is less understandable, the same code runs perfectly for ESP32 and ESP8266, but fails for the RP2040, my guess goes towards some compilation flags...

This is the line which fails.

Having some analysis, it's calling the array index operator [] of the map where it does not find the element(as it appears). So had this one working by changing direct index operator into two cases as the following:

    auto p = make_pair(svc,f);
    H4P_EVENT_LISTENERS value;
    if (h4pevt.count(inst)) {
        H4P_EVENT_LISTENERS& listeners = h4pevt.at(inst);
        value = listeners; // take a copy
        value.push_back(p);
    } else value.push_back(p);
    h4pevt.insert_or_assign(inst,value);

Note that the data structure of h4pevt is:

std::map<uint32_t,  std::vector<std::pair<std::string, std::function<...>>

Any however, this freez applies for both rpipico and rpipicow.

Any comments/suggestions for this issue?

With Thanks,
Hamza Hajeir

[earlephilhower]

You're using undefined C++ behavior with the global constructor, and things are going pear shaped. C++ does not specify which order global constructors are called. Your struct s is trying to use Serial before it is created and well before USB is actually configured by the main() routine. Move the constructor to a method and call that method from setup().

[HamzaHajeir]

Great, and here we go.

BTW here an issue regarding tweakened MCVE:

struct T {
	String str;
	bool b;
	T(){
		// str = std::string(WiFi.macAddress().c_str()).c_str(); // LINE 0
		str = WiFi.macAddress(); // LINE 1
		b = digitalRead(D12);
	}
} t;
		
void setup() { 
    Serial.begin(115200); 
   // t.str = WiFi.macAddress();  // LINE 2
}
void loop() { 
    delay(1000);  
    Serial.println(t.str); 
    Serial.println(t.b);
}

• When uncommenting LINE 0 (LINE 1 commented), the failure appears, where it shows no interactions with globals.
• Activating LINE 1 only: Runs (with invalid value "00:00:00:00:00:00").
• Activating LINE 1 + LINE 2: Failure reappears.

And finally, why such issues did not appear in ESP32/ESP8266? Is it some compiler options? or a way the compiler being configured?

I'll announce here when I finalize merging the support for RP2040 ;)

[earlephilhower]

Again, that's a global constructor that's using another global object. There are no ordering guarantees for globals, that's not part of the C++ spec. (In reality it depends on the ordering of the ctor array values by the linker, but that's implementation dependent.)

If it works on the 8266 compiler then you're just lucky and it's perfectly possible/legal for it to fail whenever anything (or nothing) changes.

So, in a nutshell, having global objects is fine but not if their constructors need to use anything other than new or standard C library calls. That's why all the Arduino global objects require a begin() call in your code before use vs. having them come up automatically.

[HamzaHajeir]

Again, that's a global constructor that's using another global object. There are no ordering guarantees for globals, that's not part of the C++ spec. (In reality it depends on the ordering of the ctor array values by the linker, but that's implementation dependent.)

Makes sense.. I guess the other platforms (ESP8266/ESP32) do prioritize constructing globals of other sources before the ones in main.cpp, inverse to what RP platform do.

But per the example, part WiFi.macAddress() in which LINE 1 alone does work (although holding incorrect data), but it fails when reassigning it in setup(). Is it some form of ordering issue at global constructors?

[earlephilhower]

Once again, please do not call other object methods in your global constructors. Maybe it won't crash, maybe it will, or maybe it will cause things to fail later on in interesting ways. It's just not legal and it's unpredictable.

FWIW, the way MAC addresses work here, since we support lots of wired Ethernet and WiFi chips (not just the CYW43 on the PicoW), they are not assigned until the network interface comes up. So you're going to get a bogus MAC until a ::begin on WiFi in setup or loop.

[HamzaHajeir]

Once again, please do not call other object methods in your global constructors. Maybe it won't crash, maybe it will, or maybe it will cause things to fail later on in interesting ways. It's just not legal and it's unpredictable.

This was already my approach to get it working, what I was looking for is to deeply understand the issue, might be an issue in the String object itself, or just a result of the compiling/linking process.

FWIW, the way MAC addresses work here, since we support lots of wired Ethernet and WiFi chips (not just the CYW43 on the PicoW), they are not assigned until the network interface comes up. So you're going to get a bogus MAC until a ::begin on WiFi in setup or loop.

Understood that.

Finally thank you for your help.