STM32F769I-DISCO noise

[benny]

Posted on June 19, 2016 at 01:46

Hi,

I want to ask if someone can confirm that the STM32F769I-DISCO has a high-pitched

https://www.dict.cc/englisch-deutsch/buzzing.html

https://www.dict.cc/englisch-deutsch/sound.html

. I think it's from the display unit. So this is normal or should i complain my board?

Kind regards

Nyix

#worst-forum-ever

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on June 19, 2016 at 09:22

Mine aren't making any discernable noise.

[benny]

Posted on June 24, 2016 at 20:01

I tested a brand new board from another vendor. The display is making the same noise. So I think it's an issue with the display unit and I'm not sure if I get a replacement which is working.

I do some more tests with older persons. They couldn't hear this noise, because the frequency is very high.

For now I couldn't recommend the board. I hope ST is changing the display unit for free or they could fix it with another driver. :(

[Tesla DeLorean]

Posted on June 24, 2016 at 22:38

I'm on the older side, I can hear some of my other boards whistle.

In this case I would suspect it to be the back-light driver.

[AvaTar]

Posted on June 26, 2016 at 18:40

> So I think it's an issue with the display unit and I'm not sure if I get a replacement which is working.

 

Normally not.

First suspects are usually magnetic components, i.e. coils, which are operated near their resonance frequency (or one of their resonance frequencies). A ''strong word'' for those effects would be ''cheap design'' ...

> I do some more tests with older persons. They couldn't hear this noise, because the frequency is very high.

 

I'm on the older side, too, and I can hear better than most of my much younger workmates - including in the 10..15kHz range.

This is, as a matter of fact, no issue of age, but of continued damaging overload (discotheque, etc.).

I personally knew people in the late 80's, hearing and seeing as good as teenagers.

[AvaTar]

Posted on June 26, 2016 at 18:41

freakin' forum software !!!

[JB2500]

Posted on February 11, 2017 at 16:39

> I want to ask if someone can confirm that the STM32F769I-DISCO has a high-pitched buzzing sound.

Mine emits a clear tone (or whistle) at 8057 Hz. It's so loud that I've been using ear plugs to protect my hearing.

I've tested three boards and all do the same.

The tone appears to be emanating from the back of the removable display unit - probably either from the inductor or maybe from a nearby capacitor acting as a piezoelectric device.

The offending component(s) may well be part of a backlight PSU as suggested above; that was my thought too.

It's difficult for me to diagnose further as I don't have a means of extending the display connections to enable access whilst the device is powered up. I do know that the tone ceases if the device is powered up with the display unit disconnected.

The 8 kHz (approx) is more than just an audible tone emitted by the device. If the DAC output of the device is connected to my desktop computer, and the board ST-Link USB is connected to the same computer, then the 8 kHz tone appears at -39 dB wrt a 0 dB 440 Hz sine wave output from the same DAC.

That's a S/N ratio of just over 6 bits, which is of course extremely poor for a 24 bit DAC.

If the USB link is disconnected and the device is powered from batteries instead, the 8 kHz tone drops to -90 dB.

JB.

[JB2500]

Posted on February 11, 2017 at 20:54

Some more information regarding this problem:

Document http://www.st.com/resource/en/user_manual/dm00321394.pdf confirms that the culprit is indeed the display backlight PSU. It supplies 25.6V.

Here's a photograph of the circuit:

Here's some information on the STLD40D (L4D in image) PSU chip:

• http://www.st.com/en/power-management/stld40d.html
• http://www.st.com/content/ccc/resource/technical/document/datasheet/5b/92/e8/f8/41/e5/43/59/CD00098098.pdf/files/CD00098098.pdf/jcr:content/translations/en.CD00098098.pdf

The maximum on time is 4 us so the switching frequency is clearly not the direct cause of the 8 kHz whistle. However, the brightness is controlled by applying a PWM signal to the enable (EN) pin of the above chip. This is doubtless the cause of the problem.

Page 9 of document http://www.st.com/resource/en/user_manual/dm00321394.pdf shows the display backlight circuitry.

It shows the EN pin as either being connected to BL_CTRL via R4, or being connected to CABC, which is an output (I think) of the LCD display module, via R1 and CN2. It also shows EN as being connected to 3.3V via R5 (4K7).

On my display board, shown above, R1 is present and R4 and R5 are missing. The EN signal for the PSU chip therefore comes from the LCD module. Had R4 been fitted instead of R1, EN would have been connected to pin 53 of the DSI LCD connector, which is the LCD_BL_CTRL (LCD backlight control) signal on the main board, which in turn connects to port PI14 of the MCU (pin 81). In this case, the 8 kHz problem could have been solved by reprogramming the PI14 output.

When the demonstration software starts, with R1 present, the EN signal is a PWM signal of just over 8 kHz as expected. Initially it has a 50% duty cycle. If the screen brightness is increased to 100% using TouchGFX => External hardware => Screen brightness (swipe left), the EN signal changes to a duty cycle of 100%. (Incidentally, setting screen brightness to 0% results in a 20% duty cycle). With screen brightness set to 100%, and hence with a 100% duty cycle, the 8 kHz noise initially fades and then ceases.

Candidate solutions:

1. Move the zero ohm resistor from position R1 to R5, thereby connecting EN to 3.3V. This would result in maximum brightness and no 8 kHz audible noise.
2. Find out the method that TouchGFX uses to control the brightness via the LCD module, and use it to set the brightness to 100%.
3. Move the zero ohm resistor from position R1 to R4, fit a 4K7 (or preferably larger to reduce power consumption when the backlight is off) in position R5, and control the brightness using PI14. (R5 is so that the screen lights even when the MCU pin is not set as an output).
4. Reprogram the LCD unit to output a much higher frequency CABC. However, it may be that the output frequency is hardwired, in which case there's no solution to be found there. So far I've not found any relevant information.
5. Find a replacement for L2 etc that does not emit sound.

I've done option (1). It cures the whistle, avoids software compatibility problems, and solves the problem of the brightness control PWM (of whatever frequency) appearing on the DAC output.

Option (2) may achieve the same as (1) more conveniently (provided it can also set the brightness to 0%). However, I've not found any information on the method involved.

I hope this helps.

JB.

[benny]

Posted on February 15, 2017 at 21:51

Hi JB,

I will test your solution, but it will take some time, because I have  a lot to do at work. Thank you for your detailed research. I will reply if I tested it.

Edit: Short question before I move on. What happen if:

1) We place a 4k7 Ohm resistor to R5 as shown in the schematic? (R1 still fitted with 0 Ohm)

2) We ONLY place a 4k7 Ohm resistor to R5 and remove R1? 

Kind regards

Nyix

[benny]

Posted on February 21, 2017 at 11:45

Okay I want to solve the problem now for everyone who doesn't want to change the hardware / resistor.

As mentioned you can swap the 0 Ohm resistor from R1 to R5. In this case CABC has 3V3 and the display runs on full brightness.

With this idea (thanks so much J B !!!) I started to search for some more documents. For example the OTM8009A datasheet (the OTM8009A is directly connected to the LCD and generates the CABC signal). At page 65 section 5.2.36 you can find the command to set the display brightness (0x51h with one parameter in the range of 0x00h to 0xFFh).

Now we just need to send this command from the DSI to the OTM8009A. For this you can use two ways.

1)  

In the file otm8009a.c (Drivers->BSP->Components) at line 146

Change 'const uint8_t ShortRegData40[] = {OTM8009A_CMD_WRDISBV, 0x7F};'

To 

'

const uint8_t ShortRegData40[] = {OTM8009A_CMD_WRDISBV, 0xFF};'

This will set full brightness in the initialization and the noise will disappear.

2)

The file 'LCDConf_CmdMode_TE.c' provide the function 'void DSI_IO_WriteCmd(uint32_t NbrParams, uint8_t *pParams)'

After you call 'GUI_Init();' in your main-function or wherever you can do something like that:

Declare a variable like e.g. 'uint8_t lcd_brightness[] = {OTM8009A_CMD_WRDISBV, 0xFF};'

(OTM8009A_CMD_WRDISBV = 0x51h)

and call 'DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness);'

This will set the display brightness also to the maximum, but a short noise will appear in the start, because the brightness will initialize with 0x7Fh and is change some milliseconds after to 0xFFh.

I would prefer the first way. Change the driver and you never have this noise again. But you can experiment with the second solution and different brightness-level.

I hope this helps.

Hint: There are maybe some helpful other commands you want to send (e.g. display on/off) ! You can find them in the OTM8009A datasheet.

Kind regards

Nyix

[JB2500]

Posted on February 21, 2017 at 12:14

Great stuff, Nyix! Thanks for completing this. Great teamwork!

Incidentally, did you happen to see a way to increase the frequency of the CABC signal, e.g. to 25 kHz, so that the brightness can be controlled without the audible noise problem?

JB.

[benny]

Posted on February 21, 2017 at 12:35

Thanks. The datasheet says that the frequency for the CABC signal can be changed in the range of 38 Hz to 39 kHz. But I need some time to figure it out how to change it.

Edit: And I need to check if the LED-Driver can handle other frequencies.

Kind regards

Nyix

[benny]

Posted on February 21, 2017 at 20:36

Okay I get it working now.

So what to do step by step:

1) You need two pages from the OTMA8009A datasheet

Page 124 section 5.3.26 PWM_PARA3 (C6B1H) PWM Parameter 3

Page 127 section 5.3.28 PWM_PARA5 (C6B4H) PWM Parameter 5

2) In the beginning we should have a look at section 5.3.28 and the PWM_FREQ_SEL[1:0] parameter.

The default register value is 12h that means 0001 0010.  We only want to change the PWM_FREQ_SEL bits D2 and D1. The deafult value for D2 is 0 and for D1 1 (01).

With this information in mind we need to have a look at section 5.3.26. The default value here is 10h = 0001 0000 = 16 (dec). As you can see in the table with PWM_FREQ_SEL 01 and DBF 16 the PWM frequency is around 7.812 kHz.

3) More explanation: The LCD-Backlight-Driver has 5.5 microseconds as a minimum On-Time and 250 ns as the minimum Off-Time. That means if you want to dim the Backlight in 1% steps you need a maximum frequency of around 1818 Hz.

How to calculate: 1 / (100 steps * 5.5 micro seconds) = 1818 Hz.

For higher frequencies the resolution is greater than 1%.

So I tested 1.819 kHz this is in the table with the same PWM_FREQ_SEL value. Only the DBF value is raised from 16 to 72 (dec). But this makes noise too (not so loud). For lower frequencies you reach a better resolution so I tested 609 Hz (DBF = 217). There is still a bit noise, but not disturbing.

I decided to test higher frequencies with a resolution of 10% steps (that's totally fine for me). So I took DBF 6 this means 18.973 kHz. And the noise is gone (maybe not for my cat  )

3) Now I will explain how to write these values to the registers. The controller must be in command mode 2. This is only in the initialization.

3.1) You open the file 'otm8009a.c' and add 4 new variables (e.g.):

const uint8_t ShortRegData_PWM_FREQ_SEL_REGISTER[] = {OTM8009A_CMD_NOP, 0xB4};

const uint8_t ShortRegData_PWM_FREQ_SEL_VALUE[] = {0xC6, 0x12};

const uint8_t ShortRegData_PWM_FREQ_REGISTER[] = {OTM8009A_CMD_NOP, 0xB1};

const uint8_t ShortRegData_PWM_FREQ_VALUE[] = {0xC6, 0x06};

First I will tell you what does it mean:

You need to perform 2 operations. First set the register and second write the value.

To set the register we send the OTM8009A_CMD_NOP (=00h) and the last 2 bytes of the register address.

(e. g. section 5.3.26. the SPI/I2C/MDDI Address is C6B1h and has only one parameter so the last 2 bytes for the parameter are B1h)

Now we send the write instruction (C6h) and the value from the table, in my case 06h (= DBF 6 (dec) = 18.973 kHz).

3.2.) The DSI write command can be placed in the function

'uint8_t OTM8009A_Init(uint32_t ColorCoding, uint32_t orientation)'

between

'DSI_IO_WriteCmd( 15, (uint8_t *)lcdRegData24);'

and

'DSI_IO_WriteCmd(0, (uint8_t *)ShortRegData13);'.

That is before the comment with PWR_CTRL1.

In between you should place:

DSI_IO_WriteCmd(0, (uint8_t *)ShortRegData_PWM_FREQ_SEL_REGISTER);

DSI_IO_WriteCmd(0, (uint8_t *)ShortRegData_PWM_FREQ_SEL_VALUE);

DSI_IO_WriteCmd(0, (uint8_t *)ShortRegData_PWM_FREQ_REGISTER);

DSI_IO_WriteCmd(0, (uint8_t *)ShortRegData_PWM_FREQ_VALUE);

The first argument of DSI_IO_WriteCmd equals the number of parameter to write. 1 parameter = 0, 2 parameter = 1 etc.

4) Now you can test your code. I did it in this way:

Declare variables:

uint8_t lcd_brightness00[] = {OTM8009A_CMD_WRDISBV, 0x00};

uint8_t lcd_brightness10[] = {OTM8009A_CMD_WRDISBV, 0x19};

uint8_t lcd_brightness20[] = {OTM8009A_CMD_WRDISBV, 0x38};

uint8_t lcd_brightness30[] = {OTM8009A_CMD_WRDISBV, 0x4C};

uint8_t lcd_brightness40[] = {OTM8009A_CMD_WRDISBV, 0x66};

uint8_t lcd_brightness50[] = {OTM8009A_CMD_WRDISBV, 0x7F};

uint8_t lcd_brightness60[] = {OTM8009A_CMD_WRDISBV, 0x99};

uint8_t lcd_brightness70[] = {OTM8009A_CMD_WRDISBV, 0xB2};

uint8_t lcd_brightness80[] = {OTM8009A_CMD_WRDISBV, 0xCC};

uint8_t lcd_brightness90[] = {OTM8009A_CMD_WRDISBV, 0xE5};

uint8_t lcd_brightness100[] = {OTM8009A_CMD_WRDISBV, 0xFF};

Create an empty GUI Thread with

/* Initialize GUI */

GUI_Init();

WM_MULTIBUF_Enable(1);

GUI_SetLayerVisEx (1, 0);

GUI_SelectLayer(0);

GUI_SetBkColor(GUI_WHITE);

GUI_Clear();

and a loop like

while(1)

{

GUI_Exec(); /* Do the background work ... Update windows etc.) */

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness00);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness10);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness20);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness30);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness40);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness50);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness60);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness70);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness80);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness90);

GUI_Exec();

osDelay(3000);

DSI_IO_WriteCmd(0, (uint8_t *)lcd_brightness100);

GUI_Exec();

osDelay(3000);

}

Remember because of the high frequency I can't scale with 1% so I took 10% steps.

This thread will step from 0 to 100% in 10% steps every 3 seconds.

Maybe ST will change the driver with the next release of the STM32F7Cube Library.

Edit: Feel free to test other frequencies as well

Edit 2: Seems like my cat can't hear anything too.

Kind regards

Nyix

[benny]

Posted on February 22, 2017 at 16:06

For evaluation:

I attached a AC6 SW4STM32 project. You can simply import, build and flash it. The interesting parts are in otm8009a.c, k_lcd.h/.c and main.c.

Furthermore I attached the otm8009a datasheet (with some comments).

Edit: If someone is interested in: how to use SRAM and SDRAM for the heap with heap5.c. I used itin this example and explain it in another forum thread.

Kind regards

Nyix

________________

Attachments :

F769_lib1_6_otm8009a.7z.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hysw&d=%2Fa%2F0X0000000bDa%2FkhNw6K.7TomtQoDJl2pT5e2XTxRBihAxBH1El6P5uKo&asPdf=false

OTM8009A-ORISE.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hysm&d=%2Fa%2F0X0000000bDZ%2FwZb_cuLXwKXo_nBlY70bjSqPgXzJd9Xb1uIguVW8vO8&asPdf=false

[JB2500]

Posted on February 23, 2017 at 00:08

I'm nearly 49 so I probably can't hear ~ 19 kHz now. However, I could certainly hear up to 20 kHz when I was younger and also sense - as a sort of force / pressure near the sides on my head - frequencies just above that. Therefore, to accomodate younger people (as well as older people with intact hearing), I would like ST to use a frequency of at least 20 kHz and preferably above 22 kHz: particularly as it's almost certainly going to appear on the DAC output (as a consequence of the USB earth loop), just as the ~ 8 kHz did.

I understand that this would limit the number of brightness levels even further. Perhaps eight levels at around 22.5 kHz would be acceptable.

A frequency of around 200 Hz might be sufficiently quiet without introducing problematic flicker (I'm not in a position to try it right now). However, given the DAC interference issue, I doubt there's any merit in considering it unless the electrical noise / DAC output problem can be fixed.

All in all, particularly as I need the DAC output, my preferred option is still simply to use 100% brightness or display off.

Anyway, great work Nyix! I've not been able to download the files yet, I think due to some webhosting issue this end, but I'll try again tomorrow.

Cheers,

JB.