Computation Results are Rubbish if Variable in CCM

[julian2]

Posted on October 02, 2014 at 18:15

The strangest thing is happening.

I do some DSP computation on float arrays with the CMSIS library, especially arm_fir_decimate_f32 on an STM32F407VG. I use CooCox.

As my need for RAM grew, I decided to relocate some arrays into the CCM. No big deal, I modified the linker script by adding:

.ccm :

{

  .= ALING(4);

  *(.ccm)

  .= ALIGN(4);

} > CCMRAM

And I placed a variable

float32_t workspace_f32[4096];

in the Core Coupled Memory with

float32_t workspace_f32[4096] __attribute__ ((section (''.ccm'')));

Everything compiles and links nicely, no problem.

For the FIR decimation I got 3 float array in the RAM, the input signal, the output signal and the state buffer.

I can move the arrays for the state buffer and the input signal to the CCM and everything works as before (except from cycles needed for the computation of course). But when I move output buffer array to the CCM, its contents are complete rubbish and entirely different from what they're supposed to be.

How on earth is this possible?

Regards,

Julian

#ccm-dsp-cmsis-m4-stm32f4-coocox

[Tesla DeLorean]

Posted on October 02, 2014 at 18:27

How on earth is this possible?

With the info presented, I don't know, CCM however does not support DMA or BitBanding

[waclawek.jan]

Posted on October 02, 2014 at 19:37

Where is the output buffer located, in absolute addresses? Don't you overflow the CCM?

JW

[Tesla DeLorean]

Posted on October 02, 2014 at 19:57

Don't you overflow the CCM?

Probably not with 16KB of floats, but the core would Hard Fault if you went outside the 64KB, and the linker should stop ridiculous static allocations.

Review .MAP, and be more specific about exactly what you're seeing, and demonstrate it in a fashion others might be able to replicate.

[John F.]

Posted on October 03, 2014 at 09:35

Is the CCM memory clock enabled?

RCC AHB1 peripheral clock register (RCC_AHB1ENR)

Bit 20 CCMDATARAMEN: CCM data RAM clock enable

This bit is set and cleared by software.

0: CCM data RAM clock disabled

1: CCM data RAM clock enabled

[julian2]

Posted on October 07, 2014 at 10:57

There's no overflow, the array is only 16kB (4096 floats), I also looked into the map file.

Thanks for the tip with the extra clock, totally overlooked that!

Does not solve my problem however, but the rubbish I get is different depending on whether CCMDATARAMEN is set or not.

I'll post some code here shortly, I just need some time to replicate the error in a small example outside of my entire project.

[waclawek.jan]

Posted on October 08, 2014 at 08:57

> There's no overflow, the array is only 16kB (4096 floats),

Yes, but in your initial post you told us that you have moved two other arrays into the CCM.

> I also looked into the map file.

Can you please post the relevant portions of it (i.e. the .ccm)?

Also, where is stack (and heap, if used) located?

JW

[julian2]

Posted on November 11, 2014 at 17:11

Hey guys, sorry for the delay. I had to work on other stuff.

Thanks for all your comments. When I was going to all of the code again to isolate the problem in a simple example I basicly found a really stupid bug of mine. Some of the memory was not written on, my algorithm just jumped and left a block of memory untouched. So naturally it contained some uninitialized values.

It was never a problem in RAM, because apparently there were only zeros in the uninitialized block, but not so in CCM.

[waclawek.jan]

Posted on November 12, 2014 at 09:53

Thanks for letting us know.

This may be a clue for others who tinker with the default linker script.

JW