Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Simple GPIO problem

Hi,

I’ve just started working with system workbench and am having trouble getting a simple GPIO program working.
I’m using a Nucleo-L152RE and code is attached. Its basically a very slightly tweaked version of a helloworld example. It toggles pin3 portA.
Everything seems to build and run ok, but the GPIO voltage doesn’t change at all.

Any ideas what my problem is? I’m probably just being thick...



12:17:10 **** Incremental Build of configuration Release for project Test ****
make all
‘Building file: ../src/main.c’
‘Invoking: MCU GCC Compiler’
C:\Users\JamesB\workspace\Test\Release
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -DSTM32L1 -DSTM32L152RETx -DNUCLEO_L152RE -DSTM32 -DUSE_STDPERIPH_DRIVER -DSTM32L1XX_XL -I”C:/Users/JamesB/workspace/nucleo-l152re_stdperiph_lib” -I”C:/Users/JamesB/workspace/Test/inc” -I”C:/Users/JamesB/workspace/nucleo-l152re_stdperiph_lib/CMSIS/core” -I”C:/Users/JamesB/workspace/nucleo-l152re_stdperiph_lib/CMSIS/device” -I”C:/Users/JamesB/workspace/nucleo-l152re_stdperiph_lib/StdPeriph_Driver/inc” -I”C:/Users/JamesB/workspace/nucleo-l152re_stdperiph_lib/Utilities” -O3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF”src/main.d” -MT”src/main.d” -o “src/main.o” “../src/main.c”
‘Finished building: ../src/main.c’
’ ’
‘Building target: Test.elf’
‘Invoking: MCU G++ Linker’
arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -L”C:\Users\JamesB\workspace\nucleo-l152re_stdperiph_lib\Release” -T”C:\Users\JamesB\workspace\Test\LinkerScript.ld” -Wl,-Map=output.map -Wl,--gc-sections -fno-exceptions -fno-rtti -o “Test.elf” @”objects.list” -lnucleo-l152re_stdperiph_lib
‘Finished building target: Test.elf’
’ ’
make --no-print-directory post-build
‘Generating binary and Printing size information:’
arm-none-eabi-objcopy -O binary “Test.elf” “Test.bin” && arm-none-eabi-size -B “Test.elf”
text data bss dec hex filename
1696 1076 1568 4340 10f4 Test.elf
’ ’

Quick update, I checked with a scope and PA13 &PA14 are pulsing and PB4 is a steady 3.3V
I’m stumped.
Using the nucleo-L152RE std peripheral library, going to try with a different library and see if that’s the issue


France

Hi James,

Looking at your code you try to toggle GPIO PA3, not PB4; why PA13 and PA14 are pulsing is probably another problem, you should look at the MCU documentation to see what output could be connected on these pins, but it should not be caused by your code, as it programs and toggles PA3.

However, if you look at the stm32l1xx_nucleo.h file (in the Utilities folder of the nucleo-l152re_stdperiph_lib project) you will find that LED2 is in fact connected to GPIOA pin 5, not GPIOA pin 3, so you should correct your code to use this pin and, hopefully, the LED should blink. When using the StdPeriph library, you could use the LED2_PIN, LED2_GPIO_PORT and LED2_GPIO_CLK symbols instead of explicitly stating GPIO_Pin_3, GPIOA and RCC_AHBPeriph_GPIOA.

Bernard


Thanks, I’ve tried simplifying everything using LED2, so it now looks like this:

int main(void)
{
GPIO_InitTypeDef gpio;
RCC_AHBPeriphClockCmd(LED2_GPIO_CLK, ENABLE);

GPIO_StructInit(&gpio);
gpio.GPIO_OType = GPIO_OType_PP;
gpio.GPIO_PuPd = GPIO_PuPd_UP;
gpio.GPIO_Mode = GPIO_Mode_OUT;
gpio.GPIO_Pin = LED2_PIN;

gpio.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(LED2_GPIO_PORT, &gpio);
GPIO_WriteBit(LED2_GPIO_PORT, LED2_PIN, Bit_SET);
while(1)
{

}
}

Which should just turn on LED2, but nope, nothing. We have another spare board, so I’ve switched to that but got the same result.

PA13 & PA14 are still pulsing and PB4 is still steady. PA13&14 don’t have any alternative functions according to the documentation, PB4 is a PWM pin & used for SPI1.

I just noticed there are 2 errors, ‘Program “arm-none-eabi-g++” not found in PATH’ and ‘Program “arm-none-eabi-gcc” not found in PATH’. I’m guessing this is the problem, although I haven’t change the path variable, or change the toolchain filepath. I’ve tried resetting the preprocessor include paths, but no luck.

Hello, the fact that PA13 and PA14 are pulsing is not a part of your program, these PINs are used by the debuger to talk with your PC, so don’t worry about it.
And be careful if you have to assign these pins to another use, you may not be able to program your card anymore (that’s no big deal, you’ll just have to use ST-Link utility to reset your card and you’ll be on the road again)


Ahah, progress. I was trying to use it in release mode, not debug. Debug works fine now, thanks for your help.
I was trying to use the Ac6 STM32 debugging launcher, so that would probably explain why only debug is working.


France

Hi,

Just a few things:

  1. You explicitly set the GPIO bit to 1; I’m not sure if this will light up the led or shut it down (often LEDs are active when the GPIO output is set to 0 as outputs are often able to draw current but not to provide so much.
  2. With your scope you look at PB4, while the LED is on PA5... As you said PB4 is a PWM output or can be used to SPI1, but the LED is not connected there.
  3. If PA13 and PA14 continue to pulse, that really mean that this is not your program’s fault as it does nothing...
  4. When looking more precisely at your first program, I just noticed that you don’t have any delay in your infinite loop, meaning you just toggle the GPIO about 10 miilion times per second... You should probably see it partly lighten-up, but not blinking.
    • To blink it twice per second replace the second call to GPIO_WriteBit (which is useless) by a loop like: for (i=0; i < 5000000; i++);
    • I just tested this on a NUCLEO-f411RE (using GPIOA5 explicitly as this board is not really supported by StdPeriph) and it works like a charm. (BTW on this board setting the GPIO to 1 light-up the LED, resetting it to 0 shut it down).


Bernard

PS: The “arm-none-eabi-gcc not found” error is a known bug; it can be suppressed by seleting these errors in the “Problems” view and hitting “Delete”; it appears at project creation and will not appear again.

1) Setting the bit to 1 lights it up, 0 shuts it off. Any leakage current doesn’t look like it’s enough to turn it on.
2 & 3) I know neither of these should be related to what I’m doing, but I was curious to see if I was having any kind of effect on the GPIO pins at all. Strangely, I still see a high voltage on PA13 and PB4. You’re right though, it shouldn’t be anything to do with my program.
4) Again, you’re quite righ, I’ve stuck a big delay in to check and it’s blinking perfectly.

Well, getting there with baby steps.

Thanks,
James


France

Hello,

Yes, there is a bug for now in the “Run” feature (by opposition to “Debug”) that prevents it to flash the program; we’re working on this and it will be fixed in a future release.

In the mean-time, if you want to test a program compiled in the Release configuration (to check that optimization does not break anything) you may create a second debug configuration where:

  • In the Main tab
    • Select “Release/program.elf” as program to execute
    • Use the Release configuration
  • In the Startup tab:
    • Uncheck “Load symbols” (there is no symbols in a program compiled in the Release configuration)
    • Uncheck “Set breakpoint at: main” (there is no symbols)


Then you can start your program by debugging using this configuration; it will be flashed and started. However, when your test is finished, you should go to the Debug perspective (top right button) and stop the debugger (hitting the red square button); if you wand your program to run again, just hit the reset button on the board.

Bernard