Page 1 of 1

[Answered] New DISCO_L072CZ_LRWAN1 variant; questions about a few details

Posted: Sat Nov 11, 2017 9:13 pm
by knielsen
I'm working on a variant to support the Discovery L072CZ-LRWAN1 board:

http://www.st.com/en/evaluation-tools/b ... rwan1.html

IIUC, this is the board that is being used in free ST workshops on LoRa connectivity. The branch is here:

https://github.com/knielsen/Arduino_Cor ... 2cz-lrwan1

The variant is based on STM32Cube files and board manual/datasheet. I think I got most/all things right, but I have a few questions:

1. This board has A1, A3, A4 and A5 unconnected. What is the best way to handle this? What I did so far was to define those pins as NC in digitalPin[] and put dummy NC_2, NC_3, ... entries in the enum in variant.h:

Code: Select all

  const PinName digitalPin[] = {
    ...
    PA_0,  //D26/A0
    NC,    //D27/A1
    PA_4,  //D28/A2
    NC,    //D29/A3
    NC,    //D30/A4
    NC,    //D31/A5

Code: Select all

  enum {
    ...
    PA0,  //D26/A0
    NC_2, //D27/A1
    PA4,  //D28/A2
    NC_3, //D29/A3
    NC_4, //D30/A4
    NC_5, //D31/A5
2. Do I need to enable any peripheral clocks in SystemClock_Config()? Some variants have a HAL_RCCEx_PeriphCLKConfig() call in SystemClock_Config(), while others do not (eg. NUCLEO_F303K8 vs. NUCLEO_F303RE).

3. The STM32L072 has a Cortex M0+ (as opposed to plain M0) CPU. Is it still
correct to put "build.mcu=cortex-m0" in boards.txt (as opposed to eg.
"build.mcu=cortex-m0+" or something like that)?

(I plan to submit a pull-request shortly, but I would like to first get some testing done on real hardware first...)

Re: New DISCO_L072CZ_LRWAN1 variant; questions about a few details

Posted: Sun Nov 12, 2017 7:58 am
by fpiSTM
knielsen wrote:
Sat Nov 11, 2017 9:13 pm
1. This board has A1, A3, A4 and A5 unconnected. What is the best way to handle this? What I did so far was to define those pins as NC in digitalPin[] and put dummy NC_2, NC_3, ... entries in the enum in variant.h:

Code: Select all

  const PinName digitalPin[] = {
    ...
    PA_0,  //D26/A0
    NC,    //D27/A1
    PA_4,  //D28/A2
    NC,    //D29/A3
    NC,    //D30/A4
    NC,    //D31/A5

Code: Select all

  enum {
    ...
    PA0,  //D26/A0
    NC_2, //D27/A1
    PA4,  //D28/A2
    NC_3, //D29/A3
    NC_4, //D30/A4
    NC_5, //D31/A5
In fact, they could be connected depending a solder bridges to the same pin than other Ax or dedicated pins. (same on the schematics rev C or D)
Refers: Table 11. Configuration of the solder bridges of the UM2115
One tip: the pin mapping management used is derived from the mbed one.
you could have a look to the mbed porting:
https://os.mbed.com/platforms/ST-Discovery-LRWAN1/
on this page you have links on 2 files:
PeripheralPins.c
PinNames.h
As you will see in the PinNames.h:

Code: Select all

    A0          = PA_0,
    A1          = PA_0, // Alias
    A2          = PA_4,
    A3          = PA_4, // Alias
    A4          = PB_9, // SB11 must be closed
    A5          = PB_8, // SB12 must be closed
knielsen wrote:
Sat Nov 11, 2017 9:13 pm
2. Do I need to enable any peripheral clocks in SystemClock_Config()? Some variants have a HAL_RCCEx_PeriphCLKConfig() call in SystemClock_Config(), while others do not (eg. NUCLEO_F303K8 vs. NUCLEO_F303RE).
The SystemClock_Config provided is mainly a default one to have basic features functional.
It is a weak function which can be redefined in the user sketch.
HAL_RCCEx_PeriphCLKConfig() could be used to set specific values else the default one will be call I think.
I often use the STM32cubeMx to generate the SystemClock_Config.
knielsen wrote:
Sat Nov 11, 2017 9:13 pm
3. The STM32L072 has a Cortex M0+ (as opposed to plain M0) CPU. Is it still
correct to put "build.mcu=cortex-m0" in boards.txt (as opposed to eg.
"build.mcu=cortex-m0+" or something like that)?
I think cortex-m0+ do not exist. CMSIS will deal with the proper options I guess.
Maybe you will have a warning about SecurCore (__CORTEX_SC).
Probably you could add

Code: Select all

-D__CORTEX_SC=0
in the build.extra_flags as done for the NUCLEO_L053R8
knielsen wrote:
Sat Nov 11, 2017 9:13 pm
(I plan to submit a pull-request shortly, but I would like to first get some testing done on real hardware first...)
Nice, thanks

Re: New DISCO_L072CZ_LRWAN1 variant; questions about a few details

Posted: Sun Nov 12, 2017 11:08 am
by knielsen
In fact, they could be connected depending a solder bridges to the same pin than other Ax or dedicated pins. (same on the schematics rev C or D)
Refers: Table 11. Configuration of the solder bridges of the UM2115
Right. I wasn't sure how useful it would be to define pins that are non-functional by default.

But thinking more, leaving those pins NC does not seem to do much good. The user can still reference them in a sketch, there is no compile-time error, just non-functional code.

So I guess it makes sense to define them like mbed does, with a comment about the need to close solder bridges. (Is there a good place to document such restrictions?)

In fact, mbed also defines a number of pins that are always unavailable (because they are used by the LoRa module internally, presumably). I left those out of the Arduino variant, but what do you think?
HAL_RCCEx_PeriphCLKConfig() could be used to set specific values else the default one will be call I think.
I often use the STM32cubeMx to generate the SystemClock_Config.
Yeah, I also just used the one generated by STM32cubeMx here. Though I think I deleted the HAL_RCCEx_PeriphCLKConfig() call thinking that peripherals would be enabled by the Arduino core as necessary.
Probably you could add

Code: Select all

-D__CORTEX_SC=0
in the build.extra_flags as done for the NUCLEO_L053R8
Ok, thanks!

- Kristian.

Re: New DISCO_L072CZ_LRWAN1 variant; questions about a few details

Posted: Sun Nov 12, 2017 1:54 pm
by fpiSTM
knielsen wrote:
Sun Nov 12, 2017 11:08 am

So I guess it makes sense to define them like mbed does, with a comment about the need to close solder bridges. (Is there a good place to document such restrictions?)
I think yes. For the moment it's the better place, I think, as when an user uses the core he could have the information directly in the file.
I've planned to document well this core thanks the https://stm32duino.github.io/. CurrentWiki is not easy to find/manage...
One page per board will be added with those kind of information

Re: New DISCO_L072CZ_LRWAN1 variant; questions about a few details

Posted: Sun Nov 12, 2017 2:35 pm
by knielsen
Thanks for answer! I will send a pull request once I've verified it actually runs on the hardware.