I am using 7 Modulino modules on the Arduino UNO Q STM32 I2C bus.
Six modules are working without any problem.
If I add the Light module in my application the system is crashing. Compiling and linking of the Light module - not calling begin() or using it - is enough.
Inside of the Modulino library a static instance is getting used:
Sorry, I don't have your hardware, nor your program to look at, but
creating a new App in App lab, with just:
#include <Arduino_Modulino.h>
#include <Arduino_LTR381RGB.h>
void setup() {
Serial.begin(115200)
// put your setup code here, to run once:
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
delay(500);
}
Does not crash as far as I can tell. Nothing in monitor and the LED is blinking like once per second.
Now if I add in the begin like some of their examples:
#include <Arduino_Modulino.h>
#include <Arduino_LTR381RGB.h>
void setup() {
Serial.begin(115200);
// put your setup code here, to run once:
pinMode(LED_BUILTIN, OUTPUT);
if (!RGB.begin()) {
Serial.println("Failed to initialize rgb sensor!");
while (1);
}
}
void loop() {
// put your main code here, to run repeatedly:
digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
delay(500);
}
It fails in the RGB.begin() as I don't have one and then prints out
error message and loops for ever, looking like it is hung.
Now on UNO Q Serial goes currently out to the Hardware Serial object that uses pins 0, 1.
I have a USB to Serial Adapter hooked up to it with a Terminal window connected and
sure enough I see:
*** Booting Zephyr OS build v4.2.0-44-g7cfc53a6f3fc ***
Invalid sketch header
Failed to initialize rgb sensor!
Which is as the program specified and Now I don't have blinking LED
Hi @qudorino. Please provide the contents of the App's sketch/sketch.ino file. I'll provide instructions you can follow to do that:
Open the App in Arduino App Lab.
Click the ▸ icon next to the "sketch" folder item under the "Files" section of the left hand panel in the Arduino App Lab window.
The item will expand to show the contents of the sketch folder.
Select "sketch.ino" from the list of contents of the folder. sketch.yaml will open in the editor panel of the Arduino App Lab window.
Click on the editor panel.
Press the Ctrl+A keyboard shortcut (Command+A for macOS users).
The contents of the editor panel will be selected.
Press the Ctrl+C keyboard shortcut (Command+C for macOS users).
This will copy the selected text to the clipboard.
Open a reply here on this forum topic by clicking the "Reply" button.
Click the <CODE/> icon on the post composer toolbar.
This will add the forum's code block markup (```) to your reply to make sure the content is correctly formatted.
2. Open IDE 2.3.X or App Lab 3. Upload the above sketch @KurtE . 4. Open (another) IDE from Start icon. 5. Detect the Serial port (0, 1) at the correct COM Port. 6. Open Serial Monior at Bd = 115200. 7. Read the message that has appeared on the Outputox of Serial Monitor.
bool FactoryC::Begin(void)
{
printLn("\n\nFactory Begin \n\n");
bool ok{true};
mButtonsDrv.Begin();
mBuzzerDrv.Begin();
mDistanceDrv.Begin();
mKnobDrv.Begin();
//mLightDrv.Begin(); --> no crash
mPixelsDrv.Begin();
mThermoDrv.Begin();
return(ok);
}
bool FactoryC::Begin(void)
{
printLn("\n\nFactory Begin \n\n");
bool ok{true};
mButtonsDrv.Begin();
mBuzzerDrv.Begin();
mDistanceDrv.Begin();
mKnobDrv.Begin();
mLightDrv.Begin(); --> now crashing
mPixelsDrv.Begin();
mThermoDrv.Begin();
return(ok);
}
#include "LightDrv.h"
#include <Modulino.h>
LightDrvC::LightDrvC()
: mLight{}
{
}
// I use a tiny wrapper to be later extended (LightDrvC is nothing doing for now):
// The bass class is responsible to initialize the "modulino lib" once,
// independent how the Begin() call order of the other six drivers are:
#include "ModulinoBase.h"
#include <Modulino.h>
#include "../Trace/Log.h"
bool ModulinoBaseC::mInitDone{false};
void ModulinoBaseC::ModulinoBegin(void)
{
printLn("\n\nModulino Base Begin \n\n");
if(not mInitDone)
{
printLn("\n\nModulino Begin \n\n");
mInitDone = true;
Modulino.begin();
}
}
void LightDrvC::Begin(void)
{
ModulinoBegin();
mLight.begin();
}
I do not allocate any dynamic memory in my application code.
The memory footprint of my application class are ~1.500 bytes.
With the terminal the following happen if I enable one line code:
The trace output is telling me, that the root cause could not easy be found. I think it
is not the first time I am running into this problem. I have rearranged my code many times again and again. If I rearrange my code it is running for a longer time stable till adding something simple the next crash is there.
That is useful information, but it is the contents of the sketch/sketch.yaml file. I asked you to provide the contents of the sketch/sketch.ino file (note the .ino file extension).
Please provide that information and I'll investigate.
I see. I recommend you create a sketch that contains only the absolute minimum amount of code required to produce the crash.
I find that often by the time I have completed this work the cause of the fault has become clear to me. Even if it doesn't, you can then share that "MCVE" here on the forum. It is likely that information will enable us to more effectively investigate and assist.
This often implies to me, there is an underlying problem with the code, either in system, or libraries, or your code. Some of the common ones I have run into include:
a) you write outside the bounds of an array: for example like:
uint8_t my_array[3];
...
my_array[3] = 0;
Or potentially worse, negative index.
b) using an uninitialized variable.
c) running out of memory, like stack space, which could be by recursion or having large arrays on the stack... Sometimes it causes the stack to run into the global variables, which get clobbered.
...
But your crash report may give you some insights on where it crashed!
You might be able to gain some information, from looking at the output
from the build.
For example if run an app on my Q4, lets say my weather2
If you open up a command prompt to your Q. Not sure how you are running it, but if connected to pc, could use the >_ icon bottom leftish of screen.
And look in the apps .cache directory like at: ~/ArduinoApps/weather2/.cache/sketch
Obviously change weather2 to your app name.
I don't remember if addr2line command is installed automatically or not, but
if it works, it might give hint, if not maybe the map files.
However with applab builds not sure how much information one can get here.
@ptillisch - So far it looks like the map file here is sort of useless? That is it only has the actual code of sketch within it and addressed based from 0. Also I don't believe that the zephyr.map (Built as part of the "bootloader" is included anywhere?). I am running on my own build. Do you know of a good document/post that might describe some of this? Thanks!
However if you can setup to build and install your sketch on Arduino IDE2,
you can have a better chance at looking at your crash locations. That is if you look at the build options:
If you use the default options for Link Mode, you will get similar results for the addresses. However if you use the option value "Static", it no longer links your code through links and the like, which gets redirected during the load of your sketch, instead it is built with real addresses, and if you get a crash you can look at the map file and get better ideas of where that
address is located in your code, or libraries or ...
And likewise maybe where the address you are trying to access might be...
looks like allot of code..
curious, what is the size of the sketch.ino.elf file??
typically located inside of the /.cache/sketch folder for the project..
good luck.. ~q
At the end for a STM32 with a flash size of 2 times 1MB the footprint is a don't care.
I work with co-routines (protothreads) so my estimated stack size is in a range of
100...300 Bytes. I do not know how huge the stack of the Zephyr-Arduino main thread is.
But I expect to be far away of using k Bytes. My application itself is using with library
instances inside (Modulino) not more than 1.5 kBytes (STM has >700 k SRAM). I never use malloc()/free() to get memory.
I have made class by class code review with ChatGPT but currently no hint about the crash root-cause. Soon or later I will find the bug.
just did a quick check..
the actual file that gets uploaded is sketch.elf-zsk.bin, pretty sure you will find it is the same size..
with core 0.54.1 that file can not be no more than 131072 bytes in size if you are running it from AppLab, you could load it into flash using Arduino IDE..
this was changed in the core just 2 days ago so next release this shouldn't be a limit..
your elf looks like it is under this limit but you are close, is this size with everything or with the offending code commented out??
is the bin file the same size as elf??
What kind of limit are the 131072 bytes? Is the code getting loaded into the SRAM? The MCU has got > 700k SRAM. Zephyr and Arduino libs are using together ~600k SRAM?
Are there documents explaining the limits?
Available stack size for the Arduino-Zephyr main thread. I have put a 1024 byte test array onto the stack and it has worked. My stack-less co-routines are not consuming a huge stack. But yes, I have no glue what Arduino code is doing.
Available heap for application.
Done a carefully malloc and free test (only for testing) to investigate the heap. Has worked.
For embedded programming the STM32U585 is a "big" MCU!
I do not want to work with different IDEs. In need to update on Linux the Python code and the Arduino C++ code in one cycle. If I have investigated the Arduino UNO Q web side I liked the concept to use Linux with Python and the Arduino side in one IDE. And very important, having a powerful embedded MCU on-board, on the same PCB with a communication channel.
Lets see what Arduino/Qualcomm wants to do with the Arduino UNO Q.
It is the App Lab interface that supports both Python Programming (script) for MPU and Arduino Programming (sketch) for MCU. The IDE supports only the Arduino Programming of the MCU.
If using IDE, then there is a option for sketch loding into Flas/RAM.
If using App Lab, the sketch is always loaded into RAM.
Further investigation revealed that my Arduino application wasn't being loaded correctly into the MCU. The crash occurred before a single line of my code could be executed—likely due to the 132k limit. I waited for the updates (IDE 0.70, etc.), and sure enough, everything now boots without crashing.
Without the dump you know nothing. Soon or later I will find the bug.