Missing features in Blinky example on F429 Discovery board

Absent any support, I have continued to dig into this
project myself. According to the schematic I downloaded for
my Discovery board, only 2 LEDs: LED3 & LED4 are directly
soldered to GPIO ports PG13 and PG14 of the processor and
under program control. When I stepped through the
initialization routine and monitored the configuration and
data registers of GPIOG I could see no changes whatsoever.
The initialization is controlled by an array of struct whose
origins are difficult to find, but I do find the following
definition in file LED.c:

const GPIO_PIN_ID Pin_LED[] = { { GPIOD, 12 }, { GPIOD, 13 }, { GPIOD, 14 }, { GPIOD, 15 }
};

from which I infer this module assigns 4 LEDs to port D and
none to port G.

So either I have the wrong board, or loaded the wrong Blinky
application, or Keil released this eval software without
testing it on actual hardware.

I attempted to address this issue at the source: inside
LED.c, but it appears to be write-protected. I have as yet
found no way to track it down on my disk drive.

Does anyone know how?

loaded the wrong Blinky application,

sounds that way. GPIOD sounds ARM. the '51 'speaks' Port0, Port1, ....

BTW with the F429 you would, probably, be better off at the SILabs forum http://community.silabs.com/

While Bob comes by here occasionally, usually when things are on fire, you might be better served by just emailing him directly, his address is on the application note.

This is a USER forum, not an official Keil support venue, they have a direct email address, which I believe is support@keil.com http://www.keil.com/support/

The LED's you describe are for the STM32F4-DISCO, the board you have is the STM32F429I-DISCO

The printf() stuff is not in the blinky from the app note, or for that matter the general blinky examples, so there's definitely an issue with what's being provided in the ZIP vs the app note. For printf() stuff you'd be better to look at the retarget.c/serial.c type files, and use the ITM_SendChar() functions to send characters to the SWO/SWV interface.

http://www.keil.com/appnotes/docs/apnt_261.asp
http://www.keil.com/appnotes/docs/apnt_230.asp

BTW with the F429 you would, probably, be better off at the SILabs forum http://community.silabs.com/

sorry, missed the 'ARM' however this show how important full part numbers are, SILabs also make a ...F429 (the rest of the numbers are different from the ST)

Erik,

I always put the full P/N in the first line, but you are
correct that in forums that are not HW-specific, I should
have put it in the subject line, no matter how long that
would make it (apologies).

All,

I have been using Keil debuggers since 1996, mostly with
8-bit products and know how to debug with far less than
the Cadillac features I see in MDK5. If I never get the
printf feature to work, that will only slow me down a bit.

However, if I can't get the Blinky example app to blink
my LEDs, that is a show stopper.

I have been reluctant to use freebie examples on the claim
they get you up and running faster than writing the first
application from scratch because if the freebie sample has
a bug it in, it is far more difficult to troubleshoot than
my own code because the freebie code has a massive amount
of superfluous complexity built into it having nothing to
do with my task.

So, it still looks like the problem is my app is
talking to the wrong ports to drive my LEDs, as suggested
by the LED.c file I see in the code window of MDK5.

When I look at the directory structures under c:\keil_v5
created by the MDK5 installer (and enhanced by me with
more code from the Keil app notes) I find 8 files named
LED.c. They are deeply nested in the structure (some up
to 9 levels) and to display them clearly I need access to
more HTML tags than this forum will allow. I have uploaded
my illustration file here:

  - my.execpc.com/.../LedDrivers02.html

and request you view it with a browser while I ramble on.

I extracted the code that initializes the LEDs from each
file (concerning myself only with those related to the
STM32F4) and tacked that code to the right.

Here you can clearly see that only the LED.c under the
Blinky and RTX_Blinky examples of Keil app note initialize
port G. The other 4 address only port D.

Under directory:

C:
 +--Keil_v5
     +--ARM
         +--Examples
             +--Boards
                 +--ST
                     +--STM32F4-Discovery
                         +--Blinky-KeilAppNote253
                             +--Blinky

there is a file called Blinky.uvprojx, which I took to be
a project file. When I load that file into MDK5, I get
the window documented at the bottom of the web page. This is
clearly not the LED.c file in the Blinky directory.
Furthermore I cannot edit it, so infer it is write-
protected. meaning it is probably one of the 3 files I
have marked in red (unless it is not stored under
c:\Keil_v5) in the directory structure.

Getting back to my original question...

It would be nice to be able to track this file to its actual
storage location and I want to know if one can do that with
MDK5.

I'm leaving this on the forum because I think it's a question
of broader interest. The problem belongs to another class
of program complexity I call "intermodule dependencies". As
far as I know there are no generally-accepted standards
reining in the spaghettification of an application in this
domain, so styles are still specific to the individual
programmer. (Shame that is.)

If none of you knows the answer, I will then send it on to
Mr. Boys.

When you open a project, you can look at the properties for the individual files in the project. That gives you information about the path of the file and any special build options.

CORRECTION!

Despite all my pre-cautions, I still managed to get lost in
that directory jungle and loaded the wrong app. The Blinky
app that comes with App Note 253 MIGHT be functional, but
will not build under MDK5 without installing "Legacy Support"
as it was created with MDK4.

I can't install "Legacy Support" myself and the guy who can
was out to lunch, so while waiting I tried using the "20)
Creating your own project from scratch: Using Blinky source
files" chapter of the App Note 253 PDF, but instead of
creating an empty project, pulled in the source files from
the App note 253 .zip module.

App Note 253 itself was written for MDK4 and there are
subtle differences in several of the windows, but I managed
to guess my way through all of them, build, load, and run
the Blinky example without further tweaking of the source
files. (It works!)

So, while I would still like to know how to identify the
location of a file if it's not in the project directory,
this gap is not holding me up any more.

Thanks for your hints!