Coder Social home page Coder Social logo

Comments (6)

maxgerhardt avatar maxgerhardt commented on June 12, 2024

When you upload a blinky firmware in the current configuration (and not start debugging), does that run?

from arduino-pico.

rivimey avatar rivimey commented on June 12, 2024

I thought about that, and to verify I can upload and run something correctly I compiled a blinky in Rust (because doing so uses only a rust compiler toolchain). This worked fine, no problems.

Is that what you meant?

from arduino-pico.

maxgerhardt avatar maxgerhardt commented on June 12, 2024

Not really, I meant a blinky written with this regular Arduino-Pico core. It should be flashable via the cmsis-dap protocol, setup as you now have.

#include <Arduino.h>
#define LED LED_BUILTIN // or whatever
void setup() { pinMode(LED, OUTPUT); }
void loop() { digitalWrite(LED, digitalRead(LED) ^ 1); delay(1000); }

from arduino-pico.

rivimey avatar rivimey commented on June 12, 2024

Aside: before I used platformio, I compiled my project using a simple Makefile with compiler flags cribbed from an Arduino build; this built and linked ok but also failed in the crt0 code in what seems to be a very similar way. The switch to platformio was supposed to avoid the 'handcrafted' aspect of this build. Sadly this doesn't seem to have worked.

I will say I'm not doing anything at all weird, especially in during crt0/start/main startup. There are some c++ constructors which could perhaps start doing something but as far as I know that happens after crt0, not during.

from arduino-pico.

earlephilhower avatar earlephilhower commented on June 12, 2024

Without a full MCVE we're really just guessing here and not likely to get down to the root cause, but...

I will say I'm not doing anything at all weird, especially in during crt0/start/main startup. There are some c++ constructors which could perhaps start doing something but as far as I know that happens after crt0, not during.

C++ constructors are all called as part of the C++ runtime initialization, in random order. If a C++ global object constructor uses another global object there is no guarantee that the called object's constructor will have been called. Recipe for confusion, at least, or a crash, more likely.

That said, please run @maxgerhardt 's very basic blink example and verify that works. If it does, there's a problem in the crashing app's code. If blink doesn't work, there's a toolchain config problem (wrong flash type specified, maybe?)...

from arduino-pico.

rivimey avatar rivimey commented on June 12, 2024

Thanks both for your suggestions, appreciated. I first tried the blinky code (by replacing src/* with a cpp file containing that code) and it worked fine.

I then tried reinstating all my project's code (except u8g2 and the display thread on core 1) but commenting out any line that could cause code execution, so both of the global c++ objects (one for each core) and so on. I then included the lines from blinky so it would run that within the context of my code. That worked too.

I then re-enabled one core's global constructor, and it failed immediately, as (now) expected. It seems the point about constructor initialisation is well made, though I'm unsure if this is about ordering or not, as there is only one global constructor being enabled here.

I then made the global object a pointer, with an initialisation within arduino setup(). That also worked (in so far as it didn't crash -- there was still no loop() code and all the non-trivial setup code was commented out too).

I then thought I would single-step through the setup() code, see what was happening. So, in debug mode, set a breakpoint in setup() and upload. It stopped at the beginning of the framework's main.cpp as expected. I click on 'step' once and it dies with "trap 6". I can't see anything else wrong in the log, and a breakpoint set a couple of lines later in main() [on the freeRTOS check line] is not hit.

A thought: Could this trap be something to do with debug compile or link settings?

Fatal signal: 
Abort trap: 6

----- Backtrace -----
Backtrace unavailable
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

Out of all this I am somewhat confused why bad/faulty app code can cause a crash in crt0 code -- is this just about c++ initialisation doing unexpected things or is something else going on?

from arduino-pico.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.