Programming ‘F407 …

So I have one of those tiny ‘F407VET boards. (actually I have a few of them)

I do all my work on Linux, particularly I use Fedora Core 22 at the moment.

I have written a simple sketch to make some LEDs blink …

Now, I am trying to figure out how to program this baby. I used F103 parts
before, and it was trivial through the built-in serial boot loader.

With the ‘F407 things appear much more complex …

First I tried St-Link. I can upload the sketch and it will run properly blinking
the LEDs. And I can read it back and it appears to be the same file as I upload.

BUT, once I hit reset or power cycle this board, my sketch does not run
anymore. I know Boot0 and Boot1 have to be both zero for it to run from Flash,
and I have tried all combinations of the two, nothing. It does not run my sketch.
I can upload it again (setting boot0 to 1), and then it will run again as long as I
don’t reset/power cycle the board.

So, next I thought lets get the built in boot loader to work. Took me a while to learn
about DFU …

I installed all DFU tools, all looks good. I plug in the board (boot0=1), and lsusb shows:
Bus 003 Device 036: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

Looks good, right ?

I than run “dfu-util -a 0 -s 0x08000000 -D test.bin”, and I get
“File downloaded successfully”.

Than I use “dfu-util -a 0 -Z 17276 -U check.bin” and verify the upload really went fine.

And the files do match. All looks good.

BUT, with DFE it appears my sketch never gets executed.

I have tried various options when uploading my sketch, but no luck. I can power cycle
the board and read my sketch back, it’s all there, it’s all good.

Why does it not execute my sketch ? I used objdump to disassemble the file (test.bin).
The vector table is there, as expected, all the start-up code is there, and my test code.

Somehow the ‘F407 hates me

Any ideas suggestions ?

Oh, yeah, I am using the latest DFE utilities, v0.9.

And I get no errors or warnings whatsoever … so must be operator error ?

Somebody, please help !

Many Thanks !
rudi

% dfu-util -l
dfu-util 0.9

Found DFU: [0483:df11] ver=2200, devnum=37, cfg=1, intf=0, path=”3-13.3.4.3″, alt=3, name=”@Device Feature/0xFFFF0000/01*004 e”, serial=”386333563233″
Found DFU: [0483:df11] ver=2200, devnum=37, cfg=1, intf=0, path=”3-13.3.4.3″, alt=2, name=”@OTP Memory /0x1FFF7800/01*512 e,01*016 e”, serial=”386333563233″
Found DFU: [0483:df11] ver=2200, devnum=37, cfg=1, intf=0, path=”3-13.3.4.3″, alt=1, name=”@Option Bytes /0x1FFFC000/01*016 e”, serial=”386333563233″
Found DFU: [0483:df11] ver=2200, devnum=37, cfg=1, intf=0, path=”3-13.3.4.3″, alt=0, name=”@Internal Flash /0x08000000/04*016Kg,01*064Kg,07*128Kg”, serial=”386333563233″

I had a similar issue on a F103 “Ugly board”

It would work fine directly after upload via USB to Serial

but not after reboot

The only think I could think of, which may cause this, was faulty oscillator startup

But I tried changing the code to stop and restart the oscillator after a timeout, and it didnt fix the problem

Normally STLink uploads work well

So its strange if you can read back from 0x800000 and the binary is fine but it won’t run after a power cycle.
Did you read back after power cycling to check the program is still in flash ?

Are you sure its in flash not ram ? (this seem unlikely with STLink, but is possible with Serial upload)

Did you try using GDB (SOrry not sure how to connect GDB to STLInk as I use BMP)

Did you read back after power cycling to check the program is still in flash ?

Yes I did, and the comparison passed.

Are you sure its in flash not ram ? (this seem unlikely with STLink, but is possible with Serial upload)

Well, I guess this is really impossible to know, lol

If I go by the address, I am writing and reading 0x08000000 – and this should be flash

The only other thing that comes to m mind, is that the startup/initialization (in my file) is not working properly.

When I use st-link, it somehow configures the device correctly, but than if I try to run my code stand alone, the init fails …

I’ll have to look into this more.

Thanks,
rudi

when I program with St-Link, my sketch DOES run ! My LEDs are flashing !

But, once I hit reset/power cycle, it will not run again.

I tried all combination of boot switches as well.

Only right after programming the sketch it will run, and will run for hours if I don’t disturb it.

If I turn off the board, set both boot switches to zero, and power the board back up again (not through st-link),
my sketch does NOT to run …

Setting Boot0 to 1 and programming through st-link again, will get it working again !

Wery strange !

Thanks,
rudi

yeah, I tried that. Still nothing …

But that shouldn’t make a difference. In “normal” boot mode, when both boot0
and boot1 are 0, the device should work as normal.

I am not=w giving up the libs of Tilen, and will try my luck with Koduino !

Thanks,
rudi

You could try using STMs non Arduino tools e.g. STM32CubeMx, and download the free version of Atollic True Studio

The Cube is a big program and a bit daunting to get the clocks setup correct, but it does export a True Studio project file ( and Keil etc) , so you could try that instead.

Or, I think OpenOCD supports debugging via STLink, so you may be able to connect after a cold boot and get GDB to tell you the Program Counter addresss e.g. see where its stuck.

If you can splash out in $2 STM32F103C8 board, you could flash the Blackmagic probe firmware onto it, and use GDB directly and issue commands etc, to see whats going on.

Or, can you try uploading via USB to serial instead?

BTW. Are you sure your program is in Flash and not RAM?

Thanks for all the messages !

So I made a bit progress ! The Koduino library was surprisingly easy to set
up and use.

Edoglando, funny you should ask ! Out of the 10 boards I have, 4 seem
not to like the programming and do not execute my test sketch. The other
6 appear to work.

Now, I have 6 blinking boards and 4 “dead” ones. The dead ones are quite
interesting, and I wonder if it is a programming “bug” or “feature”. I can
program the Flash, and read back, even after power cycling, BUT, it does
not execute my simple blinking sketch. I have also been trying to force the
use of HSI, instead of HSE to avoid external crystal issues. Not sure if that
has propagated now or not, or even if it will become effective when using
dfu, or I must use st-link.

I ideas guys ? Sound like a strange issue, and 4 boards having the same
issue, is also strange …

BTW, destroyed a second st-link adapter last night. What’s wrong with these
things, ? Looks like the LDO is dead, if powered by external battery it seems
to work :/

Many Thanks,
rudi

I had a relatively similar issue on a F1 board: in my case it was due to a micro shortcut between the HSE pins (due to poor soldering) which prevented the correct startup of the HSE..
Symptoms in my case:

• the USB didn’t work
• Blinking worked but with incorrect timings when trying to use the PLL, the reason was that the PLL startup was failing and the HSI was used instead..
• furthermore: if I correctly remember blink worked only when using a SPL blink example; using an Arduino library sketch blink was not working, probably due to failure in initializing the USB Serial interface..

I could fix the problem cutting the shortcut.

hope this can help..

Are you making your own boards ?

clock could be an issue.

I think the code waits for HSE to start, in an infinite loop. I don’t think there is any code to timeout waiting for HSE then attempts to restart

I have a similar issue with a F103 board, it only works if I upload via serial (I havent tried STLInk), and run straight away, but if I power cycle, the board does not run

I presumed it was a faulty clock, but its not a good board, so I simple don’t use it any more.

I am using a very basic sketch, wich makes two LEDs blink (one on the
MCU board) and one on my base board). This is just in case the LED
on the CPU board does not work …

The MCU boards I am using, I bought online:
https://www.aliexpress.com/item/STM32F4 … 85751.html

I have made a base board where they plug it in. But I can operate them
outside my base board or plugged in, it doesn’t matter. Results are the same.

I have been thinking about HSE, and did add a “USE_HSI” ifdef block
in your libraries, Roger. Now am trying to find the correct place in Koduino.

I did a physical inspection and did not see anything wrong, like solder
shorts.

I have one question about the vector tables. I noticed that the vector table
might have something like this:

0800 1ffd, Reset Vector
0800 0d1d, NMI Vector

In both cases it’s an odd address, bit 0 is set (this actually applies to all
vectors).

But the actual locations are:
08001ffc <Reset_Handler>:
08000d1c <NMI_Handler>:

What is going on here ? It’s like actual address + 1 ?! This does work on 6 of
my boards, so it must be correct !

But I still would like to understand it. I have been searching through the almost
2000 pages of the programming manual, and nothing so far …

Many thanks !!!
rudi

Edogald, yeah they F407 device. And I don’t trust whats printed on them eiter – it’s coming from china after all. So I run this:

% st-info –probe
Found 1 stlink programmers
serial: 523f7106517755563306153f
openocd: “\x52\x3f\x71\x06\x51\x77\x55\x56\x33\x06\x15\x3f”
flash: 524288 (pagesize: 16384)
sram: 196608
chipid: 0x0413
descr: F4 device

So it is a F4 !

Cheers,
rudi

Edogald, yeah they F407 device. And I don’t trust whats printed on them eiter – it’s coming from china after all. So I run this:

% st-info –probe
Found 1 stlink programmers
serial: 523f7106517755563306153f
openocd: “\x52\x3f\x71\x06\x51\x77\x55\x56\x33\x06\x15\x3f”
flash: 524288 (pagesize: 16384)
sram: 196608
chipid: 0x0413
descr: F4 device

So it is a F4 !

Cheers,
rudi

Finally some good new !

All of my boards are working now. As many of you have suggested, the external Clock Oscillator
was not working properly (or most likely the external Crystal or the load capacitors are no good).

Anyway, I made some changes to the SetSysClock() routine to select HMI and also modified the
way the other dividers were generated to automate the whole process a bit. BTW, it looks lie all
the libraries I looked at so far, use exactly the same SetSysClock() routine with very little changes ….

Many Thanks !
rudi

Ok. Its not the first time we have seen an issue with a dodgy external clock

Can you post a snipped of your updated / improved clock code

yes absolutely, it’s attached below. Besides adding optional HSI
clocking, I also added resetting the device if the PLL does not
become ready …
I’m not sure how good of an idea that it, but I think it will give
better chances to start up than just sitting in an endless loop …

I think this code still needs a lot of more work. I think as a minimum
this functions should have two inputs to it: 1) Select HSI/HSE;
2) allow the user to specify the clock frequency he wants (but that
will break backwards compatibility ).

In HW design, we quite often use TCL scripts to configure IP
Core before synthesis. I think it would be really helpful to have
a configuration tool, that is platform independent, that can
generate some of the startup code, or may be just some
parameters …

If I get some time, I might start writing such a tool …

BTW, this file of the code snipplet below has ST copyright …

Best Regards,
rudi


/**
* @brief Configures the System clock source, PLL Multiplier and Divider factors,
* AHB/APBx prescalers and Flash settings
* @Note This function should be called only once the RCC clock configuration
* is reset to the default reset state (done in SystemInit() function).
* @param None
* @retval None
*/
#define USE_HSI
static void SetSysClock(void)
{
/******************************************************************************/
/* PLL (clocked by HSE) used as System clock source */
/******************************************************************************/
__IO uint32_t StartUpCounter = 0;
__IO uint32_t F_WANT, PLL_M, PLL_N, PLL_P, PLL_Q, PLL_VCO, PPRE2_DIV, PPRE1_DIV;

I guess to update libmaple we’d need to change the code in boards.cpp for each variant

static void setup_clocks(void) {
// Turn on HSI. We'll switch to and run off of this while we're
// setting up the main PLL.
rcc_turn_on_clk(RCC_CLK_HSI);

// Finally, switch to the now-ready PLL as the main clock source.
rcc_switch_sysclk(RCC_CLKSRC_PLL);
}

I’m confused. Did you want to continue working on the libraries you are maintaining ?

If yes, let me take another look, because I still didn’t have luck with them. But
if you want to keep them up, I would be happy to continue on the ‘F40x port …

Give me a few days to catch up with some other items, and then I will post an
update of the routine above …

Thanks,
rudi

I looked at the code you posted, but it didnt look like either the existing F1 or F4 code (as far as could tell), it looked like you added a new function to setup the clocks and probably changed other parts of the code to call your new function instead of the existing clock setup code.

So I was trying to work out how I could merge your new code with the existing code, just to add the ability to include a timeout on the HSE starting, and to loop back around and try again, if the HSE failed to start before timeout

However I may have miss understood what you have done.

Either way, this problem hardly every happens to anyone else, so its not a critical fix and can be added to my very very long To Do list

Here is an updated SetSysClock function. I don’t think I fixed anything in it, just tried to rename
and make some parameters explicitly visible – mostly for my own understanding.

The only “new” thing is being able to select HSI. This routine is taken from Kodunio,
But I think is mostly identical to what’s inside your libraries.

If you are ging to keep on maintaining your libraries, I’ll go back and look at them and see
if I can make them work for me.

I was under the impression you did not think it would be worth while to make any changes
since ST is eventually going to come out with support ….

Best Regards,
rudi

/**
* @brief Configures the System clock source, PLL Multiplier and Divider factors,
* AHB/APBx prescalers and Flash settings
* @Note This function should be called only once the RCC clock configuration
* is reset to the default reset state (done in SystemInit() function).
* @param None
* @retval None
*/
#define PLL_P_ADJ(x) (x == 2 ? 0x0 : \
x == 4 ? 0x1 : \
x == 6 ? 0x2 : 0x3)

}
else
{ /* If HSE fails to start-up, the application will have wrong clock
configuration. User can add here some code to deal with this error */
NVIC_SystemReset();
}
}


I suspect, for various reasons, that the libmaple core will continue to be used for a long time.

So I will try to apply your fix for this ( as well as other fixes people send me, including as PRs etc)

But I have to prioritise which changes I get to first, as I am rather time-poor at the moment

why don’t you hold off applying any fixes …

Let me get it all working and then send you a complete working version, which you can integrate with your changes …

I found some more bugs today, that need to be fixed …

Cheers,
rudi

No rush….

I have a question if I may after I reslly summarize the challenges you experienced.

In your Post you indicated you were using the STM32F407VET6 Mini. These STM32F407VET6 Mini boards presented challenges. Some boards were fine running your sketch after a Power On or Reset and others not. You found the source of the challenges that appears likely in lowel code for the STM32.

My question is is do you feel the STM32F407VET6 Mini is a board that someone just starting into STM32, has only done a bit of dabbling in last few week on an Adruino, and has a long systems technical backgound will be fine with the STM32F407VET6 Mini? I ask as the STM32F407VET6 Mini is one of a few STM32 boards I am to considering for something important I need to build for me. An important personal need device.

I have ordered a Maple Mini and will order another Baite one in a few days. The Maple Mini may barely have the least number of pins I need for the longer term goal as I add on the devices to the desired end result. The end result will need at least 12ADC, and at least 12 Digital, after SPI for SD card, and I2C for RTC and other I2C devices. I will start with a subset of the desired end goal.

I now know from some code I have written in past week as a framework to help me size Flash/RAM the Maple Mini may just squeeze in with the 20K RAM. The Maple Mini 64K or 128K Flash will be just fine for the code in question. I am hoping the RISC and processing clock speed of a STM32 will meet the other requirements I have. The Maple Mini I have ordered will be used to gain a sense of the CPU processing power ability vs my need. There will be no display, or if there is a display, a character display to display values once or twice a minute. Likely a 16×20 character display. So no graphics, or such requirements that might add to the processing requirements of the MCU in that respect.

I am looking at a few other STM32 boards that have a few more pins to way more pins than I need, but more is better than not enough. I have some other more routine hobby needs that the Maple Mini will be just fine for and I choose over an Adruino as the Maple Mini costs less and has more to offer than most of the typical Adruino devices commonly available and many use. I have one AtMega Adruino, and one more on way (common and not so common typical Adruino) to allow me to compare code/libraries if I have some issue with any porting or compiling of libraries in STM32 that having an AtMega based Adruino will help me in the figuring out the kinks to libraries/code that may not be available in STM32 and/or need tweaking for a STM32 based MCU.

Regards,

John L. Males
Toronto, Ontario
Canada
06 November 2016 07:23
06 November 2016 07:31 Usual Post Typo corrections. jlm

sorry, I am not online that often these days.

> @Luudee,
>
> I have a question if I may after I reslly summarize the challenges you experienced.
>
> In your Post you indicated you were using the STM32F407VET6 Mini. These STM32F407VET6 Mini boards presented challenges. Some boards were fine running your sketch after a Power On or Reset and others not. You found the source of the challenges that appears likely in lowel code for the STM32.

No, it was not a code problem. The external HSE oscillator does not work on some
of my boards. For me switching to the internal (R/C based) HSI oscillator is not a problem.
So that is what I am using now.

> My question is is do you feel the STM32F407VET6 Mini is a board that someone just starting into STM32, has only done a bit of dabbling in last few week on an Adruino, and has a long systems technical backgound will be fine with the STM32F407VET6 Mini? I ask as the STM32F407VET6 Mini is one of a few STM32 boards I am to considering for something important I need to build for me. An important personal need device.

The ‘Mini” board is more or less a bare board, with just the MCU, USB and SD card connectors.
No other “baggage” – that is what I wanted. I also need the ‘407 for performance reasons.

If your application requires the power of a ‘407, and you do not need other peripherals/interfaces,
that this is a good board. But be prepared for a lot of headaches. All open/free libraries for the
‘407 are a mess. I think there is alot more clean stable support for the ‘103.
>
> I have ordered a Maple Mini and will order another Baite one in a few days. The Maple Mini may barely have the least number of pins I need for the longer term goal as I add on the devices to the desired end result. The end result will need at least 12ADC, and at least 12 Digital, after SPI for SD card, and I2C for RTC and other I2C devices. I will start with a subset of the desired end goal.
>
> I now know from some code I have written in past week as a framework to help me size Flash/RAM the Maple Mini may just squeeze in with the 20K RAM. The Maple Mini 64K or 128K Flash will be just fine for the code in question. I am hoping the RISC and processing clock speed of a STM32 will meet the other requirements I have. The Maple Mini I have ordered will be used to gain a sense of the CPU processing power ability vs my need. There will be no display, or if there is a display, a character display to display values once or twice a minute. Likely a 16×20 character display. So no graphics, or such requirements that might add to the processing requirements of the MCU in that respect.
>
> I am looking at a few other STM32 boards that have a few more pins to way more pins than I need, but more is better than not enough. I have some other more routine hobby needs that the Maple Mini will be just fine for and I choose over an Adruino as the Maple Mini costs less and has more to offer than most of the typical Adruino devices commonly available and many use. I have one AtMega Adruino, and one more on way (common and not so common typical Adruino) to allow me to compare code/libraries if I have some issue with any porting or compiling of libraries in STM32 that having an AtMega based Adruino will help me in the figuring out the kinks to libraries/code that may not be available in STM32 and/or need tweaking for a STM32 based MCU.

> Regards,
>
> John L. Males
> Toronto, Ontario

Best Regards,

rudi

Thanks for all the messages !

So I made a bit progress ! The Koduino library was surprisingly easy to set
up and use.

Edoglando, funny you should ask ! Out of the 10 boards I have, 4 seem
not to like the programming and do not execute my test sketch. The other
6 appear to work.

Now, I have 6 blinking boards and 4 “dead” ones. The dead ones are quite
interesting, and I wonder if it is a programming “bug” or “feature”. I can
program the Flash, and read back, even after power cycling, BUT, it does
not execute my simple blinking sketch. I have also been trying to force the
use of HSI, instead of HSE to avoid external crystal issues. Not sure if that
has propagated now or not, or even if it will become effective when using
dfu, or I must use st-link.

I ideas guys ? Sound like a strange issue, and 4 boards having the same
issue, is also strange …

BTW, destroyed a second st-link adapter last night. What’s wrong with these
things, ? Looks like the LDO is dead, if powered by external battery it seems
to work :/

Many Thanks,
rudi

this board is from https://www.aliexpress.com/item/STM32F4 … 0.0.z0LbZh

very kindly they give https://www.aliexpress.com/item/STM32F4 … 0.0.z0LbZh

if you toddle off there and get the 39M zip, unzipping gives a missing central something error
i did a rename to lose the spaces and shorten it
then
zip -FF STM32F407VET6VGT6.zip -o 0123456.zip