STM32 - SWD conflict with Activate NOE

[girishv]

I am new to STM32 ecosystem. I am creating a breakout board for STM32L0. In CubeIDE, I configured the pinout as follows

Sys: Enable "Debug Serial Wire"
USB: Enable "Device FS"

In USB section, the "Activate NOE" is disabled with the following warning message

Conflict with SYS: "Debug Serial Wire".

I am aware of "USB NOE" and "SYS_SWDIO" sharing the same pin.

What are the implications of the above warning?

[LootMaster]

You're too bad...

[S. Petrukhin]

You're too bad...

He texted: "I'm new to the STM32 ecosystem"

[newbrain]

Which STM32L0 and package are you using?

Generally speaking, the warning can be safely ignored:

• USB_NOE can be remapped somewhere else, if needed, in packages with 64 pins or more.
• Moreover, it is not an essential pin: it just mirrors the Output Enable status of the internal physical layer driver.

So, you should still be able to use the USB peripheral (and SWD!).

You're too bad...

Because, of course, you know everything, never make mistakes, and, especially, are always ready to help others.

[girishv]

Which STM32L0 and package are you using?

Generally speaking, the warning can be safely ignored:

• USB_NOE can be remapped somewhere else, if needed, in packages with 64 pins or more.
• Moreover, it is not an essential pin: it just mirrors the Output Enable status of the internal physical layer driver.

So, you should still be able to use the USB peripheral (and SWD!).

I am using STM32L063C8T6 (LQFP-48).

[newbrain]

I am using STM32L063C8T6 (LQFP-48).

So, USB_NOE is not available if you want to keep SWD active (highly recommended).
As said, this is not a big deal, and USB can be used with no problems.

Remember that CubeMX will always give warnings when some pin can not mapped.
The peripheral function can still be usable though, as in this case.
If some peripheral or function cannot possibly be configured (no alternative mapping for its essential pins), it'll appear in red.
Code can still be generated, for the other configured peripherals.

[S. Petrukhin]

I am using STM32L063C8T6 (LQFP-48).

So, USB_NOE is not available if you want to keep SWD active (highly recommended).
As said, this is not a big deal, and USB can be used with no problems.

Remember that CubeMX will always give warnings when some pin can not mapped.
The peripheral function can still be usable though, as in this case.
If some peripheral or function cannot possibly be configured (no alternative mapping for its essential pins), it'll appear in red.
Code can still be generated, for the other configured peripherals.

From myself I will add. The STM does not have fuses that are controlled by the programmer as Atmel. All configuration is performed programmatically by your program. CubeMX generates the initialization source code from the checked boxes and hides it from you. If you really need to use programming pins, you can switch them in the program at any time, most often in the initialization section. This does not interfere with programming, because the programmer resets the processor, after resetting they again become the programmer's pins and are used until the firmware starts running. But you will need to connect a hardware reset wire to the programmer. One problem is that if you disable SWO in the program and use its pins, you will not be able to perform step-by-step debugging on the chip.

[girishv]

I am using STM32L063C8T6 (LQFP-48).

So, USB_NOE is not available if you want to keep SWD active (highly recommended).
As said, this is not a big deal, and USB can be used with no problems.

Remember that CubeMX will always give warnings when some pin can not mapped.
The peripheral function can still be usable though, as in this case.
If some peripheral or function cannot possibly be configured (no alternative mapping for its essential pins), it'll appear in red.
Code can still be generated, for the other configured peripherals.

I almost ignored the warning. The turn around time for a board is almost 2 weeks. So, I sought help in forum.

[girishv]

I am using STM32L063C8T6 (LQFP-48).

So, USB_NOE is not available if you want to keep SWD active (highly recommended).
As said, this is not a big deal, and USB can be used with no problems.

Remember that CubeMX will always give warnings when some pin can not mapped.
The peripheral function can still be usable though, as in this case.
If some peripheral or function cannot possibly be configured (no alternative mapping for its essential pins), it'll appear in red.
Code can still be generated, for the other configured peripherals.

From myself I will add. The STM does not have fuses that are controlled by the programmer as Atmel. All configuration is performed programmatically by your program. CubeMX generates the initialization source code from the checked boxes and hides it from you. If you really need to use programming pins, you can switch them in the program at any time, most often in the initialization section. This does not interfere with programming, because the programmer resets the processor, after resetting they again become the programmer's pins and are used until the firmware starts running. But you will need to connect a hardware reset wire to the programmer. One problem is that if you disable SWO in the program and use its pins, you will not be able to perform step-by-step debugging on the chip.

I suppose I could use a jumper to switch to SWD_IO?

[newbrain]

I suppose I could use a jumper to switch to SWD_IO?

Really not worth the hassle, and that would steal another useful pin.
Unless you have a very specific requirement for using the USB_NOE signal - it would seem not, from your description - just forget about it.

[S. Petrukhin]

I am using STM32L063C8T6 (LQFP-48).

So, USB_NOE is not available if you want to keep SWD active (highly recommended).
As said, this is not a big deal, and USB can be used with no problems.

Remember that CubeMX will always give warnings when some pin can not mapped.
The peripheral function can still be usable though, as in this case.
If some peripheral or function cannot possibly be configured (no alternative mapping for its essential pins), it'll appear in red.
Code can still be generated, for the other configured peripherals.

From myself I will add. The STM does not have fuses that are controlled by the programmer as Atmel. All configuration is performed programmatically by your program. CubeMX generates the initialization source code from the checked boxes and hides it from you. If you really need to use programming pins, you can switch them in the program at any time, most often in the initialization section. This does not interfere with programming, because the programmer resets the processor, after resetting they again become the programmer's pins and are used until the firmware starts running. But you will need to connect a hardware reset wire to the programmer. One problem is that if you disable SWO in the program and use its pins, you will not be able to perform step-by-step debugging on the chip.

I suppose I could use a jumper to switch to SWD_IO?

I try not to use pins SWD for other purposes and use cases with enough pins. I also leave and use SWO pin. But, if you really really need it, you can safely use them as you wish. In other designs, not in this case with USB - here, you can say that you lose the extra signal and it is not needed. A jumper is not required, just connect the pin in both directions at the same time. "Jumper" is required in the program - if you start using step-by-step debugging on a chip, the code part that disables SWD and releases pins will need to be disabled.

[girishv]

I try not to use pins SWD for other purposes and use cases with enough pins. I also leave and use SWO pin. But, if you really really need it, you can safely use them as you wish. In other designs, not in this case with USB - here, you can say that you lose the extra signal and it is not needed. A jumper is not required, just connect the pin in both directions at the same time. "Jumper" is required in the program - if you start using step-by-step debugging on a chip, the code part that disables SWD and releases pins will need to be disabled.

I will keep it reserved for SWD. No point in complicating things. In addition, I am not short of I/O pins.