cancel
Showing results for 
Search instead for 
Did you mean: 

Step 2, LED Blinking with STM32F769I-Discovery

IvanS
Associate II

Dear community,

I am totaly new and trying to get some idea on STM32F7...board

I've got opened an example project, provied within IDE. If I compile code and download it to MCU, everything works fine: 2 LEDs are blinking:

This is the main code for LEDs blinking within main function:

while (1) {

   while (Buttons_GetState() & 1U);       /* Wait while holding USER button */

  osSignalSet(tid_Thread_LED, 1U);       /* Signal LED thread             */

  osDelay(100);                          /* Wait 500ms                    */

 }

It does blink, when no button is pressed.

in order to get better understanding in MCUs I am trying to simplyfiy the code and change it in the following way:

 while (1) {

      if(mytempV %2 == 0){

      HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9,GPIO_PIN_RESET);

               }

      else {

      HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9,GPIO_PIN_SET);

      }

         mytempV++;

   osDelay(500);                          /* Wait 500ms                    */

 }

I have expected that one of LED will start blinking. I checked in manual that red LED seets on Port B pin 9:

0693W000000U4dvQAC.png

However, nothing was happening.

If I use

while (1) {

     HAL_GPIO_TogglePin (GPIOB, GPIO_Pin9 )

   osDelay(500);                          /* Wait 500ms                    */

 }

result is the same: nothing.

What could be the reason for that?

Shouuld I allow somwhere independently the GPIOs to be changed?

or I messed up with use of osDelay()?

Best regards,

Ivan.

1 ACCEPTED SOLUTION

Accepted Solutions
Piranha
Chief II

B9 is the physical BGA package pin number. The PJ13 is the peripheral port and pin.

View solution in original post

8 REPLIES 8
Piranha
Chief II

B9 is the physical BGA package pin number. The PJ13 is the peripheral port and pin.

IvanS
Associate II

Pirahna,

thank a lot for your answer. Indeed, I have tried to change to

     HAL_GPIO_WritePin(GPIOJ, GPIO_PIN_13,GPIO_PIN_RESET);

and it helped.

However, I am a bit confused by now with this "double naming" system for Ports and pins. I find it more consistent to adress directly pins as I learned it for Atmega8 about 15 years ago...

Thanks again.

Ivan.

Piranha
Chief II

The reason why we have "double naming" is the fact that the same silicon comes in different packages with different pin count.

https://protostack.com.au/wp-content/uploads/IC-ATMEGA8A-PU-3.jpg

Package pin 28 is PC5. How is ATmega8 different in this regard?

KnarfB
Principal III

Its quite common to name BGA package pads B9 etc., whereas the port+pin combination applies to the internal die regardless of the package used.

Each vendor has their own ways of approaching and doing things, so you're going to have to pay attention to the column headings and nomenclature for the stuff you're using today, not a decade and a half ago. You're also going to need to be aware of things running at 1.25V internally, and having 3.3V IO (or whatever).

There's also a lot more going on in the ARM parts, typically multiple instances of peripherals, with large banks of registers, and independent clocks for everything.

The "Bingo/Battleships" numbering of BGA ball's is also very common. ST has the same die is multiple packages, the datasheet usually covers the pin "numbering" vs GPIO Bank, Pin and Alternate Function designations.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Yes, I think this a bad analogy, bit like complaining Ford and Ferrari have different "REDS"

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Battleship analogy... in conjunction with trouble-shooting BGAs... aptly named... 🙂

To add to the confusion, some devboards' manuals use also the Arduino connectors pins names/marking...

JW

IvanS
Associate II

Thanks to all for the answers.

I was not going to initiate a philosophical discussion on this subject. Sorry.

I was thinking (as usually) in a limited way: that all who work with MCUs ALWAYS have to works with physical layouts to consider any ADC or pin Up/Down for control smth around MCU, but, indeed, most of the programming work is done with USB/SPI/Display – communication, and in this case it is convenient to think the hardware level apart from software view to hardware.