f407vet6 & f407zet6

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Mon Jun 05, 2017 4:39 am

danieleff wrote:In the linker the ram is set to 112K https://github.com/rogerclarkmelbourne/ ... jtag.ld#L8
I think it should be 128K. (There is a 112K region directly followed by a 16K region)

To use the extra 64K:
1. jtag.ld: below the ram line, put `ccmram (rw): ORIGIN = 0x10000000, LENGTH = 64K`
2. common.inc: below .bss section, put

Code: Select all

.ccmram (NOLOAD):
      {
        . = ALIGN(8);
        *(.ccmram .ccmram.*)
      } > ccmram
3. And in your code, use as
`uint8_t __attribute__((section(".ccmram"))) data_in_extra_ram[14*1024];
4. you need to zero out these variables yourself

I do not think it is possible to automatically spread out variables between the different not continuous regions.
Thank you very much for this information, now things get clearer for me.

I had planned to look what this "ccmram" is in the processor spec documents.
I think I can split the buffer in two parts, one placed by the linker and one in the fix location of the ccmram.
Modification to drawPixel for this is easy, but update from buffer to e-paper can't then just use existing drawBitmap.

Jean-Marc Zingg
I like clickable and valid links that point to relevant information

stevestrong
Posts: 1611
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: f407vet6 & f407zet6

Post by stevestrong » Mon Jun 05, 2017 7:24 am

I think in that repo the PIN_MAP is still in RAM, so that will also reduce your available RAM.

Btw, you could eventually try the generic F4 branch of my repo, there is already the generic F407 board defined as variant, and also some optimizations done. A minimal sketch uses ~12kB RAM, wherein USB alone more than 4kB.
http://www.stm32duino.com/viewtopic.php?f=39&t=1976

User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Mon Jun 05, 2017 7:51 am

stevestrong wrote:I think in that repo the PIN_MAP is still in RAM, so that will also reduce your available RAM.

Btw, you could eventually try the generic F4 branch of my repo, there is already the generic F407 board defined as variant, and also some optimizations done. A minimal sketch uses ~12kB RAM, wherein USB alone more than 4kB.
http://www.stm32duino.com/viewtopic.php?f=39&t=1976
Thank you Steve, I will try this.

But every time I download and add a new version of the STM32 package, I get the nagging library update notifications again:

http://forum.arduino.cc/index.php?topic ... msg3255241

and with the newest I get these errors:

Code: Select all

Index error: could not find referenced tool name=arm-none-eabi-gcc version=4.8.3-2014q1 packager=arduino
Index error: could not find referenced tool name=arm-none-eabi-gcc version=4.8.3-2014q1 packager=arduino
Index error: could not find referenced tool name=CMSIS version=4.5.0 packager=arduino
Index error: could not find referenced tool name=CMSIS version=4.5.0 packager=arduino
So I try to avoid STM32 package updates.

Jean-Marc
I like clickable and valid links that point to relevant information

stevestrong
Posts: 1611
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: f407vet6 & f407zet6

Post by stevestrong » Mon Jun 05, 2017 8:06 am

I don't install Arduino_STM32 with library manager.
Simply download from github and extract the files to the appropriate folders (delete any previous version before).

User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Mon Jun 05, 2017 9:30 am

stevestrong wrote:I don't install Arduino_STM32 with library manager.
Simply download from github and extract the files to the appropriate folders (delete any previous version before).
That's exactly what I do. (Is there any other method for the stm32duino.com package? adding json link to preferences would be nice!).

My native language is not English, maybe this is the reason I get misunderstood in my posts so often.
I like clickable and valid links that point to relevant information

stevestrong
Posts: 1611
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: f407vet6 & f407zet6

Post by stevestrong » Mon Jun 05, 2017 10:01 am

Zingg_JM wrote:My native language is not English, maybe this is the reason I get misunderstood in my posts so often.
Never mind, you're not alone, including me.

When you post something, always check whether you understand it and if you would be able to give a reasonable answer when you read what you have written ;)

So, what is actually your problem?

User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Tue Jun 06, 2017 12:06 pm

Any explanation for slow clock issue with my DESTM32-L STM32F704ZET6 board?

This board starts up with 16 times slower speed, intermittently to almost every time.

I download code trough ST-Link. The board has no reset button, but I added a push button. Reset by push button seemed not to work, e.g. no serial output, and reset by ST-Link (MCU reset, Application started) intermittently started, but drawing on e-paper was very slow.

Most of the time startup was ok after the second or third download of the same code, but failed again sometimes after code change.
With bitmap buffer added, startup starts slow every time, even with reduced buffer size.

The measured clock output to the display seems to be exactly 16 times slower then.

The same code runs fine on a STM32F407VET6 board, but I can't check with the e-paper display (no FCP connector, no e-paper specific supply voltages).

BOOT0 has 10k to GND, and I connected it directly to GND for test, BOOT1 has no connector, but seems to have 10k to GND.

Has anyone seen such a strange behavior?
Has anyone an explanation for this behavior? fall-back to the slow clock option of the processor?

Can I kick the processor clock in the setup function?
I like clickable and valid links that point to relevant information

User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Tue Jun 06, 2017 2:57 pm

This is really strange:

it works for:

Code: Select all

Global variables use 36336 bytes of dynamic memory.
or less, but no more for

Code: Select all

Global variables use 36536 bytes of dynamic memory.
or more.

So maybe the processor on that board has a "Dachschaden", a defect in its brain.
I like clickable and valid links that point to relevant information

stevestrong
Posts: 1611
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: f407vet6 & f407zet6

Post by stevestrong » Tue Jun 06, 2017 3:19 pm

In absence of other information, assuming that the code is same, I would rather think on RAM overflow, data being overwritten due to that missing 200 more bytes.
Check the MAP file for RAM limitations.

User avatar
Zingg_JM
Posts: 40
Joined: Tue Jan 17, 2017 10:46 am

Re: f407vet6 & f407zet6

Post by Zingg_JM » Tue Jun 06, 2017 3:20 pm

stevestrong wrote:I think in that repo the PIN_MAP is still in RAM, so that will also reduce your available RAM.

Btw, you could eventually try the generic F4 branch of my repo, there is already the generic F407 board defined as variant, and also some optimizations done. A minimal sketch uses ~12kB RAM, wherein USB alone more than 4kB.
http://www.stm32duino.com/viewtopic.php?f=39&t=1976
I tried with this version, but it seems the processors lost some ports and pins.
I like clickable and valid links that point to relevant information

Post Reply