A laundry list of questions for designing an STM32L07 PCB ready for STMduino

[TwoArmsTwoLegs]

Hi enthusiasts,
I've gotten myself very turned around and I've come hoping that expertise and experience can confirm or correct my assumptions.

I've had a PCB design for a atmega32u4 arduino project that I've been working on for some time now, but I've decided that I can no longer be constrained by such a puny flash. I've decided that the STM32l07 series is good for me given it's low power requirements, flash size and inbuilt eeprom.

I bought a Nucleo, uploaded the code - i2c seems to be working fine, serial all good, didn't test USB.

I've reflowed an stm32l07 onto a breakout board and am breadboarding at the moment.
ardunio IDE has offered me "thunderpack" under "generic stm32l07" which I've gladly taken as my inspiration. had a look at the schematic which seems understandable enough.
Blink upload with ST-link works like a dream and as soon as the red flash hit my eyes, I thought "This is going to be a breeze!".
This is where the grape turns sour.
I am trying to figure out where my nucleo might differ from my bare chip STM32.

Assumption 1: There's no STM32duino bootloader for the L0 series, is there. or is there? I think I'm getting confused with the chip datasheet talking about a pre-programmed bootloader. The STMduino bootloader is a different thing from the IC pre-programmed bootloader, correct? The bootloaders allow for programming and serial via USB, is this right? What's the difference between them? Surely I don't need a bootloader to use the arduino keyboard emulation code?

Assumption 2: I'd assumed that with a micro USB port broken out on PA11 and PA12 and common ground that I would be able to use arduino built in serial and keyboard example code right off the bat. Is appears to be wrong? or I've made a wiring error? If I know what is *should* or *shouldn't* work, then I can target my debugging efforts, but I feel like I'm reading myself in circles.

Assumption 3: Pins PA13 and PA14 broken out to TX and RX of a USB serial adapter should give me something on the serial monitor, with arduino example code and the right board selected and uploaded via arduino IDE, right?

Where does STM32CubeMX fall into all of this? Do I have to take the code from that and compile that in with the arduino code for things like USB and serial to work? Or are cubeMX outputs already in the STM32 core on arduino?

I'm running the STM32L07 without a crystal, grateful for the crystal-less USB mentioned in the datasheet. I keep reading about people having to change their clock speed for USB to work, but that's correct advice for other ICs, not the L07, right?

Apologies for my great confusion.
I understand that it must be like watching a man trip over his shoelaces over and over because he keeps tying them together and wondering what's going wrong.
Utmost respect and well wishes for lockdown.

[stas2z]

Assumption 1: There's no STM32duino bootloader for the L0 series, is there. or is there? I think I'm getting confused with the chip datasheet talking about a pre-programmed bootloader. The STMduino bootloader is a different thing from the IC pre-programmed bootloader, correct? The bootloaders allow for programming and serial via USB, is this right? What's the difference between them? Surely I don't need a bootloader to use the arduino keyboard emulation code?

there is no "stm32duino bootloader for any series except f1
but you got it right, yor chip have system (preprogrammed to system area, its read only and don't waste user flash space) bootloader, which (as i can see in AN2606) supports serial (USART1 and USART2) and probably usb dfu uploading (for L072/L073).
To enter system bootloader you need to pull BOOT0 up while power on or reset (and make sure nBOOT1 bit is set, but it's set by default afaik), after that you can flash your chip.
Automatic reset to bootloader from IDE is not implemented yet, but it's WIP and probably will be finished some day, so you need to reset it manually before flashing atm or use ST-LINK.

Assumption 2: I'd assumed that with a micro USB port broken out on PA11 and PA12 and common ground that I would be able to use arduino built in serial and keyboard example code right off the bat. Is appears to be wrong? or I've made a wiring error? If I know what is *should* or *shouldn't* work, then I can target my debugging efforts, but I feel like I'm reading myself in circles.

Yes, at least serial. if you are talking about examples, shipped with core. Make sure you enabled generic serial in the dropdown menu right after you selected your mcu.

Assumption 3: Pins PA13 and PA14 broken out to TX and RX of a USB serial adapter should give me something on the serial monitor, with arduino example code and the right board selected and uploaded via arduino IDE, right?

Not exactly, in case of NUCLEO_L073 variant, default serial pins are PA2/PA3
but, you can use other serials, check the core docs, how to enable extra serial instances, for PA13/PA14 you need to enable SERIALLP1 and use it as SerialLP1.*** in your sketch.

Where does STM32CubeMX fall into all of this? Do I have to take the code from that and compile that in with the arduino code for things like USB and serial to work? Or are cubeMX outputs already in the STM32 core on arduino?

Nowhere by default. CubeMX can be used to generate some lowlevel code for your special needs (for example, if you need different clock frequency) but most things can be done without it.

I'm running the STM32L07 without a crystal, grateful for the crystal-less USB mentioned in the datasheet. I keep reading about people having to change their clock speed for USB to work, but that's correct advice for other ICs, not the L07, right?

I can't be 100% sure, but usually if chip have usb support it's configured with proper frequencies to run USB.

[mrburnette]

Hi enthusiasts,
I've gotten myself very turned around and I've come hoping that expertise and experience can confirm or correct my assumptions.

I've had a PCB design for a atmega32u4 arduino project that I've been working on for some time now, but I've decided that I can no longer be constrained by such a puny flash. I've decided that the STM32l07 series is good for me given it's low power requirements, flash size and inbuilt eeprom.

Migration to a STM32F103C8xx is likely easier on a blue board or black board.
https://stm32duinoforum.com/forum/wiki_ ... _Pill.html
https://stm32duinoforum.com/forum/wiki_ ... _Pill.html

Why? Because the old forum has bunches of info (Roger's Core)
https://github.com/rogerclarkmelbourne/Arduino_STM32/

I bought a Nucleo, uploaded the code - i2c seems to be working fine, serial all good, didn't test USB.

Use the Official STM core.
https://github.com/stm32duino/Arduino_Core_STM32

I've reflowed an stm32l07 onto a breakout board and am breadboarding at the moment.
ardunio IDE has offered me "thunderpack" under "generic stm32l07" which I've gladly taken as my inspiration. had a look at the schematic which seems understandable enough.
Blink upload with ST-link works like a dream and as soon as the red flash hit my eyes, I thought "This is going to be a breeze!".
This is where the grape turns sour.
I am trying to figure out where my nucleo might differ from my bare chip STM32.

Assumption 1: There's no STM32duino bootloader for the L0 series, is there. or is there? I think I'm getting confused with the chip datasheet talking about a pre-programmed bootloader. The STMduino bootloader is a different thing from the IC pre-programmed bootloader, correct? The bootloaders allow for programming and serial via USB, is this right? What's the difference between them? Surely I don't need a bootloader to use the arduino keyboard emulation code?

STM32 has a serial bootloader (in silicon) with autobaud which only requires USB--> serial module: Rx, Tx, Gnd, 3.3V.
You can also use a ST-Link, many STM boards have this interface integrated.

Assumption 2: I'd assumed that with a micro USB port broken out on PA11 and PA12 and common ground that I would be able to use arduino built in serial and keyboard example code right off the bat. Is appears to be wrong? or I've made a wiring error? If I know what is *should* or *shouldn't* work, then I can target my debugging efforts, but I feel like I'm reading myself in circles.

Assumption 3: Pins PA13 and PA14 broken out to TX and RX of a USB serial adapter should give me something on the serial monitor, with arduino example code and the right board selected and uploaded via arduino IDE, right?

https://github.com/stm32duino/wiki/wiki/Upload-methods
and/or
https://github.com/rogerclarkmelbourne/ ... /Uploading

Where does STM32CubeMX fall into all of this? Do I have to take the code from that and compile that in with the arduino code for things like USB and serial to work? Or are cubeMX outputs already in the STM32 core on arduino?

https://github.com/stm32duino/Arduino_C ... troduction

I'm running the STM32L07 without a crystal, grateful for the crystal-less USB mentioned in the datasheet. I keep reading about people having to change their clock speed for USB to work, but that's correct advice for other ICs, not the L07, right?

I am not familiar... Anyone?

Apologies for my great confusion.
I understand that it must be like watching a man trip over his shoelaces over and over because he keeps tying them together and wondering what's going wrong.
Utmost respect and well wishes for lockdown.

Ha, ha ... no prob. After AVR 8-bit stuff for years, you are graduating kindergarten ... most of us have the same story.


Ray

[TwoArmsTwoLegs]

Thanks for the reassurances and the reading materials gents,
Eventually, given what you were saying, I was so certain that what I'd breadboarded should work that I pulled it all apart and started from scratch out of frustration.
In case it might help anyone else in future, I was coming up against a "USB device descriptor failed" on plugging in a seriously simple minimal circuit of the STM32L07 with USB plus (USB_DP) on PA12, USB minus (USB_DM) and common ground (also with a button to ground on NRST and a button to VCC on BOOT0).
The cause was a cold solder joint on USB minus between my PCB and the micro USB connector.
on fixing that, upload via STMCubeProgrammer(DFU) and serial monitor via CDC generic serial just worked beautifully and without a hitch and without any modifications to the arduino example code.
It really is staggeringly simple. Gratitudes to everyone who's contributed code. Apart from my bad joint, everything software side was seamless.

If anyone comes across the same issue, check your joints, check your wires. I know they look fine and I know you don't want to, but it might just save you some time.