SAI_AudioPlayback example with ArmClang

[Jnevi.1]

Hi,

i tried the SAI_AudioPlayback example for the h745 discovery board. I'm using Keil and with the keil 5 armcc compiler everything works fine.

Now i switched to armclang 6 and replaced the "libPDMFilter_cm7_keil_wc16.lib" with "libPDMFilter_cm7_gcc_wc16.a" i can compile & run the program but soundoutput is not working.

i attached a screenshot. for the input i get pdm values but pcm is always zero. If i compile with armcc the pcm values are not zero.

is there something i have to configure? i think maybe it is some signed/unsigned problem? does anybody have a hint what can cause this error?

Regards

[Piranha]

It's because of D-cache. Look at audioPdmBuf addresses - on the right it's located at a data/bss sections, while on the left it's at some dedicated memory region most likely configured in MPU. For testing purposes just do not enable the D-cache.

Not necessary to make this example working, but still:

https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers

[Jnevi.1]

This is the debug output with the armcc compiler

The dcache gets invalidated by the program(it's the st example) and with armcc everything works fine so my conclusion was: it is something compiler related but maybe this is misleading?

(but i will check the dcache anyway because i'm not saddle-proof regarding this topic)

[Jnevi.1]

Just to be Sure i disabled the Cache & d-Cache with the cmsis functions but still no luck with armclang :\

[Piranha]

> Look at audioPdmBuf addresses - on the right it's located at a data/bss sections, while on the left it's at some dedicated memory region most likely configured in MPU.

Start by adjusting the audioPdmBuf definition to get it to the same 0x38000000 address. For Clang it should be similar to GCC:

https://developer.arm.com/documentation/100067/0612/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----section--name-----variable-attribute

> The dcache gets invalidated by the program(it's the st example)

Which means it's written by incompetent fools. They don't understand cache or anything non-trivial. My article shows how to do it correctly.

[Jnevi.1]

has there every an employee looked into this? as it works with one compiler out of the box and not with the newer one i think this should be looked into? or am i the only one with this problem?

[Piranha]

My posts already give an answer. If you do not understand the code, then start with learning the software development first!

[Jnevi.1]

what is your problem? as said before: this is example code which works with one compiler and not with the other!

[waclawek.jan]

In the first post, the breakpoint appears to have stopped execution before actually calling AUDIO_IN_PDMToPCM() function, as consequence of debugging optimized code. If it was before the first call to that function, the output buffer might've been cleared from the startup code if it's a global variable.

JW

[Jnevi.1]

on both screenshots i stopped in line 200 after the lib was called(the marker is the yello arrow, not the blue one)

on both screenshots the variable is placed at the same memory location @piranha!! so no! this likley has nothing todo with d-cache or anything(or it is something this lib needs to handle differently internal, which i doubt atm)

with armcc it works, with armclang not. (same code)

only thing changed is this lib because cubemx delivers other libs for each compiler compilers. and as said there were problems with other libs before because i think signed/unsigned behaves different iirc

[Pavel A.]

The name of the lib suggests that it is intended for gcc, not clang toolchain. Are you sure gcc and armclang are compatible on ABI level?

> signed/unsigned behaves different 

*This alone * should be very unlikely to change between gcc and clang.

[Jnevi.1]

it was a short enum/wchar problem .

https://community.st.com/s/question/0D50X0000AlgbG2SQI/arm6-compiler-support

So behaves differently is wrong, just the compiler options must fit.

and https://support.touchgfx.com/4.16/ja/docs/miscellaneous/known-issues#touchgfx-4140

touchgfx added armclang support and there it is said you should use the gcc libs. for touchgfx i can confirm it is compatible with armclang

[Jnevi.1]

looked into it again after all this time. pavel is right. it was a lib problem. i don't know if the files were changed or there were updates or it would have worked in the beginning. tried with the keil libs again and it works with armclang 6.19

maybe the touchgfx lib handling put me on the wrong track there.

it is not a cache problem it's a lib problem(made by me as it seems :( )

i recreated the project with cubemx for the 745 disco board and now it is working