STM32 F3 Nucleo - LED3 on whilst debugging, why?

[max_torque]

ok, i've got to be being a Muppet, but i just can't see why the LD3 (LED3) on my erased F303k8 Nucleo board illuminates when i connect to the target with the ST-LINK utility ie start a debugging session?

I've looked at the schematic for the board: F303K8_userMan page 33 and 34 and i can't see any connection between LD3 / D13 / PB3 and the debugger IC (the F103 on the board running as the std link slave device)

As mentioned the F303 has been erased (flash all FF's) and the LD3 is off when i disconnect and comes on, continuously, when i connect

what am i missing???   

[max_torque]

ok, second question, is STM32CubeMX also full of bugs or is it just being deliberately unhelpful?   

Selecting PB3 as an output and serial wire debugging sets a little yellow warning triangle next to the SYS section, and it suggests "Partly disabled conflict with PB3 mapped with GPIO_Output" but nothing that actually tells you anything, or why that might be, or god forbid, even how you might start removing that conflict!


And if someone could please tell me how i tell it what timeout i want for the systick that would be great too. It has stuck in a "1000" in the code it's generated, under the stm32f3xx_hal.c file so i assume that's 1 millisecond, but where its got that from, i have no idea, and how you might change it in CubeMX even less idea!

 

[tsman]

Selecting PB3 as an output and serial wire debugging sets a little yellow warning triangle next to the SYS section, and it suggests "Partly disabled conflict with PB3 mapped with GPIO_Output" but nothing that actually tells you anything, or why that might be, or god forbid, even how you might start removing that conflict!

It means you can't select some of the SYS options because PB3 conflicts with them. If you click on PB3 to bring up the config menu, you'll see that SYS_JTDO-TRACESWO is also on that pin. The "Trace Asynchronous Sw" option and the JTAG options in the dropdown is disabled because it can't use PB3. ST expect you to have the ST + ARM datasheets as well to explain what the various options actually mean.

And if someone could please tell me how i tell it what timeout i want for the systick that would be great too. It has stuck in a "1000" in the code it's generated, under the stm32f3xx_hal.c file so i assume that's 1 millisecond, but where its got that from, i have no idea, and how you might change it in CubeMX even less idea!

It just configures it for a 1ms SysTick hence the 1000. HAL_InitTick is declared as weak in the HAL so you can override it with your own copy elsewhere.

[capt bullshot]

Didn't want to read the manual for you, but now I did:

Port 3 isn't configured "All pins input or tri-state" after reset. PB3 and PB4 are in "Alternate function mode", say configured for JTAG debug mode (TDO -> output). This ensures an empty chip can be accessed with an JTAG debugger. So this explains why the LED is lit with erased flash.

If you want to use these pins as GPIO, your firmware has to configure them to GPIO. The cube generated code takes care of this for you.

Anyway, always select at least "Serial Wire" for the Debug under SYS.

No idea for the timeout, I tend to not use most of the HAL functions, and if, just leave such stuff at the default. Most of the HAL functions are useful for initialization of a peripheral, but you have to read and understand the manual to make the correct settings in Cube, as these often just represent the bare register with no explanation. So yes, Cube isn't helpful to the newbie at all.

And yes, Cube doesn't do a good job in terms of taking you by the hand and explain what to do. It absolutely doesn't save you from reading and understanding the manual. It's a nice thing to get your I/O assignment done, depending on the chip you can get hints: e.g. said Conflict PB3 mapped with GPIO output. Translated: you must remove the GPIO output setting from that pin (set it to "Reset State" to solve the conflict. If one function can be assigned to another pin, Cube shows a <Ctrl-Click> to Show Alternate(s) when hovering over that pin.

Edit:
When using a nucleo board with Cube, select "Initialize peripherals according to board default" (or the like, can't find that option in that particular Cube installed on this particular PC I'm at now, but it exists somewhere), to get some helpful Pre-Sets for the Pins matching the board.

[max_torque]

Now that ^^ all makes perfect sense. When explained properly, it's simple!  Surely, that is the point of tool sets like the CubeMX etc? otherwise, what is the point?


As ST have gone to the trouble of writing the software, surely the extra work to actually make it usable by itself is not too much to ask?  I'm more than happy to read the datasheet, i've done that for years, but the attraction of the STM32 range of devices was tools like the CubeMX that claim to make it "simple" to set them up, whereas clearly, it's anything but.  You can use the tool, but you still need to understand in detail what the various factors with any particular set up are, so you have to read the datasheet anyway.......

[max_torque]

BTW, i had straight way spotted that SYS_JTDO-TRACESWO was on PB3, but as i was using SW debug, which doesn't use that pin, i expected the warning to go away.

Itnow makes sense that the warning is still there because that port has a different state in RESET, but surely it would have made sense to maybe highlight that in the cube software, rather than leaving it hanging and requiring one to wade through potentially thousands of pages of datasheet to find that info.  All it would take is "see datasheet pages xyz" hint for example.

[max_torque]

Port 3 isn't configured "All pins input or tri-state" after reset. PB3 and PB4 are in "Alternate function mode", say configured for JTAG debug mode (TDO -> output).

ok next stupid question, even though you've told me this, i still can't actually find where it says this!! Can you provide a link?  (document / page)

[tsman]

BTW, i had straight way spotted that SYS_JTDO-TRACESWO was on PB3, but as i was using SW debug, which doesn't use that pin, i expected the warning to go away.

Itnow makes sense that the warning is still there because that port has a different state in RESET, but surely it would have made sense to maybe highlight that in the cube software, rather than leaving it hanging and requiring one to wade through potentially thousands of pages of datasheet to find that info.  All it would take is "see datasheet pages xyz" hint for example.

The warning in CubeMX for the SYS peripheral isn't because of the reset behaviour. It is just telling you why some of the SYS options can't be enabled. In this situation, PB3 being used as a GPIO output conflicts with SWO + JTAG. If you set all the pins to the reset state, the SYS warning will go away.

The STM32 documentation is spread out across multiple areas. Some parts you'll need the ARM datasheets as it is a generic ARM peripheral. The STM32 specific parts will be in the ST documentation. For the HAL/LL, you'll need to dig into the ST HAL/LL documentation + examples included in the firmware package bundles.

[tsman]

Port 3 isn't configured "All pins input or tri-state" after reset. PB3 and PB4 are in "Alternate function mode", say configured for JTAG debug mode (TDO -> output).

ok next stupid question, even though you've told me this, i still can't actually find where it says this!! Can you provide a link?  (document / page)

Page 231 in RM0316 "Reference Manual for STM32F303xB/C/D/E, STM32F303x6/8, STM32F328x8,STM32F358xC, STM32F398xE advanced ARM®-based MCUs"

[max_torque]

The warning in CubeMX for the SYS peripheral isn't because of the reset behaviour. It is just telling you why some of the SYS options can't be enabled. In this situation, PB3 being used as a GPIO output conflicts with SWO + JTAG. If you set all the pins to the reset state, the SYS warning will go away.

Well that's pretty stupid too ain't it!  Warnings should be issued when required and not when not required. Nobody says "you might need an umbrella" on a beautiful sunny day just because there is the risk it might rain!

The "warn just in case" route simply means there will always be lots of warnings flashing up, and history proves that all that does is result in warnings being ignored!  That's just the way us humans work 

It would be far better that clicking an option made no warning unless there was a REAL conflict, and that perhaps they introduced an "INFO" flag to tell you important things that don't matter right now, but could, ie that that port you have just selected as a GPIO will not be HiZ in reset which, for example if your STM was say driving an Hbridge that drove a motor, could lead to some very un-expected functionality / smoke when you come to flash the device with power on......

Ie,

you select JTAG, and then PB3 as a GPIO = conflict warning

you select SW debug and a little info flag pops up on the debug pins to say "not held HiZ in reset"


but hey, that would be far too logical wouldn't it..........

[tsman]

Well that's pretty stupid too ain't it!  Warnings should be issued when required and not when not required. Nobody says "you might need an umbrella" on a beautiful sunny day just because there is the risk it might rain!

The "warn just in case" route simply means there will always be lots of warnings flashing up, and history proves that all that does is result in warnings being ignored!  That's just the way us humans work 

Yeah. All CubeMX projects basically light up like a Christmas tree with the warning symbols because each pin causes so many conflicts.

Not that it is an excuse but the processor configuration tools from all manufacturers tend to be weird and quirky. A textbook case of designed by developers for developers with an unspoken assumption they know the intricate details. I normally only use CubeMX for the clock configuration tool and the general pin mapping tool. Easier to play with those two tools than dig around in the datasheets looking for the exact combinations that are valid for the peripherals I need.

I'd strongly suggest having a brief glance through the errata for the part you're using as well. Some of the bugs are bad and you'll be tearing your hair out if you hit one of them and not realise it is a known issue.

[capt bullshot]

ok next stupid question, even though you've told me this, i still can't actually find where it says this!! Can you provide a link?  (document / page)

It's in the Reference Manual, each chapter assigned to a peripheral has a section describing the registers and the reset state of the registers. So I looked up the GPIO chapter, and Port B registers. tsman pointed to another source.

The yellow warning sign means "not all modes hidden behind this menu are configurable" - open the menu to see them. A red warning sign appears if all modes are gone - the peripheral isn't accessible anymore.

One needs some exercise / experience to get useful results from Cube, mostly the same as most other tools from other MCU's I've seen.

[JPortici]

otherwise, what is the point?

To me, the point of CUBE MX, or harmony, or ASF or whatever framework from whatever vendor is pin planning and the inclusion of usb/ethernet/graphic stack or whatever. Sometimes also the setup for stupidly convoluted clock trees.
The framework is not a substitute for the datasheet.

[mbless]

As ST have gone to the trouble of writing the software, surely the extra work to actually make it usable by itself is not too much to ask?  I'm more than happy to read the datasheet, i've done that for years, but the attraction of the STM32 range of devices was tools like the CubeMX that claim to make it "simple" to set them up, whereas clearly, it's anything but.  You can use the tool, but you still need to understand in detail what the various factors with any particular set up are, so you have to read the datasheet anyway.......

Well it does make it quick to generate the base code with a few clicks in a GUI. As other's have said it's great for planning and seeing peripheral conflicts. It's rather daft of you to think the program can stand on its own and replace a 1000+ page reference manual without any prior knowledge.