I reached out to my ST rep. I’ve known him through a few day jobs, so I already had his contact info. If you fill out of a form on the website, they should assign you a sales rep.
I just got back my Feather boards using the QFN package. Here’s what they look like.
Oh, nice board!
I filled out the web form, but I’m just a lone hacker at the moment…
Evidently ST doesn’t send out samples if you’re not working for a large company promising to buy millions of units. Too bad…
Great Help JP. Thank you for Sharing Your work.
Hi looking forward to your Opensource Project…Great Work
Curious if there were any updates on opensourcing the project? I am super interested and looking forward to seeing the documents available.
I finally pressed the order button on some stm32wle5jc’s… Now I get to figure out how to design a small board. Lots of new challenges 
@jpnorair and @jason: did you find any RF reference designs? Used the sx1262 ones? I took a quick look at the ST docs and haven’t found anything yet. Any chance you’d post a PDF of your schematic or the RF section?
I have the reference design docs from ST, but they were shared under NDA. I assume they’ll become public at some point. For now, the SX1262 RF design should be close enough. I’ve been focusing on the WB chip while I wait for the WL software to catch up. The WB has a custom companion chip for RF matching and filtering. I wouldn’t be surprised if the WL gets one too.
PSA: Mouser and the ST store have a small qty of STM32WLE5CCU6 in stock, that’s the 256KB flash version in UFQFPN.
found this these days: Seeed created a canned Module “Lora-E5” which using the WLE5JC and a sx in addition - which looks redundant but there we go and probably to rush with CE/FCC - which is an atractive point.
Yeah, that Lora-E5 module makes no sense to me.
The seeed module looks pretty good 'cause you don’t have to deal with the UFQFPN or BGA packages. It’s just the stm32WLE5 chip plus some passives. There is no separate radio chip (it wouldn’t even fit), the description is just messed-up. Problem, though, it’s out of stock 'til january or so, and also the benefit of getting cpu+radio for less than the cost of just the radio is way gone.
PSA: a bunch of application notes and reference docs about RF design with the STM32WLE5 have appeared on the ST product page: https://www.st.com/en/microcontrollers-microprocessors/stm32wlex.html#documentation
They’re listed right at the top under recommended resources, such as AN5457 - RF matching network design guide for STM32WL Series and more…
(Post edited to fix the product link)
The E5 is an MCU+Radio. The 55 is dual-MCU+Radio. The problem with the 55 is that the MCU tied to the Radio is the Cortex-M0, so you can’t do much signal processing on it. LoRaWAN is so elementary that I’m not sure dual-MCU matters. Dual-MCU is common on BLE SoC’s, but BLE is a beast of a stack.
Thanks for the link to the data page, though. Over the winter holiday I’ll be qualifying the vendor stacks and finishing the Zephyr port, if there’s time. My module has a different front-end than the ST reference design. It uses an external TI 3.1V LDO rather than the analog switches ST uses, and an SP3T RF switch. Should be somewhat more efficient my way, but I’ll test when I have the Nucleo.
Oops, I did link to the WL55 product page by mistake, I’ll fix that. The AN5457 is the interesting new doc and that applies to both. There’s also a new AN5408 migration app note that is interesting in that it has some good tables comparing discrete stm32 processors plus sx12xx radio with the stm32wl option. Nothing you don’t already know, but nice to reference. (For example, I hadn’t spotted that the WLE5 cpu doesn’t have an FPU…) Then there’s AN5042 - Precise HSE frequency trimming using STM32 wireless MCUs, which is also very useful.
Quick warning that I’m seeing errors in AN5457…
I’m looking at Appending A.1.10 of AN5457 where the PA matching impedance measurements for the UFQFPN48 package @14dBm and 915Mhz are shown. I cannot match up the points 1 through 5 in figure 80 with the rows 1 through 5 in table 14 below the figure.
For example, point 5 in the chart is between the 22mA and 23mA lines but the table lists 27.38. There are 3 points above the 25mA contour in the chart but only 2 in the table. Etc.
Is the QA on the chip better than the QA on the AN’s?
Hmm, looking at the 868Mhz page (A.1.7) the correspondence between chart and table looks OK at first glance, but the real part of point 3’s impedance in the table is far off from all the other points, yet it’s in the middle of the cluster. After trying to plot some more of the impedances in the table on a smith chart I don’t see how the table and chart can match up. Maybe I’m not understand what I’m looking at at all…
Another PSA: FWIW, there is an MB1552B reference board for STM32WLxx in the QFN48 package. This ST forum thread has downloadable schematics: https://community.st.com/s/question/0D53W00000FzAd6SAF
Hi folks: it took six months, but finally I’ve created a GitHub page for the module design. The availability of FW, now, makes it more useful.
Edit: Here is the octopart BOM
Module: https://octopart.com/bom-tool/yhC5Y8BV
Very cool! Thanks for making this available! I’m sure I will have 1000 questions 
!
First question: what is your thinking WRT U3, the Vreg to supply TX power in high-power mode. I can’t tell what drives RF-VSEL, so that’s a bit confusing. But my question is really whether you’re trying to avoid the power switch or somehow get better performance? I thought that the voltage level on VR_PA was determined by the selected TX power level, i.e., not a fixed value, your design would no longer allow to select TX power? Probably I am completely mistaken?
The 3.1V LDO can be enabled when desired via the pin. The selection of the low power PA and high power PA is done in firmware, so to get the HP-PA mode, you need to enable the LDO and do the normal set-up in FW.
There are a few reasons I didn’t use an analog switch circuit together with the interval 3.1V RF supply.
I’d really like to do some intensive performance evaluation of external LDO vs internal LDO with switch, but this has been postponed because the STM32WL general-availability and dev kits have been delayed so long.
