Skip to main content
Oliver R.
Oliver R.
Associate II
March 4, 2020
Solved

How to control setting the option bytes using cube ide ?

  • March 4, 2020
  • 4 replies
  • 3172 views

..

This topic has been closed for replies.
Best answer by Oliver R.

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.

4 replies

KnarfB
KnarfB
Super User
March 4, 2020

Use STM32CubeProgrammer for that.

Oliver R.
Oliver R.Author
Associate II
March 5, 2020

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).

KnarfB
KnarfB
Super User
March 5, 2020

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.
Oliver R.Author
Associate II
March 5, 2020

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.

Oliver R.
Oliver R.Author
Associate II
March 5, 2020

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 ...

Oliver R.
Oliver R.AuthorAnswer
Associate II
March 5, 2020

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.

Terms & ConditionsAccessibility statement