-
Notifications
You must be signed in to change notification settings - Fork 960
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic Board STM32G031J6, issues with starting the downloaded code (pinMode hangs) #1637
Comments
Hi @olikraus,
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.
|
I finally succeed to flash my STM32G0316-DISCO, so I continue my investigations.
So all seems to work properly |
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.
yes correct. I think the problem described here is not related to NRST, but I just wanted to describe my complete setup. So, this is the normal (expected) Arduino Upload process:
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. So what are possible failures could be here?
At this point I think that there is an issue with stm32duino. I started to some further investigation:
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 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. |
Nice.
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).
Moreover, even after power on reset, my code is not executed. Can you confirm that PA13 is used by pinMode(6, ...)? |
In the generic:
With
So it is correct. |
It had been "Manually Wired". |
I have created a new board with a virgin device: I have added a normal reset button here. I can confirm, that this works as described by @ABOSTM (second post): However, I observe, that the device still freezes if I change something in the code (for example changing the delay time). So, at the moment, I have still two issues:
|
Ok, here is my problem:
All works fine, the code size is 13416 bytes
Code size is now 13412 bytes. |
After some more testing, my result is this:
Instead it should be ('-' instead of '+'):
Unfortunately, this will still not work, because the mass erase, issued by "-e all" will fail, which leads me to the second problem:
The STM32G031J6 only has 32KB Flash ROM, however the Cube Programmer reports:
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: But this will not make much sense, for other controllers. Applying a much bigger range to cover all STM controllers |
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. |
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. |
I have created another issue for STM32CubeProgrammer, see stm32duino/Arduino_Tools#82 I think, this issue can be closed. Thanks a lot for your amazing support and providing STM32duino to the Arduino community. |
Hi @olikraus First by defaut the full erase is not request. It is a option added for some user which use the boards.local.txt or the platform.local.txt feature. About the
|
ok, I understand. Anyhow, the problem is: If my code for STM32G031J6 changes in size, then the execution fails and requires a full (or at least suffient) erase, which does not happen at the moment. The best solution would be, if I could enable full Flash erase (mass erase) operation for the STM32G031J6. Is there an option in the GUI already available for this? I think this applies to all STM32G031J6: Any upload will require a mass erase. |
I don't think mass erase is required. Line 3488 in de25178
as stated you can use the platform.local.txt to customize your setup or use this https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core |
Thanks for the hint, I will try this.
As mentioned above, the newly uploaded code to STM32G0 fails if the binary size was changed. |
I've made the same setup than you and here the result:
Even if the mass erase failed, during the next step (programming) it first erases the 0-6 sectors and flash without any issue. |
This is exactly not the case. I change the size only by 4 bytes, then the flashed software becomes anusable. Also any reset does not help here. Let me repeat my problem:
I see the same message in both cases in the Arduino IDE, but still it doesen work.
I also assumed that one page is 2kb. However there is another miracle. However, if cube programmer assumes one page to be 1kb, then
would only erase 7kb (out of the required 14 kb). Maybe cube programmer has a real problem, because it erases only half of the code. This would indeed explain why any code change will not work. Maybe you can confirm the malfunction for the above 13 steps... EDIT: Changed the delay values in the code |
I've succeed to reproduce your issue sometimes after the reset, this is not regular and the board is in unknown step as event the STLink could not connect anymore. |
I am happy to read this.
I have not checked this, but if I do a full erase, then it will also work again. Ok, I understand that I could use STLink. From my perspective, if STM32duino would add "-e [0 31]" to the cube programmer cli as part of the upload arguments for the STM32G031J6, then the problem would be solved. (again, as discussed, "-e all" does not work and also the GenG0.menu.upload_method.serialMethod.upload.protocol=11 trick will probably not work, because it just enables the none working "-e all") |
Probably but it is just a workaround. You can use it using the platform.local.txt or the custom core as show in the wiki. |
Sure, but i am also interessted in a more generic solution. The above problem will happen to everyone who uses STM32duino with the STM32G031J6, right? So it would be great if STM32duino could solve this problem somehow in the STM32duino project. |
Probably. But I can't be sure as it could depend of the bootloader version available within the mcu. Changing the core to add "-e [0 31]" will impact all the generic G0 variants but it is probably not correct for all. While I have not the exact reason why it fails, I would not deploy a fix as it could implies a lot of change in the core. |
Very much correct. I also didn't meant this as a generic solution. I think a generic solution should allow individual upload arguments for cube programmer cli based on the selected controller, so that J6 gets -e [0 31] and J4 might require -e [0 15].
I am happy that you already guided me to find a workaround for my issue. At least I now know how to modify STM32duino so that it works with my board. Thats already a great success. Again: THANKS A LOT! |
Unfortunately, Arduino boards definition is very limited. So hard to do that or it would required to define all the boards at the same level with all the submenu duplicated 😉 This will lead to a boards.txt more than 100x longer and a very long menu ... |
hmm.. I understand. So, it would be great if -e all would work.... |
I tried to figure out whether CubeProgrammer works with 1kb or 2kb sector size. So I did the following test:
The warning is correct, the first none-empty byte is at 0x08000000
As a conclusion the "-e [0 1]" will only clear memory from 0 to 2047. This means the "-e" command expects sectors as 1kb size and indeed "-e [0 31]" is required to erase the complete flash of the STM32G031J6 During pattern flashing the output of cube programmer had been:
This would make sense, if the erase sector size is 2kb. So at least, the input arguments to the -e command are different (1kb) to the generated output (2kb). |
I did another test:
Expectation would be, that I see 4000 bytes with value 0x55 0x08000000.
This looks very good, all is ok
This is wrong. Only 2048 of the 4000 bytes with 0x055 had been written to the flash. Still we can see 0x0f values although we tried to overwrite these values. Cube programmer is broken and does not work as expected for the fillmemory command. I think the same wrong behavior applies to flash write command at least for the STM32G031J6. |
I have tested the behavior with STM32G031F8 and SWD interface. Please excuse using a cheap stlink clone, but as a hobbyist, my budged doesn't allow me to buy expensive equipment. Results are good with SWD interface: "-e all" works as expected and also the the fillpattern command works as expected. Overwriting the 0x0f pattern with 0x55 correctly reports:
So it looks like Cube Programmer 2.9.0 has a problem with all STM32Gxxx devices connected via USART only (SWD works correctly). |
More remarks: The STM32G031Fx is not listed in STM32duino, probably I could use STM32G031Kx instead, but then the pin numbers might be different. Anyhow, just an observation. |
I tried to figure out how to change STM32duino so that the erase operation works correctly.
Does not work, because the "-e all" will not work at all for this device. So the only option to make the STMG032xx work correctly via USART flash is to modify stm32CubeProg.sh. Summary
|
You can add the generic quickly following the wiki to add a new board. |
Thanks! |
Internal Ticket 122350 |
I am a little bit confused regarding closing this topic: #1653 will solve the automatic startup after download (USER_VECT_TAB_ADDRESS and clock setup topics). I mean this issue has described two issues and only one is now solved by #1653 How shell we deal with the USART flash problems? Any progress on your Internal Ticket 122350? |
From my point of view, yes, this issue is closed: The issue that upload via UART is broken when code length changes, is I think invalid (or miss interpretation). I have not seen evidences that links code length change and bootloader issue. And this is not something I observed during my analysis. Now if you still have some issues using UART bootlader despites the fixes I made, then I propose to open a new issue, and in any case, experiments should be restarted from scratch with both fixes. |
I agree, this makes sense. |
The problem mentioned on 3 Feb seems to be resolved now with CubeProgrammer 2.10 Thanks to all! |
@olikraus Looks like you solved the problem, but I'm wondering about that resistor value in series with the LED. Typically these are 1.7V and power supply is at 3.3V so the 100 Ohm resistor will drop 1.6V pulling the max current of 16mA from the MCU pin. |
In fact the resistor is not required. The MCU will limit the current to the specified value from the datasheet: you can connect a LED directly to any of the pins. |
Great! I see a "20mA" condition in Table 53, but nothing about current limiting. Table 19 above is from paragraph 5.2, "Absolute maximum ratings". An active current limiting would involve more on-die parts that would measure current and turn off at a threshold value, allowing short to ground and to VCC which is also mentioned in the data sheet. Where did you find "_The MCU will limit the current to the specified value from the datashee_t" ?? |
The current limitation is an effect/ characteristics of the underlaying CMOS technology. It doesn't require any extra parts. Unlike TTL logic a CMOS transistor has still a significant resistance if the transistor is fully turned on (So called on-resistance of the MOS transistor). This "build in" resistance will always limit the output current. |
Apply Ohm's Law to that FET's RDS-on and you will soon exceed what a MCU port can handle. 0.020mA*3.3V=0.066W. |
Each FET has a kind of a lowest RDS-on. This will limit the current. Of course the FET may still get destroyed if RDS on is very low and no proper cooling is applied. And yes: for an MCU you can not expect all GPIOs to deliver 20mA: There is an upper limit of what the overall MCU can deliver (this is also mentioned in the MCU datasheet). Moreover your calculation is wrong, because you need to multiple the current with the voltage over the enabled output FET of the driver stage of the GPIO of the uC. This, however, is the applied power voltage minus the forward voltage of your LED: 0.020mA * (3.3V-1.8V)
Just to clarify this. I was talking about a single GPIO pin. Regarding facts, you could look at this FET: https://eu.mouser.com/datasheet/2/196/Infineon_BSS127I_DataSheet_v02_01_EN-2237807.pdf |
Please, before reporting any issue
https://github.com/stm32duino/Arduino_Core_STM32/releases/latest
Oliver: I have installed Arduino Core STM32 last week (2.2.0)
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
Oliver: Difficult to say, but I assume it is a problem within Arduino_Core_STM32
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:
⚠ When reporting any issue, please try to provide all relevant information to help on its resolution.
Describe the bug
To Reproduce
Steps to reproduce the behavior:
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)
Desktop (please complete the following information):
Board (please complete the following information):
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
So my initial code looks like this (didn't execute):
Bypassing pinMode and digitalWrite
To debug this, I have bypassed pinMode and digitalWrite:
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
This will at least start the above code (blink works), however:
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
SCB->VTOR
is assigned correctlyThe text was updated successfully, but these errors were encountered: