Generic Board STM32G031J6, issues with starting the downloaded code (pinMode hangs)

[olikraus]

Please, before reporting any issue

• Make sure you are using the latest Arduino_Core_STM32 version.
  https://github.com/stm32duino/Arduino_Core_STM32/releases/latest
  Oliver: I have installed Arduino Core STM32 last week (2.2.0)
• Make sure the issue is not already reported/fixed on GitHub or discussed on the stm32duino forum
  Oliver: I have looked for similar problems for STM32G031 but the total number of entries for the STM32G031 is very much limited and do not fit to my case
• Submit a GitHub issue only for reporting a problem related to the Arduino_Core_STM32.
  Oliver: Difficult to say, but I assume it is a problem within Arduino_Core_STM32
• Avoid to submit a GitHub issue for project troubleshooting.
  Oliver: I have partly modified Arduino_Core_STM32 as a workaround (see below) and my project is just the Arduino "blink" example.

Any questions/feedback/suggestions should be discussed on the stm32duino forum:

• questions on the STM32 Core
• bugs/enhancements on the STM core: Bugs and enhancements

⚠ When reporting any issue, please try to provide all relevant information to help on its resolution.

Describe the bug

1. After successful upload, the code (Arduino Blink) is not executed by STM32CubeProgrammer (Running the code after upload does not work)
2. After hardware reset, the code (Arduino) is not executed

To Reproduce

Steps to reproduce the behavior:

1. Open the Arduino Blink example
2. Upload the Arduino Blink example
3. Check whether the LED blinks
4. Reconfigure target to execute the newly flashed code
5. Execute a hardware reset on the target
6. Check whether the LED blinks

Note: I will provide more information with partial findings below in this issue

Expected behavior
The code should be executed from STM32CubeProgrammer and after hardware reset

Screenshots
Here is the protocol of the successful upload (I can provide more screenshots on request)

sh /home/kraus/.arduino15/packages/STMicroelectronics/tools/STM32Tools/2.1.1/stm32CubeProg.sh 1 /tmp/arduino_build_310859/Blink_stm32g0.ino.bin ttyUSB0 -s 
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.9.0                  
      -------------------------------------------------------------------

Serial Port ttyUSB0 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1,0, flow-control = off
Activating device: OK
Board       : --
Chip ID: 0x466 
BootLoader protocol version: 3.1
Device name : STM32G03x/STM32G04x
Flash size  : 64 KBytes (default)
Device type : MCU
Revision ID : --  
Device CPU  : Cortex-M0+

Memory Programming ...
Opening and parsing file: Blink_stm32g0.ino.bin
  File          : Blink_stm32g0.ino.bin
  Size          : 10332 Bytes
  Address       : 0x08000000 

Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 5]
Download in Progress:

File download complete
Time elapsed during download operation: 00:00:01.626

RUNNING Program ... 
  Address:      : 0x8000000
Start operation achieved successfully

Desktop (please complete the following information):

• OS: Ubuntu Linnux
• Arduino IDE version: 1.8.19
• STM32 core version: 2.2.0
• Tools menu settings if not the default: [e.g. Newlib Standard, No Serial]
  • Board: Generic STM32G0 series"
  • Board part number: Generic G031J6MX
  • USART support: Enabled
  • C Runtime Library: Newlib Nano (default)
  • Upload method: STM32CubeProgrammer (serial)
  • Port: /dev/ttyUSB0

Board (please complete the following information):

• Name: Generic STM32G031J6
• STM32G031J6 with BOOT0 pin enabled (https://github.com/olikraus/stm32g031/tree/main/enable_boot0) and reset pin disabled (https://github.com/olikraus/stm32g031/tree/main/disable_nrst)
• USB USART converter connected to PA11/PA10 (pins 5&6)
• LED connected to PA13

Additional context
LED at PA13 (pin 7 of the SO8N )
I assume pin 7 of the SO8N can be accessed by Arduino pin number 6 (

Arduino_Core_STM32/variants/STM32G0xx/G031J(4-6)M_G041J6M/variant_generic.cpp

Line 25 in b8756be

PA_13, // D6/A5

)
So my initial code looks like this (didn't execute):

#define MYPIN 6

void setup() {
  pinMode(MYPIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
  digitalWrite(MYPIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(MYPIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

Bypassing pinMode and digitalWrite

To debug this, I have bypassed pinMode and digitalWrite:

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
    //pinMode(MYPIN, OUTPUT);
  GPIOA->MODER &= ~GPIO_MODER_MODE13;  /* clear mode for PA13 */
  GPIOA->MODER |= GPIO_MODER_MODE13_0;  /* Output mode for PA13 */
  GPIOA->OTYPER &= ~GPIO_OTYPER_OT13; /* no Push/Pull for PA13 */
  GPIOA->OSPEEDR &= ~GPIO_OSPEEDR_OSPEED13; /* low speed for PA13 */
  GPIOA->PUPDR &= ~GPIO_PUPDR_PUPD13; /* no pullup/pulldown for PA13 */
  //GPIOA->BSRR = GPIO_BSRR_BR13;   /* atomic clr PA13 */
  GPIOA->BSRR = GPIO_BSRR_BS13;    /* atomic set PA13 */
}

// the loop function runs over and over again forever
void loop() {
  //digitalWrite(MYPIN, HIGH);   // turn the LED on (HIGH is the voltage level)
    GPIOA->BSRR = GPIO_BSRR_BS13;    /* atomic set PA13 */
  delay(1000);                       // wait for a second
  //digitalWrite(MYPIN, LOW);    // turn the LED off by making the voltage LOW
    GPIOA->BSRR = GPIO_BSRR_BR13;    /* atomic clr PA13 */
  delay(1000);                       // wait for a second
}

This code is also not executed, however if -DUSER_VECT_TAB_ADDRESS is used as compiler arguments, then the code gets executed successfully.

I have added this dlag to

Arduino_Core_STM32/platform.txt

Line 31 in b8756be

compiler.extra_flags=-mcpu={build.mcu} {build.flags.fp} -DUSE_FULL_LL_DRIVER -mthumb "@{build.opt.path}"

like this:

compiler.extra_flags=-mcpu={build.mcu} {build.flags.fp} -DUSE_FULL_LL_DRIVER -mthumb "@{build.opt.path}" -DUSER_VECT_TAB_ADDRESS

This will at least start the above code (blink works), however:

• any call to pinMode() will again crash the code
• Startup of the code via hardware reset still doesn't work (this means: STM32CubeProgrammer can start the code, but HW reset still doesn't work).

To me it looks like that SCB->VTOR is not setup correctly during startup for the STM32G031.
But there is another bug, because pinMode() still does not work and crashes the code.

Summary

• Everything works if only delay() is used and SCB->VTOR is assigned correctly
• A call to pinMode() will halt/crash the code

[ABOSTM]

Hi @olikraus,
Thanks for your detailed description.
I tried to reproduce your issue, but I have several concerns:

• I did not succeed to flash STM32G031J6 with USART(Pin5/6) of my STM32G0316-DISCO.
  According to AN2606, USART1 bootloader is available on PA9/PA10.
  but on SO8N, PA9/PA10 are not available, but rather PA11/PA12 (Pin5/Pin6).
  eventually, stm32g0 has the capability to remap PA11 so that it operates like PA9 (and similarly remap PA12 to operate like PA10).
  I am not sure that bootloader is able to manage this remap (enquiry ongoing).
  So my hypothesis, is that I have an old bootloader which was not able to manage remap, and you have a recent one, which manage the remap. To be confirmed.

• I made some tests with my Nucleo-G031k8. It is the same, i cannot flash over USART with remap pin PA11/PA12.

• But on this Nucleo-G031k8, PA9/PA10 are available. So I continue testing with PA9/PA10.
  As I understand, you initially clear option byte nBoot_SEL with you own program so that Boot0 pin is effective (instead of nBOOT0 option byte) and similarly you also disabled NRST pin by setting NRST_MODE= b10 in Option Bytes.
  In your sequence to reproduce this issue, you said:
  4. Reconfigure target to execute the newly flashed code
  Do you mean switch Boot0 pin from logical 0 to 1 ?
  5. Execute a hardware reset on the target
  As you deactivated NRST pin, you could not just act on this pin, so did you power OFF/ON instead ?
  On my side, BOOT0 pin is hardly accessible, so instead I used option Byte nBOOT0.
  So I configured it to run bootloader (nBOOT0=0). I upload the blinky Arduino sketch through usart, and after that, it appear that we are still in bootloader (which seems normal as nBOOT0 is still 0 ), this is confirmed by the fact I can connect with CubeProgrammer in Uart mode, thus I am able to change option byte nBoot0=1 and as soon as I apply it, Arduino code executes.
  So it look to me like there is no issue on my side.

According to your description, it looks like system is still in bootloader mode, which explains that arduino code doesn't executes. and when enabling USER_VECT_TAB_ADDRESS, the VTOR register is updated, which could lead to execution of code from flash.

• Concerning pinMode , I have no issue, all my tests above are made with pinMode and digitalWrite (just take arduino example as is). Maybe on your side, it is a side effect of being in Bootloader mode. So let's fix bootloader issue first.

[ABOSTM]

I finally succeed to flash my STM32G0316-DISCO, so I continue my investigations.
I now have access to BOOT0 pin so like you I disabled nBOOT_SEL, and I used BOOT0 pin.
And here is my finding:

1. Like you I disabled NRST pin: NRST_MODE=b10 (=2)

• I set BOOT0 = HIGH
• I upload Arduino blinky through Uart.
  At the end led doesn't blink as I am still in bootloader
• I switch BOOT0 = LOW
  led doesn't blink as I am still in bootloader (normal, a Reset is required)
• Due to NRST disabled, I power OFF/ON
  --> Led is blinking.

2. Contrary to you I enable NRST pin: NRST_MODE=b11 (=3)

• I set BOOT0 = HIGH
• I upload Arduino blinky through Uart.
  At the end led doesn't blink as I am still in bootloader
• I switch BOOT0 = LOW
  led doesn't blink as I am still in bootloader (normal, a Reset is required)
• I press the blue button on my Disco which toggles NRST
  --> Led is blinking.

So all seems to work properly

[olikraus]

UPDATE: This is the reply to your first response. Will read your second post soon.

Thanks for testing and your long answer.

You are correct, the option byte has to be modified as mentioned in my inital post. To make the USART upload available, the correct boot0 setup must be available.
As mentioned, I have cleared the boot selection bit:
https://github.com/olikraus/stm32g031/blob/e017b221bc534f08e080d7bd3ded5a41824e8bab/enable_boot0/enable_boot0.c#L78
As a consequence, I can use the BOOT0 pin to define whether to jump into bootloader or not.

As you deactivated NRST pin, you could not just act on this pin, so did you power OFF/ON instead ?

yes correct. I think the problem described here is not related to NRST, but I just wanted to describe my complete setup.
So as a conclusion: If I power on the STM32G0, it either executes flash or starts the bootloader depending on the bootloader.

So, this is the normal (expected) Arduino Upload process:

1. Code is compiled
2. Code is uploaded to flash memory of the target device
3. Code is executed

In my case I want to use "USART", so the precondition in my case is: The device must be in bootloader code and wait for USART upload commands.

All in all steps 1 and 2 work without problem. In fact STM32CubeProgrammer nicely uploads via USART.

My expectation is, that Arduino blink.c will get started after upload and the LED should start to blink.
However: This is not the case, the LED doesn't blink.

So what are possible failures could be here?

1. I have used the wrong pin number in blink.c
2. The code is uploaded to the wrong memory areay (RAM vs Flash???)
3. The code is not correctly started by STM32CubeProgrammer
4. Arduino framework has a bug (startup, delay, pinMode, digitalWrite)

At this point I think that there is an issue with stm32duino.

I started to some further investigation:

1. Arduino Pin Number for PA13? According to the source code, it could be 6, but I am not sure
2. I do not know whether STM32CubeProgrammer writes to RAM or Flash, but I assume it is flash only
3. Correct Startup.

Here I figured out, that avoiding pinMode and digitalWrite AND using -DUSER_VECT_TAB_ADDRESS will start the code on the target device.

So, as a conclusion:
I can compile and upload blink.c. I think I have used the correct pin number, but the blink does not work.

I am really happy you replied to this issue. It would be amazing if I could use stm32duino. Please let me what I can do to support the debugging here.

[olikraus]

I finally succeed to flash my STM32G0316-DISCO, so I continue my investigations.

Nice.

I press the blue button on my Disco which toggles NRST

This means, I always have to execute a manual reset, correct?

The question is, why does cubeprogrammer issue this message? My assumption is, that cubeprogrammer directly starts the just downloaded code without reset (which is very much possible).

RUNNING Program ... 
  Address:      : 0x8000000
Start operation achieved successfully

Moreover, even after power on reset, my code is not executed.

Can you confirm that PA13 is used by pinMode(6, ...)?

[fpistm]

In the generic:

Arduino_Core_STM32/variants/STM32G0xx/G031J(4-6)M_G041J6M/variant_generic.h

Line 24 in 7fc68de

#define PA13 PIN_A5

With PIN_A5:

Arduino_Core_STM32/variants/STM32G0xx/G031J(4-6)M_G041J6M/variant_generic.cpp

Line 48 in 7fc68de

6, // A5, PA13

So it is correct.
Maybe it could rely on your hardware? It is a custom board? Own PCB? Manually Wired ? Schematics available ?

[olikraus]

It had been "Manually Wired".
Let me rebuild the setup from scratch. I will also provide schematics. Again: Thank you both for the support. I will come back with more information.

[olikraus]

I have created a new board with a virgin device:

Soldered on a breakout board:

Final board with schematic:

I have added a normal reset button here.

I can confirm, that this works as described by @ABOSTM (second post):
After upload the automatic start does NOT work. Instead I have switch to normal mode and reset the device.

However, I observe, that the device still freezes if I change something in the code (for example changing the delay time).
In fact it looks like, that the code upload doesn't work any more if the size of the binary changes.

So, at the moment, I have still two issues:

1. There is no automatic start of the uploaded code (Workaround: Assign GND to BOOT0 Pin and do a manual reset)
2. Sometimes does not react any more. (Workaround: Full flash erase required)

[olikraus]

Ok, here is my problem:
I upload this code:

#define MYPIN 6
// the setup function runs once when you press reset or power the board
void setup() {
  pinMode(MYPIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
  digitalWrite(MYPIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(300);      
  digitalWrite(MYPIN, LOW);    // turn the LED off by making the voltage LOW
  delay(300);      
}

All works fine, the code size is 13416 bytes
If I change the code like this, then it doesn't work any more:

#define MYPIN 6
// the setup function runs once when you press reset or power the board
void setup() {
  pinMode(MYPIN, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
  digitalWrite(MYPIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(200);
  digitalWrite(MYPIN, LOW);    // turn the LED off by making the voltage LOW
  delay(200);
}

Code size is now 13412 bytes.

[olikraus]

After some more testing, my result is this:
As soon as the size if the binary code changes, flashing will fail (or at least there is a good chance that flashing will fail).
This can be solved, if the flash memory is fully erased (mass erase). Unfortunately this stm32duino does NOT erase the flash memory.
From what I see at the moment there are two errors in stm32duino

1. The script stm32CubeProg.sh has a problem:

https://github.com/stm32duino/Arduino_Tools/blob/d0ccf253d7109a4f79e37114f70f8f604c1262d6/stm32CubeProg.sh#L141

${STM32CP_CLI} -c port=${PORT} ${MODE} ${ERASE:+"-e all"} -q -d "${FILEPATH}" ${ADDRESS} "${OPTS}"

Instead it should be ('-' instead of '+'):

${STM32CP_CLI} -c port=${PORT} ${MODE} ${ERASE:-"-e all"} -q -d "${FILEPATH}" ${ADDRESS} "${OPTS}"

Unfortunately, this will still not work, because the mass erase, issued by "-e all" will fail, which leads me to the second problem:

2. Cube Programmer fails with mass erase "-e all" for the STMG031J6

The STM32G031J6 only has 32KB Flash ROM, however the Cube Programmer reports:

Chip ID: 0x466 
BootLoader protocol version: 3.1
Device name : STM32G03x/STM32G04x
Flash size  : 64 KBytes (default)
Device type : MCU
Revision ID : --  
Device CPU  : Cortex-M0+


Mass erase ... 

Error: Mass erase operation failed.

I assume that the cube programmer tries to erase 64KB which will fail, because only 32KB are available.

At this point we could modify this line:
https://github.com/stm32duino/Arduino_Tools/blob/d0ccf253d7109a4f79e37114f70f8f604c1262d6/stm32CubeProg.sh#L6
to
ERASE="-e [0 15]"

But this will not make much sense, for other controllers. Applying a much bigger range to cover all STM controllers
ERASE="-e [0 255]"
will work, but will also generate several errors.

[olikraus]

I assume the problem is related to Linux only, because my problem was caused by an .sh script, which probably exists only on Linux machines.

[olikraus]

Ah, I was probably wrong with the Linux assumption. stm32CubeProg.sh will be executed via busybox also on windows, so I assume, that the same problem will appear also on windows machines.