2017-12-20 02:17 AM
Hey guys, I'm trying to do something that might be really a noobish thing (will ask in a different thread, and I recognize that there's a strange thing happening. I'm using an STM32 Nucleo64 L073RZ
I am trying to send a UART message by pressing the USER_BUTTON, and have programmed that through CubeMX with the MDK-ARM Keil v5 toolchain. There wasn't any failure during compiling nor when flash loading the program. However, I saw that even the 'Blinking ' action that I had programmed below didn't show on the main board.
If I just download the basic Blinky program from OS.Mbed compiler, it works just fine.
The strangest thing is, if I flash load the bin from Mbed online compiler, the LD1 will end with Green light (after flashing red/green) but with Keil, it stayed Red. Is that actually normal? Is there anyway I can debug this slowly?
Here's my code bit in Keil.
while(HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13)== 1) {
HAL_UART_Receive(&huart2, (uint8_t *) result, sizeof(result)-1,200); } // Do nothing because button is not pressedfor (int i=0; i<5; i++){ //blinking sequence before transmitting the text
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(500); } HAL_UART_Transmit(&huart2, text, sizeof(text)-1,200); //When the button is pressed, it goes to here, //then gets the handle for which UART, get the address of //data to be sent 'text', send the size of the data, and the timeout 20 ms. while (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == 0){} } /* USER CODE END 3 */#nucleo-l0732017-12-20 05:18 AM
Hello,
I recommend you to check the
GPIO_IOToggle example in the STM32CubeL0,
It will help you on your application:STM32Cube_FW_L0_V1.10.0\Projects\STM32L073RZ-Nucleo\Examples\GPIO\GPIO_IOToggle
Best Regards
Imen
2017-12-20 06:18 AM
The strangest thing is, if I flash load the bin from Mbed online compiler, the LD1 will end with Green light (after flashing red/green) but with Keil, it stayed Red. Is that actually normal? Is there anyway I can debug this slowly?
If I remember correctly, MBED requires a special bootloader on the target board, that presents itself as mass storage to 'drop in' the application.
That would conflict with the Keil toolchain/debugger, that erases/overwrites this bootloader mercilessly.
Isn't this covered in the user manual of the Nucleo board ?
2017-12-20 11:57 PM
I've figured it out. Yes, it's normal.
I came from OS.Mbed, and that was the mindset that I went in with. I skimmed the user manual because of that, and when in time I turned to Keil that has a much more comprehensive support, I am overwhelmed with the amount of detailed info.
Anyway, the Nucleo user manual does not specify exactly what the LED means as far as I have read it in terms of different toolchain, or more specifically the difference between the Mbed 'Drop In' bootloader and the Keil toolchain.LEDs
The tricolor LED (green, orange, red) LD1 (COM) provides information about ST-LINKcommunication status. LD1 default color is red. LD1 turns to green to indicate thatcommunication is in progress between the PC and the ST-LINK/V2-1, with the followingsetup:• Slow blinking Red/Off: at power-on before USB initialization• Fast blinking Red/Off: after the first correct communication between the PC andST-LINK/V2-1 (enumeration)• Red LED On: when the initialization between the PC and ST-LINK/V2-1 is complete• Green LED On: after a successful target communication initialization• Blinking Red/Green: during communication with target• Green On: communication finished and successful• Orange On: Communication failureUser LD2: the green LED is a user LED connected to Arduino signal D13 corresponding toSTM32 I/O PA5 (pin 21) or PB13 (pin 34) depending on the STM32 target. Refer to Table 11to Table 23 when:• the I/O is HIGH value, the LED is on• the I/O is LOW, the LED is offLD3 PWR: the red LED indicates that the STM32 part is powered and +5V power isavailableHowever, now I see that when Keil is put in Debug session and we're stopping at a certain program counter, the LD1 turns green.So thanks for the help, guys