SensorTile

oneselflost
Sun Oct 29, 2017 8:28 pm
Has anyone had any luck getting the ST SensorTile working with Arduino IDE?

I know it uses an STM32L476, which is supported by STM32duino, but I haven’t even been able to get the LED to blink, even after adding the proper pin to the variant file.

Any help is greatly appreciated.


RogerClark
Sun Oct 29, 2017 9:48 pm
Moved this thread to the STM core, so perhaps Frederic from STM can comment

fpiSTM
Mon Oct 30, 2017 7:01 am
Hi oneselflost,

I don’t know/have this kit (I don’t know (yet ;) all the ST portfolio).
This is currently not planned to add it. I could help you if you want to add it.
some of the components are supported with Arduino libraries (LPS22HB, MP34DT04 (on going), …)
Anyway, I think, It should be possible to use the Nucleo-L476RG variant to add basic support.
Maybe the clock config is not correct that’s why the led is not blinking


oneselflost
Mon Oct 30, 2017 3:59 pm
Thank you for the reply!

Its a very capable little board, I’m looking forward to digging into it more. Incredible how much is crammed on that little tile. I’d love to add some basic support for this board – hopefully others could benefit from it as well.

Looking at the variant folder a little closer, it looks like I need to add the LED pins (PA14, and PG12) to more than just the variant.h file. I’ll do so tonight and report back. As far as clock configs go, I’ll have some reading to do as well.

Thanks again.


oneselflost
Tue Oct 31, 2017 3:02 pm
So it looks like PA14 (SWD) will blink on the Sensortile with the L476RG variant, that’s a plus! Woohoo!

I am still working on getting the other LED on PG12 to blink.


fpiSTM
Tue Oct 31, 2017 4:28 pm
Nice.
Do not hesitate to do a PR on the github.
I’m currently on vacation. I could help more next week.

oneselflost
Wed Nov 01, 2017 2:15 am
I’m at a point where I think the issue preventing PG12 from blinking might be a clock enable on GPIOG, as you mentioned prior – but I can’t for the life of me find where this is enable is implemented. Where would I go about to make this happen?

Enjoy your vacation!


caniggia
Wed Nov 01, 2017 11:53 am
If you took NUCLEO_L476RG variant as template the GPIOG clock should be enabled.
As you can see in “Arduino_Core_STM32/system/Drivers/CMSIS/Device/ST/STM32L4xx/Include/stm32l476xx.h” you have:
#define GPIOG_BASE (AHB2PERIPH_BASE + 0x0000U)
and
#define GPIOG ((GPIO_TypeDef *) GPIOA_BASE)

In “stm32l4xx_hal_rcc.h” the “__HAL_RCC_GPIOG_CLK_ENABLE()” is defined:
https://github.com/stm32duino/Arduino_C … rcc.h#L784

In “PortNames.c” the “__HAL_RCC_GPIOG_CLK_ENABLE()” is called:
https://github.com/stm32duino/Arduino_C … mes.c#L136

Do you use blink example?
What error do you get?


oneselflost
Wed Nov 01, 2017 1:19 pm
Thank you so much for replying, and pointing me to those files.

Well if the GPIOG clock is already enabled, then I am at a loss for why this pin will not blink.

I am using the blink example, and it compiles and flashes without error.

void setup() {
pinMode(PG12, OUTPUT);
}

void loop(){
digitalWrite(PG12, HIGH);
delay(500);
digitalWrite(PG12, LOW);
delay(500);
}


caniggia
Wed Nov 01, 2017 2:24 pm
What error do you get, when you compile/verify sketch ?
Or it compiles without error?

oneselflost
Wed Nov 01, 2017 2:26 pm
It compiles without error

caniggia
Wed Nov 01, 2017 2:36 pm
OK, i have tried to compile your code with NUCLEO_L476RG and got this error:
‘PG12’ was not declared in this scope.
So you probably defined PG12 but apparently not ok.

Try with pin name PG_12 instead of PG12 in your blink sketch.


oneselflost
Wed Nov 01, 2017 2:48 pm
I tried with PG_12 in the sketch, that compiled without error as well, but did not work either.

Also added a #define LED2 PG_12, and used LED2 in the sketch, that also compiled without error, but did not work either.

I added PG_12 to variant.cpp, and PG12 to variant.h, in the same position of the respective array.

That took care of the ” ‘PG12’ was not declared in this scope” error.


caniggia
Wed Nov 01, 2017 2:54 pm
You don’t have to add PG_12 anywhere, because it’s allready in “PinNames.h”:
https://github.com/stm32duino/Arduino_C … mes.h#L151

oneselflost
Wed Nov 01, 2017 3:06 pm
Hmm.. Do you think because I added it to the .cpp file that would have any negative effect on it?

I’ll have to play with it once I get home.


caniggia
Wed Nov 01, 2017 3:49 pm
Choose “NUCLEO_L476RG” (not your ST SensorTile variant),
and try with PG_12 in your sketch.
So we can see if it works wit built-in PG_12.

oneselflost
Wed Nov 01, 2017 5:03 pm
I am using the NUCLEO_L476RG variant – haven’t made my own yet.

Tried the PG_12 yesterday, same results – compiles but doesn’t do anything.

The LED is definitely tied to PG12 too, here is the schematic: http://www.st.com/content/ccc/resource/ … ematic.pdf

Also cross checked the BSP from ST, and they have LED2 tied to PG_12.


caniggia
Wed Nov 01, 2017 6:32 pm
What changes did you do to variant.h & variant.cpp ?

oneselflost
Wed Nov 01, 2017 6:39 pm
Just added “PG12” to the bottom of the extern const PinName digitalPin[] array in variant.h, and “PG_12” to the bottom of that in variant.cpp (which you mentioned I won’t need, I’ll try it without that in the cpp tonight)

caniggia
Wed Nov 01, 2017 6:55 pm
I toght you’ve put PG_12 next to PG12 in variant.h

Did you add PG12 in variant.h before PEND ?


oneselflost
Wed Nov 01, 2017 7:04 pm
I toght you’ve put PG_12 next to PG12 in variant.h – No, those are comments next to the PxX in variant.h

Did you add PG12 in variant.h before PEND ? – Yes


fpiSTM
Wed Nov 01, 2017 9:29 pm
Check quickly, your update is correct but the LED is on when PG12 is High.
It is linked to SAI_SD of the SensorTile, so if it is set to low by it then the led will be always off.

Note: using PG_12 in the sketch is not correct as it is the PinName not the pin number.

One other try which could be done is to use directly the ST HAL, this bypass all Arduino API:
void setup() {
GPIO_InitTypeDef gpio_init_structure;
__HAL_RCC_GPIOG_CLK_ENABLE();

/* Configure the PG12 pin */
gpio_init_structure.Pin = GPIO_PIN_12;
gpio_init_structure.Mode = GPIO_MODE_OUTPUT_PP;
gpio_init_structure.Pull = GPIO_PULLUP;
gpio_init_structure.Speed = GPIO_SPEED_HIGH;

HAL_GPIO_Init(GPIOG, &gpio_init_structure);
}

// the loop function runs over and over again forever
void loop() {
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_12, GPIO_PIN_SET);
delay(1000); // wait for a second
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_12, GPIO_PIN_RESET);
delay(1000); // wait for a second
}


oneselflost
Thu Nov 02, 2017 2:34 am
I tried code to use the ST HAL directly, and sure enough, it didn’t work.

Looking through the schematic and the MEMS example provided by ST, it looks like the SAI_SD is connected to an audio chip. That said, I am leaving alone PG12 for now :lol:

Moving along though – PC0, PC1, and SWD pins all blink happily! A nice surprise after a little frustration :)

I am going to need to make my own variant in order for anything to be intuitive here.. And so the project commences!


fpiSTM
Thu Nov 02, 2017 7:46 am
Referring to the User manual, page 10:
http://www.st.com/resource/en/user_manu … 320099.pdf

For PG12, Logic level of this pins is referred to VDDIO2.

Power supply
The SensorTile board has the following input supply pins:
1. VIN is the input for the onboard voltage regulator generating 1.8 V (150 mA max).
2. VDDUSB is an input for the STM32L4 VDDUSB and VDDIO2 pins (to use the
STM32L4 USB OTG peripheral, VDDUSB must be ≥ 3 V)

which power supply you use?


oneselflost
Thu Nov 02, 2017 11:10 am
I am powering via USBVDD – The LED does work when the ST ALLMEMS1 example is loaded.

cparata
Wed Nov 29, 2017 9:16 am
Regarding the MEMS sensor libraries for SensorTile, unfortunately the MEMS sensor libraries currently available on stm32duino repository support only the I2C interface. These MEMS sensor libraries can be easily extended to support the SPI 4-Wires (we just need to add a new constructor with SPI instance and 2 new implementations for IO_Read and IO_Write methods). On Sensortile, instead, the MEMS sensors are connected with SPI-3-Wires interface (it means that MISO pin is not connected and the MOSI pin is used as to transmit as to receive data to/from device). So, in order to support SPI 3-Wires we need to extend the SPI class in the STM32 Cores in order to implement also this functionality. After that, it should be possible to extend the MEMS sensor classes to support SPI 3-Wires bus as well.

Leave a Reply

Your email address will not be published. Required fields are marked *