cancel
Showing results for 
Search instead for 
Did you mean: 

How to control setting the option bytes using cube ide ?

Oliver R.
Associate III
 
1 ACCEPTED SOLUTION

Accepted Solutions
Oliver R.
Associate III

OK, I found:

I need to set the GPIO's of my target uc in cube IDE (the cube MX part) to the debugger pins.

Then the

__HAL_AFIO_REMAP_SWJ_DISABLE();

is replaced by

__HAL_AFIO_REMAP_SWJ_ENABLE();

The deubgger still does not work in Cube IDE, but it works on the same environment flawlessly with Ozone.

So now I use Cube Ide for compiling and flashing, and Ozone for debugging.

That works for now.

View solution in original post

6 REPLIES 6
KnarfB
Principal III

Use STM32CubeProgrammer for that.

Oliver R.
Associate III

Thank you for the quick reply, highly appreciated.

Unfortunately there is a misunderstanding, due to my briefness in asking.

I dont't really want to set the option bytes. I want to AVOID them to be set.

Cube ide somehow does something strange here, which I want to understand and control:

When I use cube ide and start debugging, my device gets locked,

and is then not programmable/debuggable any more, unless I set BOOT0 low.

So, I need to find what is happening in cube ide.

(I am a beginner with cube ide - with the curent 1.3.0 version things start to be usable,

but in the past I had too much trouble, so I never really used it before).

Oliver R.
Associate III

My investigation so far shows that my problem is related to the

__HAL_AFIO_REMAP_SWJ_DISABLE();

call, which is generated by cube ide.

I found some other discussion in www about this.

I continue investigating ...

When BOOT0 is not low, the chip will boot from internal system memory (ROM) and listen on some interfaces for a boot loader. This feature is ment for firmware upgrade in the field, but not for debugging. Some chips have a option bit in flash for turing that BOOT0 pin behaviour off.

But AFAIK STM32CubeIDE does never mess with option bytes. Use STM32CubeProgrammer for option bytes inspection.

hth

KnarfB

Oliver R.
Associate III

OK, I found:

I need to set the GPIO's of my target uc in cube IDE (the cube MX part) to the debugger pins.

Then the

__HAL_AFIO_REMAP_SWJ_DISABLE();

is replaced by

__HAL_AFIO_REMAP_SWJ_ENABLE();

The deubgger still does not work in Cube IDE, but it works on the same environment flawlessly with Ozone.

So now I use Cube Ide for compiling and flashing, and Ozone for debugging.

That works for now.

Again thanks for the quick response and paying attention to this.

Sorry my mistake, I mean: "set Boot0 High".

I found what was going on by debugging and then stepping over the

__HAL_AFIO_REMAP_SWJ_DISABLE();

instruction, where the debugger said good bye.

And from here:

https://medium.com/@LargeCardinal/how-to-bypass-debug-disabling-and-crp-on-stm32f103-7116e7abb546

and here:

https://community.st.com/s/question/0D50X00009XkdjtSAB/bug-cubemx-switch-off-jtag-and-swd

I figured it out.

I posted my solution.