I have a project that have a very crazy BUG.
When I upload the project it WORK. But when I put it on RUN MODE it start Blinking the PB0 pin, and doest’t run the CODE.
I also notice that when the program going to STOP WORKING in RUN MODE the MILLIS() function don’t work propely.
The most strange is that the Differenct one program that DON’T work on RUN MODE of the other that don’t WORK on RUN MODE is almost nothing:
THIS CODE RUN (ON RUN MODE):
if (buttonNumber == 0 && buttonState != 1) // TURN OFF RED LIGH ON POWER
{
digitalWrite(io_led[11], HIGH);
}
if (buttonNumber == 0 && buttonState != 0) // TURN ON RED LIGH ON POWER
{
digitalWrite(io_led[11], LOW);
}
You eventually overwrite some reserved pins for something else (for example USB).
How do you initialize this array?
I suggest you to use the pins in PXY form (PA1, PC13) instead of raw numbers (1, 13).
[gasparobr – Thu Feb 22, 2018 2:11 pm] –
Serial.println(Serial(F(“Teste”))); <= This doesn’t WORK
I think it is normal that it does not work.
What exactly do you want to achieve with that?
If you wish to know what the “F” macro does, this is a good explanation: http://forum.arduino.cc/index.php?topic=91314.0
Serial.println(Serial(F("Teste"))); <= This doesn't WORK
The definition of the IO_LED:
const int io_led[18] = {PC6, PG6, PG8, PG5, PG7, PD13, PD15, PD12, PD14, PG4, PG3, PC7, PG2, PB12, PD11, PD10, PB14, PB13};
[Rick Kimball – Fri Feb 23, 2018 1:37 am] –
What is RUN mode?
Rick,
I took it to mean moving BOOT0 from +3.3 (upload) to Gnd (normal/run?). But Opt never specifically stated that.
Ray
[gasparobr – Fri Feb 23, 2018 1:14 am] –
…
The definition of the IO_LED:
const int io_led[18] = {PC6, PG6, PG8, PG5, PG7, PD13, PD15, PD12, PD14, PG4, PG3, PC7, PG2, PB12, PD11, PD10, PB14, PB13};
Which upload method do you use?
[stevestrong – Fri Feb 23, 2018 9:32 am] –
So first please tell us what is RUN mode and what is JUST AFTER UPLOAD.Which upload method do you use?
RUN MODE: is when PUT BOOT 0 at RUN MODE.
JUST AFTER UPLOAD: when the BOOT 0 is on UPLOAD MODE and upload the FIRMWARE from SERIAL the program RUN automatically.
In the SECOUD CASE all the codes WORK without problems (with a little bug on the millis() timer);
In the FIRST CASE just one code WORK, the other make the PB1 OUTPUT Blinking.
I hope I could be clear this time!
THANKS for the attention!
It is not just that code that made it BUG. There is a function, that NEVER IS CALLED in the program, that when I put it in any place it stop work at the same why:
EX:
if(false) // CODE NEVER RUN!!
{
functionAbc(); // THIS MAKE THE PROGRAM STOP WORKING WHEN ON RUN MODE - (BOOT 0 ONRUN), BUT WORK AFTER UPLOAD, the first time.
}
//The sketch uses 145500 bytes (27%) of storage space for programs. The maximum is 524288 bytes.
//Global variables use 17192 bytes of dynamic memory.
I think I may have an old blue board. Mostly, I have moved beyond the STM32 into the ESP32 66 and on to the ESP32 which is where I spend much of my play time. Also, the rPi_Zero-W. So, when I answer a question in this forum, I am basing it on 18 month old experiences. .. unless I go down to my little lab, pull a Maple Mini out of the drawer and hook it up to my Linux development notebook.
I am a bit perplexed over the issues you are having. Initially, years sgo, I wrote/ported all of the General Examples for the Maple. I have not seen any of the strangeness you report … is there any chance your development PC is using a different version of the tool chain? The STM32DUINO should be using the “Arduino Due” Tools installed via the ArduinoIDE.
Ray
PS… I think someone in the forum proved long ago that non-called functions were eliminated by the compiler. If I can find a blue board, I am going to run the code fragment on it.
List of boards being used: http://wiki.stm32duino.com/index.php?ti … 103_boards
